DEV Community: Dominik

Forest Radar: planning a walk with Polish forest data and local AI

Dominik — Sat, 10 Oct 2026 21:12:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I built

My idea for the Touch Grass challenge was a small application that helps you choose a nearby forest for a walk. Give it a location and a radius, then get information about the forests nearby and suggestions about what you might find there. Save the result or print it, and take it outside.

I called it Forest Radar, or Leśny Radar in the Polish interface.

The original idea included mushrooms, berries, animal tracks, and questions like whether you can bring a dog. Those questions sound simple until you start looking at the available data. Forest inventory data can tell you about the trees and habitat. It cannot tell you that a mushroom is there today, or that a particular forest is safe to enter.

The current application accepts coordinates and a radius between 1 and 20 kilometres. You can also ask the browser to fill in your location. It produces a separate Polish description for each forest range returned by the search, with a Google Maps link and the same safety footer on every card.

A forest range is an administrative area, not a complete walking route. This version does not provide turn-by-turn navigation, verify dog-access rules, or guarantee a suitable entrance.

Demo

The application runs locally. The example in the screenshot uses latitude 52, longitude 21, and a search radius of 5 kilometres. The first card is for Uwieliny. It has an AI-generated forest description, a Maps link, a print button, and a mushroom-safety warning with a link to look for expert help.

Screenshot: the Uwieliny card in Leśny Radar. The description is labelled as AI-generated and potentially inaccurate; the safety footer is fixed application text.

A search at this location produces cards for Uwieliny, Bogatki, Dobiesz, Chojnów, Góra Kalwaria, and Sękocin. One run took about 97 seconds to fetch the data and generate all six descriptions. It is slow enough that I would want to prepare the cards before leaving, rather than wait for them on the trail.

The app can generate the cards, but the descriptions still contain errors. They need checking before anyone relies on them to plan a walk.

Code

The project is written in Ruby with Sinatra and is available under the MIT licence:

Forest Radar on GitHub

I chose Sinatra because the application needs one page, a JSON endpoint, and a printable result. Rails would add more structure than I need here, while writing the HTTP and view layers myself would take time away from the application.

The interface uses i18n. The Polish translations are complete; the English translation keys exist, but their values are still empty. The README includes instructions for running the app and its tests.

How I built it

The main data source is Bank Danych o Lasach, the Polish Forest Data Bank. The application queries its OGC API Features service for forest administration and inventory data near the requested location.

The useful fields include tree species, habitat type, stand age, and inventory year. A stand is a unit in the forest inventory. The application groups the relevant stands by forest range and summarizes their attributes before sending them to the model. Each forest gets its own description.

For Uwieliny, the query returned 431 stands within the search radius, with an inventory year of 2026. Here is part of the species summary:

SO (pine):       216 stands
DB (oak):        79 stands
Missing species: 53 stands
BRZ (birch):     39 stands

These are counts of stands grouped by their recorded species code. They are not hectares or percentages, and they do not count individual trees.

I keep this raw data off the user-facing card because it is hard to interpret, but include it in the model's prompt.

I chose Bielik because it is a Polish model and I wanted the forest descriptions in Polish. I run it through Ollama on a separate machine on my local network, using SpeakLeash/bielik-11b-v2.3-instruct:Q4_K_M.

I originally asked Bielik for a structured response with specific keywords and separate sections. It consistently left out the keywords or sections I requested. The forbidden-word checks described below also kept rejecting its answers, so I stopped requiring that format and now display the response as it comes back, with a disclaimer.

The prompt asks, in Polish, what the BDL data can tell us about the forest's area, accessibility for walkers, and possible animals, plants, and mushrooms. The application supplies numbered data lines, but it does not check whether the generated description accurately reflects them.

The backend also queries OpenStreetMap through Overpass and includes the retrieved trail information in each forest's prompt. The input distinguishes four cases: a mapped trail crosses the forest, the search found no crossing trail, the data was unavailable, or the forest was not checked. The prompt explains that missing data does not mean there are no trails on the ground. It also explains that the Google Maps link identifies the forest location rather than a verified walking route.

I added this trail information after reviewing the earlier output shown here. Responses remain unvalidated, so the extra context does not guarantee a correct description.

The mushroom rule I changed

I wanted the application to suggest possible mushroom species for a habitat. I did not want it to decide whether a mushroom is edible or poisonous.

My first approach was strict validation: reject responses containing forbidden words about edibility. Bielik kept using those words when listing mushrooms, and the validator kept rejecting the answers. I removed the word check from the running version.

The screenshot shows the description mentioning "grzyby jadalne i trujące" (edible and poisonous mushrooms). In a later run, before I added the trail information, the model went further and listed named mushrooms as edible. The original validation would have rejected that output. The current application does not.

I opted for a disclaimer and the same mushroom-safety footer on every forest card. The description is labelled as AI-generated and potentially wrong. The footer warns against collecting unfamiliar mushrooms and points readers toward a sanitary station, where a qualified expert can check them. It includes a Google Maps search link to help find that service.

This is a trade-off, not a replacement safety guarantee. A disclaimer does not prevent unsafe output. Forest Radar is not a mushroom-identification or edibility tool, and its generated text is not a reason to eat something found in the forest.

What the model got wrong

Before I added the trail information to the prompt, one Uwieliny description included this phrase:

sosna (216 ha) i świerk (79 ha)

That means "pine (216 hectares) and spruce (79 hectares)." The source summary actually had 216 stands recorded with the pine code and 79 with the oak code. The model changed both the units and the species associated with the second value.

It also called the forest accessible to walkers without current access evidence. These are errors in the generated description, not facts established by BDL. Animals, berries, and mushrooms mentioned in the text are not verified sightings either.

I have not yet taken a card outside and compared it with what I found in the forest.

Why I removed the entry-ban check

Checking whether a forest was closed was part of the original plan. During development, the entry-ban service returned HTTP 400 errors, so the application could not determine whether a ban was in place. I removed the check rather than keep a feature that always reported an unknown result.

That means Forest Radar does not establish current entry-ban status. The model can still write an accessibility claim, as the demo shows, but that claim is not a substitute for checking current notices from the relevant forest district.

Why does open innovation matter?

Public forest data makes this project possible. It gives the application a source for local forest information instead of asking a model to invent it from a place name. It also lets me compare the generated description with the input and identify mistakes such as the stand-count error.

An open-weight model served through Ollama gives me control over inference. I can choose the model host and change the model without replacing the rest of the application. Running it on hardware I control avoids a proprietary model API and its per-request charges, although the hardware and electricity still have a cost.

The application still needs internet access. BDL and Overpass receive queries containing a bounding box around the user's location. The model host receives summarized forest data, trail information, and distances, rather than the raw input coordinates. Google Maps receives location information when a user opens one of the links.

For this project, the benefit is control over the model service and access to the underlying data. Neither makes the generated text automatically correct.

Forest Radar is a working local prototype for exploring nearby forest options. I want the screen to be the preparation for a walk, not the activity itself. Before relying on the descriptions as a guide, I still need to improve their accuracy and test the cards outside.

I wanted Claude to delegate to a local model. That became MAF.

Dominik — Sat, 10 Oct 2026 12:44:29 +0000

I started building MAF because I wanted to make AI more reliable and spend less on it.

My idea was simple: use a paid claude based model for complex reasoning, planning, and judgment, then use a local model for implementation work. Keep the expensive model involved where it helps and use the local model for work it can handle.

At the time, I couldn't find an option that fit my workflow easily. My experiments with local models were also disappointing. Simple, well-explained tasks worked, but tool calls or longer agentic workflows would overflow the context window.

I started using Claude Code, but I still wanted to use a local model through Ollama and OpenCode for some side tasks.

I tried several approaches: first subagents, then skill bridges that told Claude Code how to delegate simple tasks to OpenCode. Automatic communication between the two harnesses—the tools running the agents—was unreliable or used too many Claude tokens.

I was making progress, though. I worked out a process where Claude Code wrote a task file with instructions for OpenCode to implement. I still had to point OpenCode to those files myself.

The shared-board idea came from a conversation at EuRuKo with Maciej Mensfeld. He described his own agentic workflow and how he isolated agents with Coi (Code on Incus), a tool that runs coding agents inside isolated Incus system containers. He also mentioned agents coordinating through a Kanban-like task service.

What stuck with me was the idea of agents using a task board to communicate. I wanted something similar, but local: no external task service and no web requests just to coordinate work. The agents could still use cloud models, but their board and messages would live in the project.

That gave me a way to move beyond manually passing task files between agents. It became Multi_Agent_Flow (MAF).

A shared board instead of another agent runtime

MAF is the glue that lets different coding-agent tools coordinate work on one project. It does not replace Claude Code, OpenCode, Codex, or Hermes. Those tools still run the agents, using the model access you configure for each one.

You can use Claude Code with your subscription and OpenCode with a local model, or choose another combination of harnesses and models. MAF does not require the whole team to use the same provider. It comes with predefined roles and workflow examples, but you can define your own.

MAF gives the agents a shared way to coordinate work on one repository:

A project-local Taskwarrior board records goals, tasks, and claims.
File inboxes carry messages between roles and workers.
Git worktrees give workers separate checkouts.
Resource locks let workers serialize access to something they share, such as a local model host.

The common interface is the coord CLI. An agent does not need a vendor SDK to read the board or send a message. It needs to run a command.

There is an optional shared-memory layer through graphify and an Obsidian vault. Obsidian makes it easier for you to browse the agents' knowledge.

There is also a web dashboard, which you can start by running .maf/bin/dashboard from the project root. It shows worker status, the task board, and coordination activity. It also includes analysis tools that suggest ways to reduce token usage.

The part I care about most is choosing tools by role. I can keep a cloud model on planning and review while routing scoped implementation work to another harness. MAF provides the coordination; it does not guarantee that a local model will do a task correctly or cheaply.

Roles are responsibilities, not model names

An architect decomposes a goal into tasks. Developers implement them. A tester checks behavior. A reviewer examines the result.

For example, imagine adding CSV export to an app. The architect defines the task and its acceptance criteria. A developer claims it and implements it in a separate worktree. A tester checks the behavior, and a reviewer examines the diff. If something is missing, they send feedback through the inbox instead of relying on me to copy messages between terminals.

A project manager can sit between me and the architect: I describe the outcome, and the project manager creates the goal and reports back. The lead roles do not claim implementation tasks.

A harness is the tool running a role. A worker is a running instance of that role. More than one worker can serve the same role.

This distinction matters because I do not want my project structure to depend on which model I happen to use this month.

For example, this configures a mixed team:

maf add claude:architect opencode:backend-developer claude:reviewer

That command installs the flow and generates the role files. It does not start the agents.

OpenCode is the harness here, not the model. To use it for local implementation, I configure it to use a model served by Ollama.

You aren't limited to the predefined roles. You could define a writer, editor, researcher, or proofreader and assign each one to whichever harness and model fits best. maf role add NAME creates a stub in .maf/roles.yml; you fill in its responsibilities and permissions. You can also write your own workflow in .maf/workflow.md for the architect to follow.

MAF stays out of the project's tracked files

The tool keeps its main installation in .maf/. It uses .git/info/exclude to keep those files out of the clone's normal Git status. The knowledge graph lives separately in graphify-out/.

MAF also installs Git hooks and harness-specific files. Those are real changes to the local environment, even though the tool keeps its setup out of the project's tracked source files. A clean Git status does not mean that nothing changed on disk.

The agents' code and project documentation still go through your normal Git workflow; MAF's local setup stays outside it.

Different ways to run MAF

At first, I ran all my harnesses interactively. That let me see what each agent was doing in its own terminal window and micromanage the process when I needed to.

Now I talk to a single agent in the project manager role. The rest of the team runs in --dispatch mode, in terminals I start myself. The dispatcher waits for tasks or messages and invokes the agent when there is work. You can also ask the project manager to arrange a team with the architect, within the worker limits and allowed harnesses you configure.

One important caveat: dispatch mode bypasses approval prompts for Claude Code, Codex, and Hermes; OpenCode uses the permissions in its role file. Separate worktrees help keep changes apart, but they are not a security sandbox. Only use unattended workers with access you are comfortable granting them.

Try different approaches to see what works for you. I started with interactive sessions because I wanted to watch the coordination before leaving more of it unattended.

Try it on something small

You don't need to start with the whole team. Begin with an architect and one developer, watch how they coordinate, and add other roles when you need them.

You need Ruby 3.0 or later, Git, and Taskwarrior for the coordination layer. For actual agent work, you also need an installed coding-agent harness with the model access it requires. Graphify is optional but recommended for shared knowledge.

gem install maf
maf version
maf guide

You can then open a coding agent in your project and ask:

Run maf guide. Read the output and help me set it up.

MAF is open source on GitHub and published on RubyGems.

You can ask your agent about MAF as you go. It can guide you through adding custom roles or workflows rather than making you learn every command first.

I'd like feedback from people whose workflows differ from mine. If you try MAF, tell me which tools you used and where setup or coordination became confusing. If you encounter a bug, please open an issue with a reproducible example.

I had Ruby running on a 2009 iPhone. Then I needed something to run.

Dominik — Sun, 04 Oct 2026 22:23:12 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I had Ruby 4.0.7 running on a 2009 iPhone 3GS. I just didn't know what to run on it.

Then this challenge gave me an idea: turn the phone into a home network dashboard connected to a local AI model.

I built it for my best friend: myself. It do not solves any problems but it let me learned some new concepts.

The Ruby port was already part of a larger side project. The dashboard is the new project I built for this challenge. I wanted something to run on the phone and something to write about here.

The phone shows devices on my home network. I can type commands or ask questions about the latest device scan. A model on my PC answers the questions. The phone runs the Ruby dashboard; the PC runs the model.

iPhone 3GS (Ruby daemon, Safari)
      └── HTTP LAN ──> Mac (Ruby agent: scan / ping / wake / chat)
                            └── HTTP LAN ──> PC (Ollama: Qwen3.8-27B-Ridge)

Three machines to ask which devices are online. This is what happens when I choose my own weekend projects.

Demo

The interface is one HTML page served on the phone by Ruby's TCPServer. Safari displays the page. An ordinary HTML form sends questions. A refresh link updates the display. There is no JavaScript.

The page lists registered and discovered devices, their online status, and the model's availability. The latest reply appears above the question box.

During verification over USB SSH, Ruby on the phone returned:

ruby 4.0.7 (2026-09-29 revision fdc00de497) +PRISM [armv7-darwin10]

An HTTP request from the phone to its own dashboard returned 13 device entries. Eleven entries were online and two were offline. A second request from the phone reached the Mac agent successfully. The agent reported the local model as reachable.

Those two offline entries need a qualification: pc and printer still had placeholder records in my configuration. The result proves the dashboard receives data. It does not prove that my actual PC and a real printer were offline.

Code

The dashboard source is available on GitHub:

agent/ runs on the Mac. It scans the network, handles commands, and sends questions to the model.
client/ runs on the phone. It serves the dashboard and talks to the agent.
config/ holds device records and agent settings.
deploy/ installs the phone's dashboard service.

The agent and client use Ruby's standard library, with no runtime gems. The tests use Minitest.

How I Built It

The model is Qwen3.8-27B-Ridge, served locally by Ollama on my PC. The Mac agent reaches Ollama over HTTP on the LAN.

The jailbroken phone runs iOS 6.1.6 and my cross-compiled CRuby build. Getting Ruby onto the phone needed changes to CRuby for compatibility with the old iOS SDK. That work belongs to the larger project. This weekend's task was to give Ruby an application.

I chose a web page for the interface because the phone already has Safari and an onscreen keyboard. Ruby serves the page, and a launchd service starts the dashboard. I had already used this approach for a light-meter application on the same phone.

The most useful bug appeared after the connections worked. The agent scanned the network. The model answered questions. But the model knew nothing about the scan.

I asked what devices were on my network. The reply began:

I can’t see your network. On your computer: run arp -a …

Fair answer. I had connected the model without sending the information the model needed.

The fix was to attach the latest device snapshot as context:

def system_prompt
  "You are a LAN overseer. Answer from the device list below only. " \
    "Keep the answer short. Devices: #{device_summary}"
end

After the fix, the recorded answer began with “10 devices online” and listed addresses from the snapshot. The model now had information about my network instead of only my question.

Commands such as ping, scan, wake, and ports go through Ruby command handlers. Free-text questions go to the model. The model explains the supplied device status; it does not choose or execute network commands.

The prompt does not guarantee accurate answers. One later reply suggested that the placeholder printer might have responded on a printer-related port. The supplied context contained no evidence for that explanation.

That is a useful limit to show alongside the working demo. Providing context helps, but the configuration and the answers still need checking.

Why Does Open Innovation Matter?

Open source made both parts possible: adapting Ruby for the phone and running a model on hardware I control.

The phone's Ruby build has no OpenSSL extension. The dashboard uses plain HTTP inside my home LAN. The Mac agent has no authentication, so this prototype belongs on a trusted home network.

Local inference gives this project three useful properties:

Local data. The application sends device status and questions to my own PC.
No per-token API fees. I use existing hardware, although running that hardware still uses electricity.
A replaceable model. I can install another compatible model in Ollama and change model_name in config/agent.yml.

The phone does not need to run the model itself. A small Ruby client is enough to use the model through the Mac agent.

That is enough for this weekend. I started with Ruby running on an old phone and no application in mind. Now the phone has a dashboard, and I have a project to write about.

Eventually, I want to share the wider Ruby-on-3GS story at a Ruby user group, perhaps as my first lightning talk. This dashboard gives me one working example to show.

My best friend seems pleased with the result. He is already thinking about what else to run on the phone.

Reading The Pragmatic Programmer in the age of AI

Dominik — Tue, 07 Jul 2026 13:51:39 +0000

I bought The Pragmatic Programmer a few years ago but never finished it. As part of my current effort to sharpen my fundamentals, I decided to finally read it from cover to cover.

I expected it to feel slightly dated. The first edition was written in 1999. The second edition came out in 2019, just before generative AI reshaped how many of us work. Instead I found the opposite: most of the principles still hold. What changed isn't their validity — it's the level at which they apply.

The first thing that stopped me was one sentence in chapter 2. The authors note, almost in passing, that there are still no compilers capable of generating software from a concise description of requirements. Reading that struck a strange tone in my mind. We still don't have the compiler they were imagining, but we do have LLMs and AI agents that occupy a surprisingly similar role — turning a few paragraphs of natural language into working software. A later chapter reinforces the feeling: the authors argue that programming can't be reduced to a mechanical process, or CASE tools would have replaced programmers long ago. History spent twenty years appearing to prove them right. Then it stopped being so obvious.

That became the question I read the rest of the book with: if implementation is finally being automated, which of these ideas become more important, and which become less?

The Knowledge Portfolio, revisited

Take the Knowledge Portfolio. On the surface, AI seems to reduce the need to learn deeply. Why spend months mastering something an assistant can explain or generate in seconds?

My strongest evidence to the contrary came from a React migration. I'm primarily a backend developer with little frontend experience. With AI's help I produced a UI that matched the mockups and met every functional requirement. To me, the code looked fine. The senior frontend engineers reviewing it disagreed — it ignored several established patterns in the codebase, and I didn't have enough experience to recognize the problems myself.

Later, on smaller and more clearly defined tasks, I noticed something. AI followed project conventions much more reliably when I could extract and state those conventions explicitly. The better I understood the rules of the system, the more useful the AI became. The lesson wasn't that AI replaced expertise. It was that expertise determined whether I could recognize good output when I saw it.

So learning and gaining expertise is still essential. Otherwise how will you notice mistakes in AI thinking? For me, the valuable investment is in mental models — functional programming, distributed systems, architecture, security, AI systems themselves. The goal is no longer accumulating syntax knowledge across many languages but understanding how software behaves.

Orthogonality, DRY, and the cost of unclear thinking

The idea that gained the most weight for me was orthogonality. Clear boundaries between modules and responsibilities have always been good practice; in the AI era they're closer to a prerequisite. AI increasingly writes the implementation while the engineer defines interfaces, constraints, and responsibilities — and the quality of those boundaries determines how effectively AI can contribute. Vague definitions produce tangled, duplicated, hard-to-verify output. Clear ones produce something you can actually review and trust.

This sharpens DRY, too. The principle was always about duplicated knowledge, not duplicated code — but AI scatters business logic across services and modules so reliably when left unsupervised that the distinction becomes impossible to ignore.

There's one idea I initially thought was new, then reconsidered. I'd written in my notes that AI makes poor thinking more expensive — a vague prompt burns tokens, time, and iterations. True, but engineers have always paid for unclear thinking. The currency used to be debugging and rework; now it's tokens and review cycles. The cost isn't new. What's new is how fast and how visibly it arrives. AI acts less like a new source of risk and more like a mirror: it doesn't create bad habits, it reflects them back faster.

The Blackboard pattern, reframed

Master your tools, invest in your environment — still valid. But increasingly the tool is operated by an agent, not typed directly by a developer. Which makes plain text more central, not less: it's the medium through which intent reaches both humans and machines, in prompts, configuration files, and instructions. The skill that used to be "master your tools" is becoming "design workflows that you and an AI can both operate in effectively."

That reframing shows up most clearly in the Blackboard pattern — one of the book's more academic-feeling ideas, where independent specialists post partial solutions to a shared space until a solution emerges. It suddenly resembles modern multi-agent systems, where specialized agents collaborate through a shared space rather than a shared conversation.

The reframe I keep coming back to is that what agents need to share isn't conversational context, which gets expensive fast, but structured knowledge: goals, decisions, findings, tasks.

Shared knowledge rather than shared context.

The more I experiment with agentic systems, the more I believe preserving useful knowledge matters more than preserving every step of the conversation that produced it.

Testing: don't let AI do the thinking part

One place that caught my interest was testing. The authors frame tests as valuable less for catching bugs than for forcing you to reason about your code before you write it — and that matches what TDD taught me: deciding how to test something is part of designing it.

Which is why I'm cautious about handing testing entirely to an AI. Ask an agent to "add test coverage" and it will — but if it does the thinking too, you skip the part that was actually useful. You never ask what the code should guarantee, where it might break, or what "correct" means here. The tests exist, but the design reasoning they usually prompt didn't happen. So in practice I let the AI write the tests while I stay responsible for what to test — writing assertions is mechanical; deciding what to verify is where the thinking is.

The lizard brain, and where instinct comes from

That worry generalizes. The authors tell you to trust your "lizard brain" — the instinct you develop from years of writing, debugging, and refactoring code yourself. That instinct is earned, and it's earned specifically by doing the work. So what happens when AI does more and more of that work? Can you build the same intuition reviewing generated code that you'd build writing it yourself? Or will the next generation of developers grow a different instinct — one tuned to architecture, decomposition, and judging AI output rather than to implementation detail?

I genuinely enjoy working with AI. It automates the repetitive parts and lets me explore ideas faster than before. But every problem it solves for me is a problem I don't solve myself — and solving problems is how experience accumulates. There's a balance to strike between using AI as a productivity tool and protecting the learning that produces judgment in the first place.

That, in the end, is what rereading The Pragmatic Programmer left me with. Software engineering is becoming less about writing code and more about making decisions — architecture, domain modeling, contracts, boundaries. You can't reason well about AI-generated code if you don't understand software engineering yourself. Knowledge hasn't become less important; it's shifted from producing code to evaluating and guiding it.

The book didn't change my mind about AI. It sharpened it. The implementation was never the hardest part of the job. If AI keeps automating the mechanics, the ability to think clearly about software may become the most valuable skill a developer can have — and I'm genuinely unsure how we'll keep teaching it once the machine is doing the reps.

Rails Integration Testing with Fixtures: A Practical Approach for Complex Data Sets

Dominik — Tue, 07 May 2024 07:47:48 +0000

The Challenge of Realistic Test Data

I recently faced a unique challenge in writing integration specs for a Rails application. The goal was to simulate real-world complexity within our test environment, involving interactions across 13 models like orders, line items, and products. The catch? I needed to generate around 10,000 interrelated records, reflecting the kind of volume and complexity we see in production. Typically, I'd reach for the factory_bot gem for test data generation, but due to the sheer volume and the need for persistent data, this method proved too slow. My ideal solution needed to enable the insertion of a large volume of data into the database efficiently, mirroring production data characteristics as closely as possible.

Solution: Tapping into Production DB and Fixtures

After exploring several avenues, I discovered that leveraging Rails' default fixtures, combined with our staging database (which mirrors the last three months of production records), provided an unexpectedly effective solution. Here’s how I transformed real production data into a manageable, anonymized test suite:

def fixture_creator(model, anonymized)
  File.open(
    "#{Rails.root}/spec/fixtures/#{model.table_name}.yml",
    "w+"
  ) do |f|
    fixture_data = {}
    model.in_batches(of: 100) do |batch|
      batch.each do |record|
        fixture_data["#{record.id}_#{fixture_data.size + 1}"] =
          record.attributes.dup.merge(anonymized)
      end
    end
    f.write fixture_data.to_yaml
  end
end

Exploring the Code

In this snippet, fixture_creator function does the heavy lifting:

Batch Processing: By processing the data in batches (model.in_batches(of: 100)), we efficiently handle large volumes of data without overwhelming memory usage.
Unique Keys for Fixtures: We create unique keys for each record ("#{record.id}_#{fixture_data.size + 1}"), ensuring each entry in our fixtures file is distinct and easily identifiable.
Anonymization: The anonymized parameter is a hash that overrides sensitive attributes with dummy values, crucial for maintaining data privacy.

This approach significantly speeds up the process compared to individually creating records via factory_bot. By directly exporting data from a staging environment (a subset of our production data), we ensure our tests are running against data that closely reflects real user interactions, both in volume and complexity.

Anonymization and Security

One key aspect of using production data for testing is ensuring all sensitive information is thoroughly anonymized. In my case, the anonymized hash includes mappings of original attribute names to anonymized values, applied to each record. This step is crucial not just for security and privacy, but also for complying with legal obligations like GDPR.

Conclusion

This method of generating fixtures from production data presents a robust way to create realistic, high-volume test environments for Rails applications. It's particularly useful when the test scenarios are complex, and the realism of data interrelations is crucial. While this approach worked well in my case, it's important to tailor the solution to the specific needs and constraints of your project and always prioritize data security in any testing strategy.

Memoization in Modern Ruby: How a Shape-Based Approach to Instance Variables Lookup Impacts Performance.

Dominik — Thu, 02 Nov 2023 11:32:39 +0000

Memoization is a classic technique in Ruby programming, greatly assisting in boosting performance. With Ruby's ongoing evolution, particularly towards a shape-based method in instance variable lookups, thoughtfully implementing memoization can be beneficial. Inspired by Jean Boussier's insights on RailsAtScale.com, this post highlights some suggested best practices.

Why Consider Memoization?

Memoization helps cache results of resource-heavy function calls, aiming to speed up subsequent executions. Ruby’s newer shape-based mechanism for instance variable lookups suggests organizing objects based on their instance variables. This approach influences performance and memory usage, but it's important to note that using memoization indiscriminately could lead to a range of object shapes, which might inadvertently affect performance. Understanding these subtleties can be helpful for developers looking to craft efficient and thoughtful Ruby code.

Suggested Best Practices

Aligning with Ruby's shape-based approach and optimizing memoization strategies, developers might consider the following approaches:

Mindful Use of Memoized Variables: It’s generally a good idea to keep memoized variables to a minimum. Ideally, aiming for one or two per class helps. If you find yourself needing more, initializing these variables to nil in the constructor could be a proposed better approach:

class MyClass 
    def initialize     
        @expensive_value = nil   
    end    

    def expensive_value     
        @expensive_value ||= compute_expensive_value   
    end 
end

Handling Falsy Values with Tokens: When dealing with memoized values that might return falsy results, using a token could be a neat way to differentiate between an uninitialized state and a value that's legitimately falsy:

class MyClass   
    NOT_SET = Module.new   
    private_constant :NOT_SET    
    def initialize     
        @expensive_value = NOT_SET   
    end    

    def expensive_value     
        return @expensive_value unless @expensive_value == NOT_SET     @expensive_value = compute_expensive_value   
        end 
    end
end

Wrapping Up

Adjusting to Ruby's shape-based approach for variable lookups, we might consider refining our memoization tactics to help maintain efficient performance and thoughtful memory usage. For those interested in exploring this topic further, Jean Boussier provides a deeper dive in his article at RailsAtScale. It's a thought-provoking read for anyone interested in evolving their Ruby coding practices in harmony with the latest language developments.

This summary reflects ideas from Jean Boussier's article published on October 24, 2023, on RailsAtScale.com. To broaden your understanding, the original article is well worth a read.