I didn't get there in one step. I started where most people start, by writing rules for the agent in its config files. When those stopped working I moved to written specs, and when specs weren't enough I moved the rules into code: custom lint rules, dependency checks and other static analysis. This is that story, using the rewrite of RemoteLock's web app as the example.

Figure: Each stage moved the rules from read to checked. Stage 1, config files: a request the model reads. Followed some of the time, whatever the level of detail. Stage 2, OpenSpec: a contract a person reviews. It fixes what to build, not how the code looks. Stage 3, static analysis: a check a machine runs. Yes or no, every time, and it names the line. A scale under the stages runs from "the model interprets" to "the machine enforces".

The example: rewriting RemoteLock's web app

At RemoteLock we are rebuilding the customer web app as a new React single-page app, connect-web-v2. It is a good stress test for AI-driven development for three reasons:

• It ships next to the old app. Both apps answer the same URLs, and a route manifest decides, path by path, which one serves a customer. Nothing can break the parts that are not moved yet.
• It is big and long-lived. Hundreds of pull requests since mid-2026, many of them written by agents, and a codebase other engineers will maintain for years.
• The old code is a trap. The legacy app works, but copying its patterns would copy its problems. The rule is that legacy is reference only: behaviour is re-specified from scratch, never ported.

That combination punishes an agent that guesses. So the repo is built to stop guessing.

Stage 1: rules in Claude config files

I started with CLAUDE.md: a file of conventions the agent reads at the start of every session. Use the component library. Keep modules apart. Test this way. Name things like that. It felt like onboarding a new engineer, and at first it worked.

Then I noticed the output wasn't consistent. The same rule held in one session and was ignored in the next. So I tried the obvious fixes, in both directions:

• More detail. Longer explanations, examples, the reasoning behind each rule. The file grew and the agent followed it no more reliably. Rules near the top competed with rules near the bottom.
• Less detail. Short, sharp lines. Easier to scan, but loose enough to be read several ways, and the agent picked whichever reading suited the task in front of it.
• Finer granularity. Rules split per folder and per kind of task. That helped locally, but which rules applied to a given change became its own guessing game.

Some changes made things worse. An example written to illustrate one rule got copied as a pattern where it didn't belong. A rule meant for one area leaked into others. And every line spent context that the actual task needed.

The lesson took a while to land: a config file is a request, not a guarantee. The model reads it the way a person reads a long wiki page, mostly right and never exactly the same way twice. Config files are still the right place for orientation, meaning where things live, why the code is shaped this way, and which docs to read. They are the wrong place to rely on for anything that must always be true.

Stage 2: specs with OpenSpec

The next problem was scope, not style. Asked to build a feature, the agent filled every gap with its own assumptions, and on a rewrite next to a legacy app those assumptions were often the legacy app's habits.

OpenSpec fixed that part. Every change starts as a written proposal: the behaviour as requirements and scenarios, and a task list. One spec change per pull request. The agent loads that change and the current spec for its area before it writes code, so it builds against a contract instead of a guess.

What it helped with:

• Less guessing. The agent no longer decides what a feature does. The spec does.
• Faster review where it counts. I read a page of behaviour before anything is built. A wrong spec is cheap to fix, and a wrong diff isn't.
• A fresh start from legacy. Behaviour is re-specified from scratch, so the old app stays a reference and never becomes a template.
• Small pull requests. One change per PR keeps each one reviewable in minutes.

What it didn't fix: a spec says what to build, not how the code should look. Two agents could implement the same spec correctly and still break the architecture in two different ways. The "how" was still living in a config file, so it was still a request.

Stage 3: rules as code

The change that made the output consistent was moving rules out of prose and into static analysis. If a rule matters, a machine checks it, and the check answers yes or no. The agent doesn't have to remember the rule, because it can't get past it.

In connect-web-v2 that means:

• Custom lint rules for our conventions. No raw HTML elements, className or inline styles outside the UI library. Components are typed arrow constants. Packages are imported by name. Tests find elements only by test id. Each one started as a line in a config file that agents kept missing, and became a lint error.
• No escape hatch. Disabling a lint rule is itself forbidden, so an agent under pressure can't silence a check to get green.
• Dependency rules for the architecture. dependency-cruiser enforces module boundaries: a module is imported only through its public entry file. The list of top-level modules is closed, and adding one needs a person's approval in the same PR.
• Presence checks. Every visual component must ship with a story and a test, or be explicitly tagged as non-visual. Every page must name itself in the browser tab.
• Dead code and drift. knip fails on unused files and exports. The API client is generated from the backend's OpenAPI schema, and CI fails if the two drift apart. Specs are validated too.
• Budgets and gates. An 80% coverage floor on logic, accessibility checks, bundle-size budgets, a changelog entry on every user-facing change, a phone screenshot on every UI change.
• Grandfather lists that only shrink. Old code that doesn't meet a new rule is listed by name, and the list can only get shorter. A new rule never waits for a big cleanup.

The dependency rules matter for another reason: they make the codebase a set of vertical slices. Each module owns everything for its feature in one folder: its API calls, schemas, hooks, components, permissions and tests, with sub-areas as nested modules of the same shape. A task almost always lives inside one slice. So the agent only needs that folder and the public entry files of the few modules it uses, a small context where everything is related, instead of a horizontal layer that cuts across the whole app. Smaller, related context is a big part of why the output got consistent: there is less to misread and less to leak into.

The effect on the agents was immediate. A red check is specific: it names the file, the line and the rule. The agent reads it and fixes it, usually on the first retry, without me in the loop. The config file changed role too. Its rules are still there, but each one now has a check behind it, so the file explains the rule and the check makes it true.

Stage 4: a review that can be argued with

Static analysis catches what can be stated as a rule. What's left, like whether the code actually does what the spec says, goes to an automated review that runs on every pull request against that PR's own spec. It is built so the model only notices and code decides:

• Several review passes read the diff and write candidate findings to files. They post nothing.
• A reconcile step matches them against a per-PR ledger of findings, and it is the only thing that comments.
• The verdict is a pure function of that ledger. Open critical or major findings block the merge, and nothing else does.
• Later rounds check whether the open findings were fixed instead of re-reviewing from scratch, so a review converges instead of finding new nitpicks forever.

When a finding is wrong, anyone can reply /review dispute with the reason. A fresh session, with none of the first reviewer's reasoning, re-derives the evidence and either withdraws or upholds the finding. A finding is a claim about the code, so it falls to evidence, not authority. Visual changes get the same treatment: a visual-regression diff on demand, approved per commit.

Put together, a change only reaches a person after every machine has said yes:

Figure: Only a change that passes every gate reaches a person. Left to right: spec change (written first, read by a person), agent builds (rules and skills), CI checks (yes or no), AI review (the ledger decides), merge (after spec and proof, read by a person). A red check at CI sends the change back to the agent, which retries. An open finding at AI review sends it back to the agent, which fixes it. Below AI review, a dispute step started with /review dispute has a fresh session weigh the evidence. The two places a person reads are the spec change and the merge.

A red check or an open review finding sends the change back to the agent. I read only the spec at the start and the evidence at the end.

Why it's fast

Guardrails sound like friction. In practice they are what makes speed safe, because they move judgement out of my head and into places an agent can read and a machine can check.

• Small units of work. One spec change per PR keeps each change small enough to review in minutes and to revert in one click.
• Cheap rejection. A red check costs the agent a retry, not me a conversation. Most problems are caught and fixed before I ever look.
• Parallel work without collisions. Module boundaries and a closed module list mean several agents can work in different areas at once without stepping on each other.
• Review that converges. The ledger turns review into a checklist that empties, not an argument that grows. Disputes settle on evidence in minutes.
• Rules that compound. Every time an agent gets something wrong in a new way, the fix is a lint rule or a check, not another line in a config file. The next agent can't repeat the mistake.

The downside

This works so well that it creates its own problem. When every convention is a lint rule and every boundary is a check, writing code becomes almost deterministic. That's exactly what you want from an agent, and it's not great for the people working in the codebase.

• Less room to improve. A better pattern now has to beat a rule, a check and a grandfather list before anyone can try it. Experiments that would have been a small PR become a debate about changing the rules.
• Gaps get hidden, not found. The checks prove the code follows the architecture. They say nothing about whether the architecture is right. When everything is green, nobody is prompted to notice that a boundary is in the wrong place or that two modules really want to be one.
• Less learning by doing. Engineers who mostly read specs and green checks spend less time inside the code, which is where people usually spot that something doesn't fit.

I don't have a full answer yet. What helps so far: treating the rules themselves as code that gets reviewed and changed, keeping architecture decisions with people, and setting aside time to question the structure instead of only building inside it.

What still needs me

The agents write the code. Four things stay with me:

• Deciding what to build. The spec is the product decision, and it is the part I read most carefully.
• The shape of the system. Architecture decisions, new top-level modules and the rules themselves are reviewed by people.
• Taste. Whether a screen feels right, whether copy reads well, whether a flow makes sense to a property manager at 7am. I judge that from the screenshots and recordings each PR carries.
• Building the guardrails. When something slips through, I don't fix the code. I fix the rule, check or skill that let it through.

That last point is the whole method. The fastest way to make AI do the right job is not a better prompt. It is a repository where the wrong job can't pass.

I run Home Assistant on a Raspberry Pi at home, and I didn't write most of its configuration by hand. Claude Code did. My job was to describe what I wanted, check the result, and keep it safe.

This is what that looks like, what it costs, and what I'd tell anyone starting.

Why it got cheap

The parts were never the expensive bit. The expensive bit was getting them to work.

A few years ago a project like an automatic watering valve went roughly like this. You read forum threads to guess which board, relay and power supply would work together. You bought them, sometimes the wrong ones, sometimes pricier ones because you didn't trust the cheap option. You wired it up and occasionally fried something with the wrong voltage. Then you copied code you didn't fully understand, flashed it, watched it fail, and changed things until it worked, without always knowing why it finally did. Each failed attempt cost a part, an evening or both, and plenty of projects died somewhere in that loop.

AI removes the most error-prone steps of that loop:

• Choosing parts. It checks compatibility, voltages and pinouts before you buy, and compares shops. In my case it priced the parts live and even caught its own mistake: it had compared a bare ESP32 module with a full dev board, which made one shop look 40% cheaper than it really was.
• Wiring. It explains which pin goes where and why, and flags the step that would destroy a board, like feeding 12 V to a 5 V input.
• Code you can read. The configuration it writes is plain YAML that it can explain line by line, instead of a sketch pasted from a forum.
• Debugging. It reads the logs and narrows a failure down to a cause, so a fix takes one attempt instead of ten.

The hardware costs what it always did, tens of euros. What dropped is the number of attempts, the broken parts and the evenings, and that is most of what a project used to cost.

The setup: Home Assistant as code

Home Assistant runs well on a Raspberry Pi with HA OS. The one habit that makes working with an AI agent safe is keeping your configuration as code: YAML files in a git repository on your laptop, copied to the Pi with a small deploy script. Every change is a diff you can read, and every mistake is one revert away.

A few things make that setup easy to live with:

• One file per area. Watering in one file, heating in another, notifications in a third. Changes stay small and easy to review.
• Validate before reloading. Home Assistant can check its own configuration. Make the deploy script run that check first, so a broken config never goes live.
• Write down the clicks. Some steps only exist in the UI, like pairing a device or signing in to a vendor account. Keep them as a checklist in the README instead of pretending they're code.

Keeping it secure

A home system has cameras, door and gate controls, and your Wi-Fi password in it. The rules I follow are simple, and none of them need special skills:

1. Don't open ports to the internet. You don't need them. Remote access goes through Tailscale: the Pi makes an outbound connection to a private network, and your phone reaches Home Assistant through that network from anywhere. Nothing in your home listens to the public internet.
2. Keep secrets out of the repository. Passwords, tokens and Wi-Fi keys live in a secrets.yaml that git ignores. The repo carries a secrets.yaml.example with the same shape and fake values, so the config is readable without exposing anything.
3. Give every token the least it needs. If another service needs your sensor data, give it a token for a dedicated read-only user. If that token leaks, someone can read sensor values and nothing else.
4. Prefer local over cloud. When you can, pick devices Home Assistant can talk to on your own network, and keep camera recordings on storage you control. Some devices only work through a cloud account. Accept that per device, knowingly, and write it down.
5. Validate before you deploy. Home Assistant checks its own config before anything reloads. A bad change is rejected instead of half-applied.
6. Decide what the AI may touch. Claude edits files in the repo and runs the deploy script. The secrets it relies on sit in files outside the repo, so they never end up in a diff or a chat. It doesn't log in to vendor accounts or pair devices. Those steps stay with me, in the UI.

None of this is exotic. It's the same discipline you'd use for a small web app, applied to a house.

Cheap devices and circuits

The part that surprised me most is how little the hardware costs. These are real prices for the parts of a typical small project, read from Portuguese and Spanish shops in July 2026:

The pattern is always the same: an ESP32 running ESPHome, a sensor or a relay, a power supply, and a waterproof box. Prices move, so check before you order, but the order of magnitude is tens of euros per device, not hundreds.

What you can build with them

None of these are new ideas. The point is that each is now an afternoon instead of a month.

Irrigation is the best place to start. A valve per zone and an ESP32, or a Bluetooth tap timer, and Home Assistant does the thinking: it skips a run when the forecast says rain, waters longer after hot, dry days, and logs how much water each run used. Compare each run with the last few and you get a leak alert almost for free. Add your water company's prices and it can estimate the bill. It's useful from the first week, it saves water, and nothing bad happens if a run goes wrong.

More ideas on the same budget:

• Control an old air conditioner or TV. An infrared blaster learns the remote and Home Assistant replays it, so a ten-year-old unit gets a schedule and a thermostat.
• Know when a tank is full or the water is running. A float switch and a flow meter cost about ten euros each.
• A camera that wakes on motion. An ESP32 camera board with a motion sensor, around thirty euros, sends a snapshot to your phone.
• Use Bluetooth gadgets without their apps. An ESP32 can act as a Bluetooth proxy, so devices out of the Pi's range still show up in Home Assistant.
• Get told when something opens. A door or gate sensor plus a notification is one of the simplest and most useful automations there is.
• Look after animals. Automatic water, feed and a camera for a chicken coop come from the same parts as everything above.

How Claude fits in, and where to stay careful

The way I work is the same for every device:

1. Describe the outcome in plain words: "water zone 2 for longer when it's been hot and dry, and tell me if it uses more water than usual."
2. Claude reads the existing packages, writes or changes the YAML, and explains what it did.
3. The deploy script validates the config on the Pi and reloads it.
4. I check the result on the dashboard or the device, and Claude reads the logs when something is off.

What it does well: reading datasheets and integration docs, writing configuration, working out protocols, keeping notes in the README so the next change starts from what was learned, and pricing parts.

Where I stay careful:

• Anything with mains power. AI can explain the wiring, but a 230 V circuit gets checked by me, and by an electrician when it's more than plugging in a supply.
• Anything that opens or locks. Gates and doors deserve a manual override and a notification on every change, so an automation bug never locks anyone in or out.
• Accounts and pairing. Logging in to vendor clouds and pairing devices stay manual steps.
• Prices and stock. They change weekly. The AI reads them live, and I still look before ordering.

The result isn't a smart home that impresses visitors. It's a house that waters the garden properly, warns me about a leak, and lets me check the cameras from anywhere, built mostly from parts that cost tens of euros each, with a lot less frustration than it used to take.

I'm not an architect and I don't use SketchUp. So on a Friday night in September 2026 I typed one line into Claude Code: "Can you make 3d models in sketchup files based on images of places?"

What I wanted, and what I started with

The goals grew over the week:

1. Decide the layout. Kitchen, stair, sleeping mezzanine, bathroom, deck, pool, garden, parking.
2. Compare options side by side. "You should make all the different suggestions in different models", so each idea got its own file.
3. Respect the real constraints. The cork oaks stay, the existing doors and windows stay, and the mezzanine has to make sense under the building rules.
4. Make it look real. Plain SketchUp "doesn't look realistic and is full of mistakes". I wanted renders I could show people.
5. Walk through it. An aerial loop and then a walk through the rooms, like a visitor would.

The starting point was thin: a map pin, "the building is 8 m by 6 m", the wall thickness and a guess at the roof height. The first model came from that and one old street-view image, and the early versions looked like this:

It got accurate once better inputs arrived: photos of the architect's drawings, which gave a scale, and the topographic survey, a CAD file that Claude converted into a JSON file with the exact outline, levels, trees and plot boundary. From then on the model of the existing building matched the real one:

The setup: the model is code

There is no SketchUp plugin or MCP server in the middle. Claude Code drives SketchUp 2026 from the terminal: it opens SketchUp with a Ruby script passed at startup, the script builds the whole building, saves the .skp file, renders preview images from a set of named cameras, and quits.

The building itself is a parametric Ruby program, about 2,900 lines plus 1,100 for materials and decoration. Wall thickness, roof pitch, where the stair starts and which wall the kitchen sits on are constants at the top. Changing the design means changing a number, not dragging faces around.

Around that:

• Real furniture and trees come from SketchUp's public 3D Warehouse as GLB files, imported at real scale.
• Textures are partly generated with Python, partly scanned PBR materials from Poly Haven.
• The survey is a CAD drawing converted to JSON with open-source tools, so the plot, levels and trees come from measurements.
• Blender rebuilt the house in Python for photoreal renders with Cycles.
• Small helpers draw plan sketches before a big change and make contact sheets of the previews.

The loop

Every change went round the same loop:

1. Describe it in one line. Often from my phone while looking at the last renders: "the stairs are blocking the doors to the bedroom", "the bed is almost touching the roof beam".
2. Sketch before building. For anything that moved the layout, Claude first drew a simple plan in the terminal so I could confirm it understood. That one habit saved more rebuilds than anything else.
3. Build a new version. Each build went into a new file with its own version name, never the one I had open, so SketchUp never got stuck on a file conflict and old options stayed around to compare.
4. Review the previews. Every build rendered 30-odd images from fixed cameras: the four corners outside, each room, and "door views" showing what you see when you walk in through each door. Claude looked at them first, I looked after.

Options got their own versions too: kitchen on the north, east or west wall, a low or high mezzanine, and about a dozen stair layouts. The one I kept is version 34.

Results

The same aerial camera across versions shows the design settling:

And the living room, version by version:

The chosen design, version 34: a low sleeping mezzanine over the kitchen, a stair along the north wall, a deck with a small pool, the cork oaks kept.

For realism, Claude rebuilt an earlier version of the house in Blender with Python and rendered it with Cycles. Fifteen images took about a minute and a half each:

What worked, what didn't

What worked:

• The model as code. Every option is a version, every change is a diff, and nothing depends on my SketchUp skills, which are close to zero.
• Real inputs beat clever guessing. The model was vague until the survey and the drawings arrived, and exact after.
• Sketch first. Asking for a quick plan before each big change caught misunderstandings before they cost a build.
• Fixed cameras. The same views every build made changes easy to compare, for Claude and for me.

What didn't:

• Walkways. The agent kept forgetting that people need room to walk past a bed, a counter or a stair. I had to say it again and again.
• Headless SketchUp is fragile. A welcome window, an open file or a locked screen can stall a build silently. The scripts write their own error log because SketchUp shows nothing.
• 3D Warehouse is uneven. Some models are kilometres wide, some trees are flat photos.
• SketchUp to Blender was too slow. Exporting the full model produced 11 million triangles and a 1.2 GB file, so the photoreal renders stayed on the earlier Blender rebuild.
• The walkthrough video. Rendering it frame by frame would have taken hours, so the tour plays live inside SketchUp and I record the screen.

Six evenings and about 34 versions later, I had a layout I'd call the best we'd done, and a clear picture of the options we turned down.

I'm happy to announce that I've just released tailwindcss-rb!

Tailwindcss-rb is as a (sort of) simple Ruby gem that aims to bring Tailwind CSS writing into a more Ruby-friendly environment.

With it, you can style your html with Tailwind in a Ruby-like syntax without losing the power of it's compiler. It's still unclear to me where it's value lies exactly, but it's something I've used as a core component of my other WIP library (view-component-ui), a mantine-like ui component framework for ruby on rails.

Here’s what Tailwindcss-rb offers:

• Easy Setup: Just add gem 'tailwindcss-rb' to your Gemfile, and you’re ready to go.
• Ruby-like Tailwind Classes: The Tailwindcss::Style class and tailwind helper make it simple to build classes in a Ruby way.
• Flexible Configuration: Tweak everything from output paths to breakpoints to match your project’s needs.
• Real-Time Compilation: Compile on the fly during development, or pre-compile your styles for production effortlessly.

I can’t wait to see how Tailwindcss-rb helps simplify and speed up your styling in Ruby projects. 🚀

👉 Explore tailwindcss-rb on GitHub

the Rails documentation doesn't always have the answers for the kinds of problems you're now dealing with.

As your project matures, the straightforward guidance that Rails offers starts to fade, and you’re left with questions that don’t have clear answers in the docs. That’s when friction starts to creep in. You’ll find yourself writing code that doesn’t quite fit into the standard Rails patterns, or relying on libraries that feel like they're just bolted on. Worse yet, you might end up with code that's difficult to maintain, riddled with performance issues, or just plain buggy. And suddenly, that "magic" that made Rails so appealing starts to feel like a burden.

At this stage, the issues you’ll run into usually fall into one or more of these three categories:

• Code that requires more than the core Rails libraries: As your app grows, you often need features that the framework doesn’t provide out of the box, leading you to patchwork external solutions.
• Code that becomes too complex for the simple MVC architecture: The default Rails patterns start to break down as you introduce more complex business logic, making your codebase harder to maintain.
• Code that fails due to the use of Rails' own patterns: Using certain Rails conventions can lead to performance bottlenecks, bugs, or maintenance nightmares, and sometimes the framework’s magic becomes the problem instead of the solution.

In this article, I’m not here to talk about the quick-fix Rails solutions for hobby projects. I’m talking to the developers who’ve spent months (maybe years) working on growing Rails apps—developers who have hit the same roadblocks I have, and who have searched the docs for answers that aren’t there. If you’ve been struggling with finding a path through some of Rails' hidden complexities, stick with me. I’m going to walk you through three common challenges that the documentation just doesn’t cover, and what you can do to navigate them without tearing your hair out.

But before we dive into the specifics, let’s start with some foundational principles that will help you reduce the friction in these situations.

The Base Principles.

These don't apply to the development of Rails apps alone, but are particularly relevant in Rails in my opinion, because of the problems we mentioned earlier.

For that reason, keep these in mind:

1. Do keep it stupid simple (KISS)

One of the biggest downfalls of a developer is abstracting too much too early, foreseeing problems that may never be relevant for the future of the company. I have been too many times guilty of doing this myself, and worked long enough to see how damaging it could be in the long run.

2. Remember that Simplicity is an antonym of Complexity, but is not synonyms with Easy.

When an organisation strives to “keep things simple”, too often are arguments construed in favour justifying a particular solution by calling it “simple”, when the author of the argument actually means “easy”. By this I mean that, in order for you to consider something as the “Simplest solution”, your considerations should not revolve around the time it takes to develop it, but around the total time and maintenance costs of the feature. Not to say that a solution can’t be easy and simple, on the contrary, that’s the ideal scenario, and by taking simple solutions you’ll guarantee than in the future you’ll have an easier time find the simple solution.

3. Remember that Consistency (almost) always trumps correctness.

Don’t go against existing patterns if you believe you’ve found a better one, unless you can entirely replace the existing pattern, otherwise you’ll end up with 2 patterns, and where there’s room for 2 patterns that do the same thing, there’s likely room for a third, and so on.

Always remember that following patterns will make your code better and easier to maintain than introducing a new pattern that others will need to learn.

To be continued.

dry-transformer offers a versatile toolkit for defining and applying data transformations in Ruby on Rails applications. By leveraging composable functions known as transformers, developers can easily define complex mappings between different data structures. With a declarative syntax and modular approach, dry-transformer enables clean and efficient data manipulation, making it an invaluable tool for optimizing data mapping tasks.

Usage Examples

Example 1: Renaming Keys and Nesting Data

require 'dry/transformer'

class DataMapper
  extend Dry::Transformer::Registry
  import Dry::Transformer::HashTransformations

  # Define transformations
  map_keys rename_keys: { user_name: :name, user_age: :age }
  rename_keys user_email: :email
  nest :address, [:street, :city, :zip_code]
end

Usage: Let's say we have input data like this:

input_data = {
  user_name: 'John',
  user_age: 30,
  user_email: 'john@example.com',
  street: '123 Main St',
  city: 'New York',
  zip_code: '10001'
}

When we call DataMapper.new.call(input_data), it transforms the data as follows:

{
  name: 'John',
  age: 30,
  email: 'john@example.com',
  address: {
    street: '123 Main St',
    city: 'New York',
    zip_code: '10001'
  }
}

Example 2: Multiplying Values

require 'dry/transformer'

class DataMapper
  extend Dry::Transformer::Registry

  # Define custom transformation
  map_value price: ->(value) { value * 10 }
end

Usage: Suppose we have an input value of { price: 20 }. When we call DataMapper.new.call(input_data), it transforms the data to { price: 200 }.

Example 3: Composing Transformers

require 'dry/transformer'

module CustomTransformers
  extend Dry::Transformer::Registry
  import Dry::Transformer::HashTransformations

  # Define custom transformations
  map_keys rename_keys: { first_name: :name, user_age: :age }
  rename_keys user_email: :email
end

class DataMapper
  extend Dry::Transformer::Pipe
  import CustomTransformers
end

Usage: Let's say we have input data like { first_name: 'John', user_age: 30, user_email: 'john@example.com' }. When we call DataMapper.new.call(input_data), it transforms the data as follows:

{
  name: 'John',
  age: 30,
  email: 'john@example.com'
}

Conclusion

By leveraging dry-transformer, Ruby on Rails developers can achieve clean, efficient, and modular data mapping in their applications. Whether you need to rename keys, nest data, apply custom transformations, or compose multiple transformers, dry-transformer offers a flexible and powerful toolkit to meet your data mapping needs. Incorporate dry-transformer into your development workflow to streamline data manipulation and unlock new possibilities for data transformation in Ruby on Rails applications.

Happy mapping!

In many applications, certain attributes have specific validation requirements beyond simple presence or format checks. For example, consider a scenario where you need to validate the gender attribute of a user record, ensuring that it contains one of the values 'male', 'female', or 'other'. While Rails provides mechanisms for basic validation, handling such custom requirements can be challenging.

Introducing dry-types

dry-types is a powerful gem that provides a flexible toolkit for defining and working with types in Ruby applications. One of its key features is the ability to define custom types tailored to your application's domain. Let's start by defining a custom type for the gender attribute:

require 'dry-types'

module Types
  include Dry::Types.module
  
  # Define custom type for gender attribute
  Gender = Strict::String.enum('male', 'female', 'other')
end

In this example, we define a custom type Gender using dry-types, restricting the values to 'male', 'female', or 'other'. With our custom type defined, let's integrate it into the validation process using dry-validation.

Validating Data with dry-validation

dry-validation is a validation library that integrates seamlessly with dry-types, allowing you to define validation contracts with support for custom types. Let's create a validation contract for a user entity that includes our custom type:

require 'dry-validation'

class UserValidator < Dry::Validation::Contract
  params do
    required(:name).filled(:string)
    required(:age).filled(:integer)
    required(:gender).filled(Types::Gender)
  end
end

In this validation contract, we specify that the :gender attribute must be filled and must adhere to the Types::Gender custom type we defined earlier. Now, let's see how we can use this validation contract in practice.

Putting it into Practice

# Usage example
input = { name: 'John', age: 25, gender: 'male' }

result = UserValidator.new.call(input)

if result.success?
  puts 'Validation passed!'
else
  puts 'Validation failed:'
  puts result.errors.to_h
end

In this example, we create a UserValidator instance and call it with input data containing attributes for name, age, and gender. The validation process checks that all required attributes are present and that the gender attribute conforms to our custom type. If validation fails, we print out the validation errors for further inspection.

Conclusion

By leveraging custom types defined with dry-types alongside dry-validation, you can enhance data validation in your Ruby on Rails applications with ease. Whether you need to enforce specific constraints on attributes or validate complex data structures, this approach provides a flexible and powerful solution. Incorporate custom types into your validation process to ensure data integrity and reliability, empowering you to build robust and maintainable Rails applications.

Happy coding!

PostgreSQL supports the decimal data type for precise numeric storage. This data type allows users to specify both the precision (total number of digits) and scale (number of digits to the right of the decimal point). However, when interacting with PostgreSQL through ActiveRecord, developers may notice unexpected behavior due to differences in how decimal values are handled.

Example of Precision Loss

Consider the following scenario:

# Migration file
create_table :transactions do |t|
  t.decimal :amount, precision: 10, scale: 2
end

# Model class
class Transaction < ApplicationRecord
end

# Creating a new transaction
Transaction.create(amount: 10.555)

In this example, we're creating a transactions table with an amount column defined as a decimal with a precision of 10 and a scale of 2. However, when we attempt to save a transaction with an amount of 10.555, ActiveRecord will truncate the value to 10.55 before storing it in the database.

Why Precision Loss is Problematic

Precision loss can lead to inaccurate financial calculations, potentially causing discrepancies in balance sheets, transaction totals, and other critical metrics. Furthermore, rounding errors can compound over time, resulting in significant discrepancies in financial reporting. For applications handling sensitive financial data, such inaccuracies are unacceptable and can undermine trust and reliability.

Solutions to Precision Issues

To address precision issues in PostgreSQL with ActiveRecord, developers can consider the following solutions:

Solution 1: Adjust PostgreSQL Column Scale

# Migration file
change_column :transactions, :amount, :decimal, precision: 15, scale: 5

By increasing the scale of the amount column, more decimal places can be stored, mitigating precision loss for values with fractional components.

Solution 2: Handle Precision in Application Logic

# Model class
class Transaction < ApplicationRecord
  before_save :adjust_amount_precision

  private

  def adjust_amount_precision
    self.amount = amount.ceil(2)
  end
end

In this solution, we use ceil(2) to round the amount attribute up to two decimal places before saving it to the database. By rounding up, we ensure that precision is maintained and that any fractional components are accounted for.

Conclusion

Decimal precision issues in PostgreSQL with ActiveRecord can pose significant challenges for developers working with financial data or other numeric values requiring precise calculations. By understanding the limitations of PostgreSQL's decimal data type and adopting appropriate strategies for handling precision, developers can ensure accurate and reliable data storage and calculations in their Ruby on Rails applications. Whether through adjusting PostgreSQL column scale, handling precision in application logic, or a combination of both, addressing precision issues is essential for maintaining data integrity and trustworthiness in financial applications and beyond.

Ruby on Rails, with its Model-View-Controller (MVC) framework, has long been a hallmark of simplicity and efficiency in web application development. Initially, this framework offers a clear and structured approach, but as applications grow in complexity, these once beneficial characteristics can turn into limitations. Drawing from personal experiences and a broader understanding of Rails, this article explores how the framework's early advantages may evolve into challenges and emphasizes the importance of a dynamic architectural approach in Rails, which offers much more than just MVC.

The Broader Appeal of Rails

Rails is often lauded for its MVC framework, but its allure extends far beyond this aspect. Its appeal lies in the simplicity it brings across the board – from setting up web servers and managing databases to fostering a robust and supportive community. The true beauty of Rails lies in this comprehensive simplicity, underscoring the fact that Rails is more than its MVC framework. It's a holistic toolkit that simplifies numerous facets of web development.

The Initial Appeal of Simplicity

The MVC framework in Rails, more than a mere structural guideline, embodies a philosophy of straightforwardness crucial in the early development stages. While it excels in managing basic functionalities and standard features, we must acknowledge that this is only a part of what Rails has to offer. As projects scale, this simplicity can start to conflict with the complexities of advanced features, revealing the limitations of a static architectural mindset.

Rising Complexity and Architectural Evolution

As projects grow, adding features and building intricate interdependencies, the simplicity of Rails' MVC starts to falter. This increase in 'domain complexity' isn't just about more code; it's about the complex interaction of expanding features. Here lies a critical point where initial architectural choices may no longer be sufficient. It becomes evident that architecture in Rails should not be static but rather dynamic, evolving to meet the application’s growing needs.

Misconceptions of the 'Rails Way'

A prevalent misconception in the Rails community is the notion of a 'Rails way' – a rigid adherence to MVC with little room for deviation. This idea can be misleading, suggesting that if MVC isn't a perfect fit, the solution might be to switch frameworks or languages. However, such a view overlooks Rails' inherent flexibility and richness. Rails offers a robust foundation that extends well beyond MVC, capable of adapting to various complexities and requirements.

Community Influence and Discerning Solution Adoption

The Rails community is a vibrant ecosystem that continuously generates a multitude of solutions and patterns. However, the popularity of these solutions, often gauged by metrics like GitHub stars, can sometimes overshadow their actual suitability for specific problems. While community-driven innovations are invaluable, they should be approached critically, ensuring they align with the project's unique requirements rather than being adopted based on trendiness alone.

Embracing Architectural Flexibility

Confronting the challenges of growing complexity necessitates exploring beyond conventional MVC. Integrating service objects, presenters, decorators, and embracing domain-driven design (DDD) represents a move towards more flexible and scalable architectural patterns. This approach is in harmony with the philosophy of Rails, advocating for architectural practices that are dynamic, adaptable, and responsive to an application's evolving requirements.

Conclusion

Rails, often equated with its MVC framework, is in fact a multifaceted tool that simplifies a wide range of web development aspects. As applications evolve, it's crucial to embrace the flexibility inherent in Rails, venturing beyond MVC to discover architectural solutions tailored to specific project needs. Recognizing and leveraging the full spectrum of capabilities offered by Rails allows for the development of sophisticated, well-structured applications that can gracefully scale with growing complexity.