Robby on Rails

On ShopTalk Show: Rails in 2026, Dependencies, and the Long Tail of Decisions

Mon, 27 Apr 2026 00:00:00 +0000

I recently joined ShopTalk Show… episode 711 to be exact. Which… now has me thinking I should probably go get myself a Slurpee.

A few things we got into…

Oh My Zsh started as shared aliases for teammates… and turned into a plugin ecosystem that keeps growing.
Ruby on Rails in 2026… scaling isn’t the question anymore. Teams are wrestling with restraint and keeping systems understandable.
LLMs and contribution… more people can open meaningful PRs now. Conventions and structure matter more than ever.
Dependencies… every one feels small when added. Over time… they stack up and stick around longer than expected.

If you haven’t listened to ShopTalk Show… go subscribe.

Less Opinions. More Data. The 2026 Rails Survey

Mon, 27 Apr 2026 00:00:00 +0000

Every two years, the team at Planet Argon runs the Rails Developer Survey. And every two years, I go through the same process… a long list of questions, a hard look at how much time we’re asking of respondents, and a lot of cutting.

If you’ve filled it out before, thank you. If this is new to you, here’s the short version: it’s an open survey for Rails developers at all experience levels and across all kinds of organizations. We compile the results and share everything publicly. No paywalls. No vendor spin. Just a snapshot of what the community is actually doing.

We first ran this in 2009… back when ”should I use Rails?” was still a serious question… and have been doing it every two years since 2012.

It’s become something we rely on heavily at Planet Argon. In client conversations. In blog posts. On podcasts. In talks. When someone asks, “what are other teams doing with X?”… we’d rather point to data than speculate.

And then there’s the less practical reason. We’ve been in this community a long time. Someone should be asking these questions. We’re fine being the ones who do.

What’s in the 2026 survey

I’ll be upfront… I have a heavy hand in what makes it in. It’s a team effort with plenty of discussion and refinement, but the final call usually comes down to me.

The filter isn’t just curiosity. It’s closer to: what reflects real decisions teams are making right now?

Those aren’t always the same thing.

This year, a couple of areas got expanded.

One is project types.

I want a clearer picture of what Rails teams have actually shipped… and what they’re actively changing right now.

Not just “we build SaaS” or “we have an API”… but the actual decisions showing up in roadmaps and backlogs.

Things like:

Upgrading Rails or Ruby versions
Moving off Heroku or changing hosting providers
Consolidating services… or breaking things apart
Reworking CI pipelines or adopting self-hosted runners
Switching testing approaches between RSpec and Minitest
Rethinking background jobs or authentication systems
Overhauling the frontend layer
Introducing tools like Kamal, Packwerk, or Rails Engines
Experimenting with AI agents in development workflows

That’s the level of detail I care about.

“What is Rails being used for?” is still interesting.

What teams are actively changing is where things get useful.

The other is AI.

Leaving it out would’ve been an obvious miss.

We added questions based on input from folks in the community to get a clearer picture of what’s actually happening… how teams are (or aren’t) using AI day-to-day, where it’s showing up in real workflows, and how that compares to what we all see on LinkedIn and social feeds.

I care more about what’s making it into production than what people say they’re excited about.

A few things I’ve left out

Some people asked if we’d include questions about specific organizations or happenings in the Ruby and Rails ecosystem.

We won’t.

There are plenty of places for those conversations. This survey isn’t a proxy for grievances or a feedback channel aimed at anyone.

If something is mostly discourse, I’d rather wait and see if it turns into actual decisions teams have to make.

We do include a “what questions do you wish we had asked?” prompt at the end. People use it… sparingly… which I take as a decent signal we’re not wildly off.

How to participate

The survey takes about 10–15 minutes. It’s open to anyone working with Rails… solo developers, agencies, large teams… all experience levels.

Take the 2026 Rails Developer Survey

We’ll publish results shortly after it closes… and before Rails World 2026. As always, everything will be freely available.

If you want to share it with your team or community… do it. More responses means better data.

Thanks for being part of it.

AI Increased Your Output. It Also Increased Your Variance.

Thu, 23 Apr 2026 00:00:00 +0000

You gave a handful of your devs access to Claude Code Max… and things moved fast. Output went up. Then things started to drift. Not just formatting or naming. Structure. Approach. Assumptions. One developer builds guardrails around it. Another uses it like autocomplete. A third treats it like a thinking partner. Same tool, same codebase… different results. The code starts to reflect how each person uses the tool, not how the team builds software together.

There’s a tension here that most teams are sidestepping. You can feel the inconsistency creeping in, but saying “we should align on how we use this” sounds heavy-handed. So it gets framed as experimentation. Let people figure it out. Give it space. But this isn’t a side project. This is production work. Treating AI like open-ended R&D means everyone is running their own experiment… and nobody is learning together.

Inside the team, the gap gets wider.

A few engineers find a rhythm with these tools and start moving faster.

Others don’t hit the same stride.

That difference starts getting interpreted as a performance gap… even though the underlying workflows are all over the place. From the outside, leadership sees a few big wins and starts asking uncomfortable questions about why the rest of the team isn’t there yet.

A recent On Rails guest, Brian Scanlan, shared a metaphor that stuck with me. Commercial pilots often land planes on autopilot. They’re still paying close attention. Monitoring, inspecting, managing the system. They’re tested without it. They take control in unfamiliar scenarios. Sometimes they turn it off on purpose just to stay sharp. There’s pride in the craft. That’s the shift for engineers right now. The tool can handle more of the execution, but someone still owns the outcome… and knows when to step in, or step away from it entirely.

There’s another tension coming into focus.

Some engineers see this as survival.

A way to level up quickly and stay relevant.

That’s not irrational. But these tools pull a lot of the work into the CLI tooling away from your coworkers and into a more private loop. As a result, the learning also fragments. You start hearing more “look what I figured out” and less “look what we figured out.” I’m not immune to this either. It’s easy to optimize your own workflow and forget that the team needs a shared one.

Most teams don’t have a dedicated group thinking about how this should work. So the problem doesn’t wait its turn. It shows up in code reviews, in Slack threads where people share what worked or vent about what didn’t, in 1:1s, and eventually in performance reviews. It shows up when leadership is staring at a list of names and trying to make sense of who is rising to the moment and who seems to be falling behind (regardless of whether that is actually the case).

Engineering leaders already have the authority to shape how work gets done. That hasn’t changed. How your team uses AI is now part of your system. If you don’t define it, it still exists but in a fragmented and difficult to improve manner. None of this works if people are each operating in their own setup, with no shared baseline to compare notes against.

Treat your shared AI conventions like a style guide… CLAUDE.md or AGENTS.md or whatever it’s called by the time you’re reading this… prompt rules, shared skills – versioned, reviewed, owned by the team.

Otherwise, you’re scaling your inconsistencies.

Your codebase doesn't care how it got written

Tue, 14 Apr 2026 00:00:00 +0000

Every design team I’ve worked with has had the same complaint about clients.

“They sent over a PowerPoint with mockups.” Eye rolls. Crossed arms. The unspoken accusation: you’re stepping on my domain.

I got it. The client would shortcut the process. Fall in love with their own wireframes. Hand the designer a solution instead of a problem.

That friction was real.

But here’s what nobody said out loud… the designers were doing the same thing to the developers.

A designer would disappear for a few weeks. Come back with approved comps. Hand them off to a dev team with zero context on the constraints they’d just inherited. The developers would look at the designs and realize that one “simple” interaction was going to blow the budget.

But the client already signed off. The battle wasn’t worth the effort.

So the devs would swallow it. Build it. Ask to be looped in earlier next time.

Next time, they’d ask again.

Nobody was tracking any of this

Here’s what we glossed over in all of that role-boundary drama… every person in every one of those conversations costs money.

Which developers sit in ideation meetings? Which designers join the earliest planning calls? How much does all that collaboration cost before anyone builds anything?

Debate has a dollar amount. So does prototyping. So does the politics of navigating who gets a voice and when.

That overhead was always part of the model. We just built it into the timeline and called it process.

The client just got a promotion

Now look at what happened.

That client who used to send over clumsy PowerPoint mockups? They can prototype at a fidelity that would have required a designer and a developer just a few years ago. They can ideate. Get feedback. Iterate. Evolve their thinking… before they ever pick up the phone to call someone like me.

All of those “my role is very critical” layers? Easy to gloss over when someone can test an idea faster than it used to take to schedule the kickoff meeting.

I’m not going to pretend that doesn’t threaten my business model. My entire consultancy is built around being involved in the strategy and implementation of those types of client ideas.

Despite that… I don’t blame people for wanting to see what they can accomplish on their own.

I’ve seen this movie before

In the late ’90s and early 2000s, some entrepreneurial founder would build an elaborate system in Microsoft Access or FileMaker Pro.

And it worked. It actually worked.

They ran meaningful parts of their business on something they stitched together with enough technical curiosity and sheer stubbornness to pull it off.

Here’s the thing people in our industry like to gloss over… a lot of those systems are still running. In production. Right now. Doing the thing they were built to do.

Sometimes because the system genuinely still meets the need. Sometimes because the person who built it never quite saw the value in investing in something nicer for the team of people required to interface with it every day.

We literally just replaced an Access-based system this past year with a Rails app. Not because Access stopped working. Because someone finally retired and nobody else wanted to own the damn thing they’d built several decades ago. I’ve written about that pattern before. It never stops showing up.

Eventually, some of those systems hit walls. They got complicated. Organizations needed real UX. Architecture. Scaling. Integration. Tech support. Operational resilience.

So they brought in people like us.

Those DIY systems birthed a whole industry. Our industry. Much of what we’ve built our careers on exists because someone who was dangerously just-enough motivated built something with the tools available to them.

I don’t know if we need all of those same steps now. The ceiling is a lot higher than FileMaker ever was.

But the pattern feels familiar.

I want to be careful here… because I hear people raising real concerns about AI and I don’t think those concerns are silly.

Quality. Accountability. Labor displacement. Environmental cost. The question of whether we’re building on a foundation that exploits creative work without consent.

These are legitimate things to wrestle with.

I’ve had to wrestle with versions of that question my entire career. And I mean my entire career.

When I was an employee, someone else was making those calls. I didn’t control the tools. I didn’t choose the clients. I just had to decide whether the work was worth the compromise.

There was a whole period where I was being asked to work with Micro$oft tooling and all I wanted was open source. Microsoft was the evil monopoly of the era. That wasn’t a casual opinion. It was a real position, held by a lot of people I respected.

I eventually quit that job specifically to go work with open source tooling. I genuinely believed it was better for small businesses. And in a weird way, I still think I was right about that.

Open source was built mostly by volunteers and contributors to a movement.

But now we have tooling that can leverage all of that work… and it feels like it’s at odds with what that movement stood for. There’s a part of me that wonders if I’ve ended up on the wrong side of this one. Whether I’m advocating for the dark side and just can’t see it from where I’m standing.

But then I think about open source a little more honestly. Were we not heavily borrowing on the ideas of commercial products the whole time? “Open source clone of Microsoft Project” was a real search term. So was “open source version of Oracle.” Legitimate things people were actively building toward. Open source didn’t emerge from a vacuum. It emerged partly in opposition to commercial software, sure. But also in imitation of it.

The ethical lines were blurry then too. I just wasn’t paying close enough attention to notice. I’m not smart enough to have that philosophical debate now. I definitely wasn’t back then.

I’ve worked with clients whose labor practices abroad I used to actively protest. Built software for companies that produce products I would never put in my body. Worked with organizations that preach things I don’t believe in and don’t support.

Because there was an exchange of services rendered. Because I had a team to feed.

Because the alternative was… what, exactly? Holding out for clients whose values perfectly aligned with mine on every axis?

That’s a nice story to tell yourself at twenty. It’s also bullshit if you’re trying to make payroll.

Twenty-year-old Robby would have called me a sellout.

Forty-six-year-old Robby is a little more open to the idea that you can do meaningful work within systems you didn’t design and don’t fully endorse. That the money I earn lets me invest in things I actually care about. That the good I can do with the work produced matters alongside the work itself.

This isn’t unique to software. Every carpenter, every accountant, every nurse has had some version of this negotiation with modern capitalism. It’s a matter of what good you can do with the resources you earn.

Not a clean equation. Never has been.

Full disclosure

I should be honest about something. Six months ago, I was closer to the skeptics than I’d like to admit.

In January, I wrote about humans in the loop after the Oh My Zsh team spent real time figuring out how to handle AI-assisted contributions. We weren’t anti-AI. But we were grappling with the cost of reviewing work that looked plausible without being deeply understood.

That’s a legitimate concern. It still is.

A few weeks later, I wrote something more personal: I Didn’t Want AI to Be Good at This. The title says it all. I was coming around begrudgingly. I didn’t want the calculus to change.

But it changed anyway.

I’m still adjusting. I don’t have this figured out. I’m just further along than I was in January.

The job description changed

I’m hearing firsthand from peers who run small software teams. They’ve got engineers who aren’t just reluctant about AI. They’re not cautiously skeptical. They are entirely, firmly against it.

“Am I being forced to adopt this, or do I need to go somewhere else?”

That’s not a hypothetical. That’s a real conversation happening between developers and their managers at real companies. It’s being discussed in leadership meetings by people trying to figure out how to catch up with adoption. Some of those companies are also struggling to keep the business afloat right now.

And honestly? A lot of us were hired to write code. That’s not revisionist. That was the job description. We were brought in to produce code the same way a writer is brought in to produce words.

And let’s fact-check ourselves for just a moment here… because I can already picture people reading this and thinking they disagree.

We asked candidates for coding samples. We put them through live coding exercises. We talked about coding standards. Style guides. Naming conventions. We’ve all wished for… and sometimes had… the chance to reject someone’s code because it didn’t meet our conventions. Didn’t match our writing style.

Writing style.

Let’s not kid ourselves that we were entirely hiring for “outcomes” all along. We built the whole hiring apparatus around the artifact. Whether that was framed right or not… that’s what we did.

The codebase doesn’t care how it got written. It cares whether it works, whether it can be maintained, and whether it helps the business do what it needs to do.

That’s not a bait and switch. That’s what happens when your organization gets access to new tools and the economics shift underneath everyone’s feet.

What we have now is a training problem. A reclassification problem. And I’m not sure what the best HR-friendly way to frame this is… but here’s a serious question:

Would you rather your company post a new job ad for what they actually need going forward and let you compete with people from the outside? Or would you rather have the insider track to try out the evolving role before you decide to move on to some idealized version of what you were originally hired to do?

That’s not rhetorical. I think teams need to commit to a course of action here. If there are new roles to be defined… define them. Post the ad. Phase out what’s no longer needed as originally written.

Because “overseeing agents on my laptop produce code wasn’t on my job description” is going to be an exhausting fucking conversation for every human involved.

Most of us at smaller companies don’t have much of a voice in the big industry narrative. We’re not fielding hundreds of inbound inquiries and cherry-picking dream clients. We service the clients we can attract.

If you think now is the right time to turn away work because you disagree with whether AI-generated code is ethical… I understand the impulse. I do.

But I also think you might be asking the wrong people the wrong question.

What you might need to be asking is whether you need to find a different industry entirely.

Or… maybe you brand yourself as an artisanal coder. Find the organizations actively resisting LLM adoption. Carve out that niche.

I think that path can work for an individual. I’m skeptical it can sustain a company for long.

I don’t know what my own success looks like in five years. I don’t think anyone does.

It’s kind of scary. Nobody is going to tell you otherwise with a straight face.

But I know that the people who thrived after the FileMaker era weren’t the ones who resented the founders for building those systems. They were the ones who understood why the founders built them… respected what they accomplished… and then made the case for what comes next.

Using Claude Code with Ruby on Rails: Field Notes

Thu, 12 Mar 2026 00:00:00 +0000

Over the past few months, a few of us at Planet Argon have been experimenting with Claude Code on real client Ruby on Rails projects. Not demos or greenfield apps, but the kind of long-lived codebases where a backtrace can eat forty-five minutes before you even understand the call chain.

The part that surprised us is how often some of those debugging sessions now wrap up closer to ten minutes.

We’re not ready to make big claims. But we’ve developed enough of a feel for when to reach for it, which model to use, and how to keep it from making a mess of your codebase that it felt worth writing down.

The guide covers things like model selection (Sonnet vs Opus and when to switch mid-session), RSpec and Minitest workflows, debugging with error monitoring payloads, and how we’re structuring CLAUDE.md without turning it into a dumping ground. It’s written for developers who are skeptical of the hype but curious enough to run an experiment.

👉 Claude Code for the Semi-Reluctant, Somewhat Curious Ruby on Rails Developer

The engineers on your team who’ve already started experimenting with tools like this probably have a small head start. The gap closes quickly once you see where they actually help.

From AppSignal Alert to Fix to Deploy — Without Leaving the Terminal

Tue, 03 Mar 2026 00:00:00 +0000

I’ve been running a few experiments to streamline our development workflow, and I keep talking with folks on teams who haven’t been granted the budget or access to this kind of tooling yet. So I’m writing some of these up to help demystify what the experience is actually like.

For this one.. I wanted to see if I could take an AppSignal error and go from alert → fix → deploy without leaving the terminal.

Using Claude Code and AppSignal’s MCP integration, the whole process took under five minutes.

For context, our Rails app is already configured with AppSignal and has been running in production for a while. Like many teams, there are a few low-priority errors that pop up from time to time, but aren’t mission-critical enough to demand immediate attention. The kind of thing where you’d normally open AppSignal in a browser, copy the stack trace, switch to your editor, dig around, and by the time you’ve context-switched three times you’ve lost 30 minutes and your train of thought.

Here’s how I was able to handle one of those lingering errors without leaving the terminal.

Step 1: Install AppSignal’s MCP

I popped over to AppSignal’s MCP docs. Okay, I used a browser for this part.

I’m familiar enough with installing MCPs, but noticed that AppSignal’s MCP requires Docker to run it. I don’t know if this will be the case long-term, but I already had Docker running on my laptop so it wasn’t an issue.

I jumped down to their “Claude Code” instructions… which proposed:

% claude mcp add appsignal -e APPSIGNAL_API_KEY=your_api_key_here -- docker run -i --rm -e APPSIGNAL_API_KEY appsignal/mcp

I didn’t like the idea of adding the API key into my zsh command history, so I opted to add the API key to my project’s .env file, which is already being used by the Rails app, and then referenced it like so:

% claude mcp add appsignal -e APPSIGNAL_API_KEY=$APPSIGNAL_API_KEY -- docker run -i --rm -e APPSIGNAL_API_KEY appsignal/mcp

Added stdio MCP server appsignal with command: docker run -i --rm -e APPSIGNAL_API_KEY appsignal/mcp to local config
File modified: /Users/robbyrussell/.claude.json [project: /Users/robbyrussell/projects/project-name]

Step 2: Test the MCP connection

Next, I opened up Claude Code and ran /mcp to see if the connection was working. I was able to see the AppSignal MCP listed and was connected.

 ❯ appsignal · ✔ connected

Instead of digging through the docs, I tried the obvious command:

  Fetch details on AppSignal error 342

(Note: my first attempt was “Error #3342” — a typo that returned no results. Being precise with incident numbers saves a roundtrip.)

To my delight, the MCP integration retrieved the full error details from AppSignal, including the stack trace, exception type, and timeline of when it first and most recently occurred. A positive starting point.

For some context, this looked related to some bot-crawler behavior. Something related to authenticity tokens. Again, it didn’t feel like a critical error, hence why it had been lingering for a while. But I was curious to understand the root cause and potential fixes.

Step 3: Collaborate on a solution

Next, I was eager to task Claude with helping me understand the severity and potential fixes for this error. I prompted Claude with the following:

How can we handle this gracefully in Rails?

Claude provided four potential solutions. Some were minor code tweaks, one was to just set it to ignored in AppSignal, another was to modify our middleware or explore something on the Web Application Firewall (WAF) side of things.

Once we narrowed down a solution, I asked Claude to write the code change, run our test suite, commit with a descriptive message (including a link to the AppSignal incident for context), and submit a pull request to our GitHub repository.

My prompt for the first few steps was something like:

please go ahead and implement Option 1 for now and then mark the issue as closed for now in AppSignal.

Step 4: Deploy the fix

Given the non-critical nature of this particular error, I opted to use one of my /review-pr skills to run a fresh PR review on the change that Claude had made. I asked for a summary of the change, then approved the PR and let our pipelines run as normal.

While that was deploying, I logged into the AppSignal dashboard to confirm that particular error was now marked as closed. That way, if it popped up again, it would reopen and alert us again.

No Performance Help… yet

Once this was sorted out, I wanted to see if it could look into performance issues captured by AppSignal, too. Sadly, that doesn’t exist in the MCP as of March 2026.

❯ https://appsignal.com/planet-argon/sites/655d333b83eb671c877e2948/performance/incidents/2

⏺ appsignal - Check for additional tools (MCP)(context: "User wants to view a performance incident from AppSignal. The existing
      get_incident tool doesn't seem to support performance incidents (only
      exceptions/anomalies). Need to find a tool that can fetch performance incident
      details.", description: "I need to fetch performance incident details from AppSignal.
      The URL is for a performance incident (not an exception). I need a tool that can
      retrieve performance/slow request incident information by incident number.")
  ⎿  # Tool Request Logged
     We've recorded your request for additional tooling capabilities. Your feedback helps us prioritize new tool development.

I’ll be sure to keep an eye on that feature request and update this post if/when it becomes available.

Final thoughts

The interesting part here isn’t this particular error.

It’s the workflow.

By exposing monitoring tools like AppSignal through MCP, tools like Claude Code can retrieve incidents, analyze stack traces, propose fixes, and help ship patches without ever leaving the terminal.

In this case the flow looked like this:

AppSignal alert → investigate → implement fix → open PR → deploy.

Five minutes. No browser tabs. No losing my train of thought.

This is still early territory, but the building blocks are starting to line up. If you’re already using tools like AppSignal, it’s worth experimenting with MCP integrations and seeing what workflows you can streamline.

Building a RAG Tool in Ruby 4: What Actually Happened

Thu, 26 Feb 2026 00:00:00 +0000

One of my priorities this quarter was running a few AI pilot experiments. This was one of them.

When I mentioned the project to a teammate, he said, “You should write this up.” So here we are.

Others on our team had already been exploring embeddings, vector databases, and RAG. I’d been watching from the sidelines… until it was time to roll up my sleeves and build something myself.

The Problem

At Planet Argon, we manage several client projects. We live in Jira (I know… I know…). We keep decisions in Confluence. We ship code from GitHub. Over years a lot of institutional knowledge piles up across those systems… past bugs, old tradeoffs, and the “we tried that once” stories.

The problem is that nobody remembers all of it. A new ticket comes in: “users can’t export reports to PDF”. Somewhere in Jira there’s a ticket from eight months ago where we debugged a Safari-specific PDF export issue. Of course it was Safari. Somewhere in Confluence there’s a permissions matrix that’s suddenly relevant. If you weren’t assigned to the project back then, you would never know to look.

So we start over. We ask clarifying questions from scratch. We search Slack to ask if anyone has asked something like this before. Tickets go into development with vague acceptance criteria, and the back-and-forth that should have happened before coding shows up during code review and/or when we’re QAing on staging instead.

A vague ticket is a polite way to ask engineers to guess. Guessing can be expensive.

I wanted to build something that could surface that historical context automatically. Point it at a ticket and get suggested clarifying questions grounded in what we actually ~~know~~ “remember” about this project.

Why Ruby, Why Minimal Dependencies

Ruby is what our team loves working in. If we were going to learn embeddings, vector search, and LLM integration, I wanted everything around those ideas to feel familiar.

I also wanted to keep the dependency footprint deliberately small. This is an internal tool for a small team. Every Ruby gem you add is a gem you maintain. I’ve watched too many internal tools rot after someone pulled in thirty dependencies for a weekend project, then nobody wanted to deal with the upgrade treadmill six months later.

Rather than listing the full Gemfile here, I’ll call out the gems that aren’t obvious. You already know thor, faraday, nokogiri, and concurrent-ruby. The interesting ones:

ruby-openai: handles both embedding generation and LLM completions. One gem, two jobs.
pinecone and chroma-db: Pinecone for the shared production index, Chroma for local development via Docker. More on this below.
mcp: Model Context Protocol server for Claude Code integration. This came later, and it changed everything.
The tty-* family: not necessary… but nicer when you’re watching a 20-minute ingestion run.

Beyond that, Ruby’s standard library handled most of the rest. The instinct to reach for a gem is strong, but for most things the stdlib is genuinely sufficient.

Why Not a Server

Early on I made a decision that shaped the whole architecture: no running HTTP server with an endpoint. (at least, not yet).

A server is a commitment. Hosting. VPNs. Monitoring. Security reviews. Someone eventually asking, “who owns this?”. For an internal experiment that might not pan out, that felt like a lot of ceremony up front.

So I built it as a CLI tool. Each engineer runs it locally on their own machine. The only shared infrastructure is Pinecone, a cloud-hosted vector database. Everyone gets API keys to the same Pinecone index, but each client’s data lives in its own namespace. Engineers use their own Atlassian and GitHub API tokens when they want to run an ingestion.

Related: Internal Tooling Maturity Ladder is an approach that I’ve been exploring with our internal tools. The idea is to start with the simplest possible implementation (a script that solves the problem for one person), then evolve it through stages of maturity (CLI tool, shared server, versioned gem) as the need becomes clearer and the team is ready to invest more.

Here’s what the environment setup looks like:

# .env: each engineer has their own copy
# OpenAI (for embeddings and analysis)
OPENAI_API_KEY=sk-...
OPENAI_MODEL=gpt-4o-mini

# Atlassian (shared instance, individual tokens)
ATLASSIAN_BASE_URL=https://planetargon.atlassian.net
ATLASSIAN_EMAIL=you@planetargon.com
ATLASSIAN_API_TOKEN=ATATT3x...

# GitHub (individual tokens)
GITHUB_TOKEN=ghp_...

# Pinecone (shared index, namespaces isolate client data)
PINECONE_API_KEY=...
PINECONE_INDEX_NAME=clarion

This kept the experiment low-stakes. No deployment pipeline, no server to maintain, no VPN to configure. If it didn’t work out, there was nothing to decommission. Engineers pull updates from the main branch, run bundle install, and they’re current. It’ll likely become a proper gem we version at some point, but for now the simplicity of “pull main and go” is working fine.

What the CLI Looks Like

We called it Clarion. A clarion is a signal… felt right for a tool whose whole job is to surface things worth paying attention to.

The entrypoint is dead simple:

#!/usr/bin/env ruby
require "bundler/setup"
require_relative "../lib/clarion"

Clarion::CLI.start(ARGV)

Here’s the help output:

$ bin/clarion help

Commands:
  clarion analyze TICKET_ID    # Analyze a Jira ticket and suggest clarifications
  clarion help [COMMAND]       # Describe available commands or one specific command
  clarion ingest SUBCOMMAND    # Ingest data from various sources
  clarion ingest_all CLIENT    # Ingest Jira, Confluence, and GitHub data for a client
  clarion mcp                  # Start MCP server (for Claude Code integration)

$ bin/clarion help ingest

Commands:
  clarion ingest confluence    # Ingest Confluence pages for a specific space
  clarion ingest github        # Ingest GitHub repository data
  clarion ingest help          # Describe subcommands or one specific subcommand
  clarion ingest jira          # Ingest Jira tickets for a specific project

The CLI: Thor Subcommands

Thor for the CLI, nothing exotic. Here’s the skeleton:

module Clarion
  class CLI < Thor
    desc "analyze TICKET_ID", "Analyze a Jira ticket and suggest clarifications"
    option :verbose, type: :boolean, desc: "Enable verbose output"
    def analyze(ticket_id)
      validate_ticket_id!(ticket_id)
      analyzer = Clarion::Analyzer.new(ticket_id, verbose: options[:verbose])
      puts analyzer.analyze
    end

    desc "ingest_all CLIENT", "Ingest Jira, Confluence, and GitHub data for a client"
    option :limit, type: :numeric, default: 100
    option :parallel, type: :boolean, default: true
    def ingest_all(client_name)
      # Looks up client config, dispatches to parallel ingestion
    end

    desc "mcp", "Start MCP server (for Claude Code integration)"
    option :namespace, type: :string, desc: "Client namespace (auto-detected if omitted)"
    def mcp
      Clarion::McpServer.new(namespace: options[:namespace]).run
    end

    # Nested subcommand for individual ingestion
    desc "ingest SUBCOMMAND", "Ingest data from various sources"
    subcommand "ingest", Ingest

    private

    def validate_ticket_id!(ticket_id)
      return if ticket_id =~ /^[A-Z]+-\d+$/
      raise Thor::Error, "Invalid ticket ID format. Expected: PROJECT-123"
    end
  end
end

The Ingest subcommand is its own Thor class, giving us scoped commands for each data source:

# Analyze a ticket
$ bin/clarion analyze WR-123

# Ingest everything for a client (parallel by default)
$ bin/clarion ingest_all waystar --limit=500

# Or ingest individual sources
$ bin/clarion ingest jira --namespace=waystar --project=WR --limit=500
$ bin/clarion ingest confluence --namespace=waystar --space=WR
$ bin/clarion ingest github --namespace=waystar --repo=planetargon/waystar-web

# Start an MCP server for Claude Code
$ bin/clarion mcp --namespace=waystar

Every ingest command requires explicit --namespace and source-specific scoping flags (--project, --space, --repo). This is deliberate. Operations should never run without explicit client scope.

Client Configuration

Each client maps to a namespace, a Jira project, a Confluence space, and optionally GitHub repos:

# config/clients.yml
clients:
  waystar:
    namespace: waystar
    jira_project: WR
    confluence_space: WR
    vector_store: pinecone
    github_repos:
      - planetargon/waystar-web
      - planetargon/waystar-api

  piedpiper:
    namespace: piedpiper
    jira_project: PP
    confluence_space: PP
    vector_store: pinecone
    github_repos:
      - planetargon/piedpiper-app

  pierpoint:
    namespace: pierpoint
    jira_project: PPC
    confluence_space: PPC
    vector_store: chroma    # Local Chroma for testing

Note the per-client vector_store setting. One client can use Pinecone (shared, cloud-hosted) while another uses Chroma (local Docker instance) for development. The tool doesn’t care. The vector store abstraction handles it.

Embeddings: Simpler Than I Expected, Until They Weren’t

The ruby-openai gem makes the embedding call straightforward:

EMBEDDING_MODEL = "text-embedding-3-small"
EMBEDDING_DIMENSION = 1536

def generate_embedding(text)
  return Array.new(EMBEDDING_DIMENSION, 0.0) if text.nil? || text.strip.empty?

  response = @openai.embeddings(
    parameters: {
      model: EMBEDDING_MODEL,
      input: text.strip
    }
  )

  response["data"][0]["embedding"]
end

One thing I didn’t appreciate initially is that every embedding call costs money and adds latency. My early version used search, which takes a text string and internally calls OpenAI to generate an embedding before querying Pinecone:

# Before: each search() call generates its own embedding internally
similar  = @vector_store.search(query_text, filter: { source: "jira" })
docs     = @vector_store.search(query_text, filter: { source: ["confluence", "github"] })
resolved = @vector_store.search(query_text, filter: resolved_filter)

That’s three sequential calls to OpenAI’s embedding API for the exact same text, followed by three sequential calls to Pinecone. Six network round-trips, all in series.

Looking at the search method, you can see why. It generates a fresh embedding every time:

def search(query, filter: nil, top_k: 10)
  query_embedding = generate_embedding(query)  # Hits OpenAI every call
  search_by_vector(query_embedding, filter: filter, top_k: top_k)
end

The fix was two things at once: generate the embedding once, then pass that vector directly to search_by_vector (which skips the embedding step). Then run those three Pinecone queries concurrently:

# After: one embedding, three parallel vector searches
query_vector = @search.embed(query_text)

similar  = Thread.new { @search.search_by_vector(query_vector, source: "jira") }
docs     = Thread.new { @search.search_by_vector(query_vector, source: ["confluence", "github"]) }
resolved = Thread.new { @search.search_by_vector(query_vector, resolved_filter) }

The OpenAI embedding calls went from 3 to 1. The Pinecone queries stayed at 3 but now run concurrently instead of sequentially. Two wins from a small refactor.

I also learned about truncation the hard way. Some Jira tickets are enormous… long comment threads, embedded images described in markup, and extensive acceptance criteria. The embedding model has a token limit. We now truncate text at 30,000 characters before sending it for embedding.

Would’ve been nice to learn that from documentation rather than from a production error. Oh well.

The Vector Store Abstraction

I didn’t want to be locked into a single vector database, especially early on when I wasn’t sure which one would work best for us. So I built a simple abstraction layer. It’s a factory that returns different backends behind the same interface:

class VectorStore
  def self.new(namespace:, backend: nil)
    backend ||= ENV.fetch("VECTOR_STORE_BACKEND", "memory")
    case backend.downcase
    when "pinecone" then VectorStores::Pinecone.new(namespace: namespace)
    when "chroma"   then VectorStores::Chroma.new(namespace: namespace)
    when "memory"   then VectorStores::Memory.new(namespace: namespace)
    end
  end
end

All three backends implement the same base contract:

module VectorStores
  class Base
    attr_reader :namespace

    def initialize(namespace: nil)
      @namespace = namespace
    end

    def upsert(documents)
      raise NotImplementedError, "#{self.class}#upsert must be implemented"
    end

    def search(query, filter: nil, top_k: 10)
      raise NotImplementedError, "#{self.class}#search must be implemented"
    end

    def search_by_vector(vector, filter: nil, top_k: 10)
      raise NotImplementedError, "#{self.class}#search_by_vector must be implemented"
    end

    def embed(text)
      raise NotImplementedError, "#{self.class}#embed must be implemented"
    end

    def delete_all(namespace: nil)
      raise NotImplementedError, "#{self.class}#delete_all must be implemented"
    end

    def stats
      raise NotImplementedError, "#{self.class}#stats must be implemented"
    end
  end
end

Callers just use upsert, search, search_by_vector, stats. They never know or care whether they’re talking to Pinecone, Chroma, or an in-memory hash.

The Pinecone backend stores document text inside the metadata (Pinecone doesn’t have a native text field), then strips it back out on retrieval:

# During upsert: embed text into metadata
metadata = (doc[:metadata] || {}).merge(text: doc[:text])
{ id: doc[:id], values: embedding, metadata: metadata }

# During search: extract text back out, unescape newlines
matches.map do |match|
  result = match.dup
  if result["metadata"] && result["metadata"]["text"]
    text = result["metadata"]["text"]
    result["text"] = text.is_a?(String) ? text.gsub('\\n', "\n") : text
    result["metadata"] = result["metadata"].except("text")
  end
  result
end

This paid off quickly. We started with the in-memory backend (pure Ruby cosine similarity, persists to a JSON file) just to prove the concept worked at all. Then Chroma for local development. You can run it in Docker. No cloud account needed. Then Pinecone for the shared production dataset that the whole team can access.

Ingesting Messy Real-World Data

This is where things got messy.

Jira: Flattening the Ticket

Each Jira ticket gets transformed into a document with an ID, a text blob, and structured metadata:

def transform(ticket)
  key = ticket["key"]
  fields = ticket["fields"] || {}

  {
    id: "jira_#{@namespace}_#{key}",   # e.g., "jira_waystar_WR-123"
    text: build_text(key, fields),
    metadata: build_metadata(key, fields)
  }
end

The text blob concatenates everything meaningful about the ticket: the key, summary, description, comments (with author tags), labels, parent/subtask relationships, and any embedded Confluence links.

Jira’s rich text format is a nested JSON tree. Jira uses something called Atlassian Document Format (ADF) for ticket descriptions and comments. It’s not HTML. It’s not Markdown. It’s a deeply nested JSON structure with node types like paragraph, bulletList, taskItem, mention, inlineCard, and emoji. I had to write a recursive parser to walk that tree and flatten it into plain text:

class AdfParser
  def extract_text(adf_doc)
    return "" unless adf_doc.is_a?(Hash)
    extract_blocks(adf_doc).join(" ").strip
  end

  private

  def extract_blocks(adf_doc)
    return [] unless adf_doc["content"].is_a?(Array)
    adf_doc["content"].map { |node| format_block(node) }
  end

  def format_block(node)
    return "" unless node.is_a?(Hash)

    case node["type"]
    when "taskList" then format_task_list(node)
    when "bulletList", "orderedList" then format_list(node)
    else extract_from_node(node)
    end
  end

  def extract_from_node(node)
    case node["type"]
    when "text"      then node["text"] || ""
    when "hardBreak" then "\n"
    when "mention"   then "@#{node.dig('attrs', 'text') || 'user'}"
    when "emoji"     then node.dig("attrs", "shortName") || ""
    when "inlineCard", "blockCard" then node.dig("attrs", "url") || ""
    else inline_text(node)
    end
  end
end

Not complex, but the kind of thing you don’t anticipate until you see your first embedding full of raw JSON nodes. Thankfully, we can task Claude Code with figuring out some of this chaos.

Comment authors matter. We tag each Jira comment as [Team] or [Client] based on the commenter’s email domain:

def determine_author_type(email)
  if email.include?("@planetargon.com")
    "[Team]"
  elsif email.empty?
    ""
  else
    "[Client]"
  end
end

This matters more than I thought it would. The LLM can distinguish between internal engineering discussion and client-facing conversation when generating suggested questions.

GitHub: PRs, Issues, Docs, and Code

We pull READMEs, docs, PRs, issues, and source files. Honestly, the source code has been the least useful of the bunch. PRs and issues have the “why”… the discussion, the tradeoffs, the things that almost shipped but didn’t. Source files have the “what,” but without the surrounding conversation the embedding doesn’t give you much you couldn’t get from grep.

Batch Uploads and Deterministic IDs

Documents get uploaded to the vector store in batches of 20. Errors in one batch don’t abort subsequent batches:

class BatchUploader
  BATCH_SIZE = 20

  def upload(documents)
    documents.each_slice(BATCH_SIZE) do |batch|
      @vector_store.upsert(batch)
      @processed_count += batch.length
    rescue StandardError => e
      @error_count += batch.length
    end
  end
end

Every document gets a deterministic ID based on its source: jira_waystar_WR-123, confluence_waystar_12345_chunk_2, or github_waystar_waystar-web_pr_47. This means re-running ingestion overwrites old documents instead of creating duplicates. Engineers can re-ingest anytime without polluting the dataset.

When a Jira ticket updates, the next ingestion run replaces the old embedding with the new one. Same with Confluence pages and GitHub content. The vector store stays in sync with reality without complex change detection or deletion logic.

One gap we haven’t closed yet: deletion. When a Jira ticket gets deleted or a Confluence page is removed, the old embedding stays in the index. We have no cleanup strategy right now. It hasn’t caused real problems, but it’s on the list.

The tradeoff: someone needs to remember to run ingestion periodically. But the simplicity is worth it.

Parallel Ingestion with concurrent-ruby

When ingesting all sources for a client, the tool uses concurrent-ruby to run Jira, Confluence, and GitHub ingestions in parallel:

pool = Concurrent::FixedThreadPool.new(3)

futures = []
futures << Concurrent::Future.execute(executor: pool) { ingest_jira }
futures << Concurrent::Future.execute(executor: pool) { ingest_confluence }
github_repos.each do |repo|
  futures << Concurrent::Future.execute(executor: pool) { ingest_github(repo) }
end

# Wait for all to complete
futures.each(&:wait)

Thread-safe state tracking uses Concurrent::Hash:

@results = Concurrent::Hash.new
@timings = Concurrent::Hash.new
@status = Concurrent::Hash.new

After completion, the tool calculates time saved versus sequential execution and reports a speedup factor. In practice, parallel ingestion typically finishes in about 60% of the time sequential would take, since the API calls to Jira, Confluence, and GitHub can overlap.

Running an ingestion looks like this:

$ bin/clarion ingest_all waystar --limit=500

════════════════════════════════════════════════════════════
                  COMBINED DATA INGESTION
════════════════════════════════════════════════════════════

ℹ Client: waystar
ℹ Namespace: waystar
ℹ Vector store: pinecone
ℹ Jira project: WR
ℹ Confluence space: WR
ℹ GitHub repos: planetargon/waystar-web
ℹ Limit: 500 items per source
ℹ Mode: Parallel

  ✓ Jira (WR)                     Complete (487/500 processed)
  ✓ Confluence (WR)               Complete (245/500 processed)
  ✓ GitHub: waystar-web            Complete (498/500 processed)

════════════════════════════════════════════════════════════
                    INGESTION RESULTS
════════════════════════════════════════════════════════════

ℹ ✓ Jira: 487 processed, 0 errors (45.2s)
ℹ ✓ Confluence: 245 processed, 0 errors (38.1s)
ℹ ✓ Github Waystar Web: 498 processed, 0 errors (52.7s)

════════════════════════════════════════════════════════════
                   PERFORMANCE SUMMARY
════════════════════════════════════════════════════════════

ℹ Total documents processed: 1230
✓ Total time: 58.3s
ℹ Time saved vs sequential: 77.7s (2.3x speedup)

✓ Client 'waystar' is ready for analysis!

Retrieval and Re-Ranking

Raw cosine similarity gets you most of the way there, but not all the way. The vector search returns the 40 most similar Jira tickets, and some of them are similar for the wrong reasons… same boilerplate language, same component name, but not actually useful context.

The context builder generates one embedding, then runs three concurrent searches. Similar tickets. Resolved tickets filtered by component. Documentation from Confluence and GitHub.

def gather_all_context(ticket, ticket_id, current_key, created_time)
  query = @search.build_query(ticket)
  query_vector = @search.embed(query)

  similar_thread = Thread.new do
    results = @search.search_by_vector(query_vector, { source: "jira" }, 40)
    score_and_limit_results(results, ticket, current_key, created_time, 16)
  end

  resolved_thread = Thread.new do
    results = @search.search_by_vector(query_vector, resolved_filter, 12)
    format_resolved_tickets(results)
  end

  docs_thread = Thread.new do
    results = @search.search_by_vector(query_vector, { source: ["confluence", "github"] }, 32)
    process_and_limit_docs(results, ticket, ticket_id, created_time, 16)
  end

  {
    similar_tickets:  similar_thread.value,
    related_resolved: resolved_thread.value,
    documentation:    docs_thread.value
  }
end

After retrieval, I added two scoring tweaks that made a noticeable difference:

Relationship boost. If a retrieved ticket is a parent or subtask of the ticket being analyzed, its score gets a 1.5x multiplier:

def apply_relationship_boost(ticket_data, relationship_type)
  ticket_data[:relationship] = relationship_type
  ticket_data[:score] *= 1.5
end

Temporal decay. Tickets older than 7 days get a 0.7x multiplier. Older than 30 days, 0.3x:

def age_adjustment_params(days_before)
  return [0.3, "Created #{days_before} days before ticket"] if days_before > 30
  return [0.7, nil] if days_before > 7
  [nil, nil]
end

These aren’t machine learning models. They’re just multipliers applied after retrieval. I was surprised how much difference they made. A few lines of Ruby math moved the output from “interesting but noisy” to something I’d actually act on.

It’s still early days, I expect that we’ll likely need to tweak this a bunch as we see more real-world queries and get feedback from engineers.

The Prompting Side

Two things surprised me here.

First: structured JSON output. Huge deal. We set response_format: { type: "json_object" } on the LLM call, which means the response is always valid JSON. No regex parsing, no hoping the model follows your format instructions. The response comes back with a defined structure:

{
  "ticket_type": "feature",
  "clarity_assessment": "needs_clarification",
  "clarifying_questions": [
    {
      "question": "The question to ask the client",
      "rationale": "Why this matters for implementation",
      "reference": "WR-892: similar issue last quarter"
    }
  ],
  "suggested_acceptance_criteria": [
    "User can export all report types to PDF",
    "Export completes within 30 seconds",
    "Error message displays if export fails"
  ],
  "potential_edge_cases": [
    "Special characters in report data",
    "Very large reports (>10,000 rows)"
  ],
  "implementation_notes": "Brief notes on approach"
}

Once you have reliable structure, everything downstream gets simpler.

Second: the prompt is where your actual communication style lives. Ours doesn’t just say “generate clarifying questions”… it encodes how we actually talk to clients:

Instead of asking open-ended technical questions, frame them as confirmations:

“It sounds like this needs to work in Chrome. Should we also make sure it works in Safari and Firefox?”

Rather than:

“What browsers need to be supported?”

The prompt covers dozens of specific communication scenarios. A few examples from the actual prompt file:

When clients apologize for not being technical:

“No need to apologize. You’re describing exactly what we need to know. The ‘what’s broken’ is your expertise; the ‘why it’s broken’ is ours.”

When scope is creeping:

“There’s a lot of good stuff here. To make sure nothing gets lost, would it help to break this into separate tickets? That way we can track the export fix and the new filter feature independently.”

When clients describe workarounds they’re using:

“Good thinking on the CSV workaround. That’ll keep things moving. We’ll fix the PDF export so you don’t have to keep doing that extra step.”

When something is working as designed:

“So it turns out the system is doing what it was originally built to do, but I hear you that it’s not what you need it to do. Want us to write up a feature request to change this behavior?”

The prompt took real care to get right, but not because it was technically hard. As a client-services company we put a lot of thought into our communication style… how we ask questions, how we handle scope creep, how we respond when something is working as designed but not as the client expected. Baking that into the prompt mattered. We also have engineers from different regions and backgrounds, and anything that helps guide everyone toward a consistent, confident tone with clients is worth the effort.

This is the part that makes it ours and not just another RAG wrapper. The vector search finds the history. The prompt makes it sound like us.

We also maintain two separate prompt files. prompts/analyzer_default.md is for open tickets (“what’s unclear?”). prompts/analyzer_completed.md is for closed tickets (retrospective analysis). The tool detects the ticket’s status and selects the right prompt automatically. It’s a small touch, but it means the output is always contextually appropriate.

I expected engineers to be the primary users. The first people to actually build it into their workflow were our PMs. They’re in tickets all day, working with clients on acceptance criteria… and having suggested clarifying questions grounded in project history turns out to be directly useful for that conversation, not just for development. I should have seen that coming.

The MCP Surprise

I didn’t expect this part to become the most useful thing in the whole project.

The tool started as a CLI experiment. Run bin/clarion analyze WR-123 in your terminal, get output, copy what’s useful. It worked, but there was friction. You had to switch contexts, looking at a Jira ticket, looking at and jumping away from your editor, and remember the command syntax.

Having spent a bunch of time recently in Claude code, I wondered… could we bring this analysis directly into the editor? I think this took me less than two hours from “I wonder if this could be an MCP server” to “oh wow, it’s actually working”.

I quickly found the mcp gem, which implements Anthropic’s Model Context Protocol. MCP lets you expose a tool as a server that Claude Code can call directly. Here’s what the server looks like:

class McpServer
  def initialize(namespace: nil, working_directory: Dir.pwd)
    @namespace = namespace
    @working_directory = working_directory
    @client = resolve_client
  end

  def run
    server = build_server
    transport = MCP::Server::Transports::StdioTransport.new(server)
    transport.open
  end

  private

  def build_server
    MCP::Server.new(
      name: "clarion",
      version: Clarion::VERSION,
      tools: [Mcp::AnalyzeTool.build(@client)]
    )
  end
end

The MCP tool itself is built dynamically. The tool description is baked in with the client’s namespace and ticket prefix at startup time, so Claude Code knows exactly what it can do:

module AnalyzeTool
  def self.build(client)
    tool = Class.new(MCP::Tool) do
      tool_name "analyze_ticket"
      description "Analyze a Jira ticket and suggest clarifying questions " \
                  "and acceptance criteria. Scoped to client '#{client.namespace}' " \
                  "(ticket prefix: #{client.ticket_prefix})."

      input_schema(
        properties: {
          ticket_key: {
            type: "string",
            description: "Jira ticket ID (e.g., #{client.ticket_prefix}-123)"
          }
        },
        required: ["ticket_key"]
      )
    end
    # ... wire up call, validation, and analysis methods
    tool
  end
end

Each MCP server instance is scoped to a single client namespace. When an engineer is working in a client’s repository, they drop a small JSON config file at the repo root:

{
  "mcpServers": {
    "clarion": {
      "command": "/path/to/clarion/bin/clarion-mcp",
      "args": ["--namespace=waystar"]
    }
  }
}

Getting set up isn’t quite drag-and-drop. A new engineer needs to clone the repo, run bundle install, configure their own .env with API keys for OpenAI, Atlassian, GitHub, and Pinecone, then drop the right config file into whichever client repo they’re working in. Our team is used to juggling .env files across multiple projects, so this didn’t feel like a big ask… but it’s worth knowing upfront if you’re thinking about something similar.

The bin/clarion-mcp wrapper is a one-liner. It sets the working directory, then delegates:

#!/bin/bash
cd "$(dirname "$0")/.."
exec bundle exec ruby -Ilib bin/clarion mcp "$@"

Now they can ask Claude Code to “analyze WR-123” and get the full analysis inline. Clarifying questions. Suggested acceptance criteria. Edge cases. Implementation notes. All without leaving their editor.

Auto-detection from git remote. If the client’s repo is configured in clients.yml with its github_repos, you can even skip the --namespace flag. The server shells out to git remote get-url origin, parses the owner/repo slug, and looks it up automatically.

One gotcha worth mentioning: TTY output breaks MCP’s stdio transport. All those nice spinners and progress bars and colored output that make the CLI experience polished? They corrupt the MCP response stream. I had to suppress stdout during MCP calls:

def run_analysis(key)
  config = AnalyzerConfig.build(key, result_formatter: PlainTextFormatter.new)
  original_stdout = $stdout
  $stdout = File.open(File::NULL, "w")
  begin
    Analyzer.new(config).analyze
  ensure
    $stdout = original_stdout
  end
end

Small thing, but it would have been confusing to debug without knowing to look for it. We also have a separate PlainTextFormatter that outputs clean text for MCP, versus the ResultFormatter that uses colored boxes and unicode for the CLI.

Where It Gets Really Interesting: MCP in Combination

Clarion as an MCP server is useful on its own. But the thing that got me excited was running it alongside other MCP servers in the same Claude Code session.

Our engineers can have Clarion (our embedded project history), the Atlassian MCP (live read/write access to Jira and Confluence), and the GitHub MCP all connected at once.

The combination we’ve found most useful: analyze a ticket with Clarion, review the suggested clarifying questions, adjust the wording, then use the Atlassian MCP to post the comment directly on the Jira ticket. The whole loop closes without leaving Claude Code.

Cross-source research has been useful too. Ask “what do we know about how authentication works in this project?” and get results from Jira tickets where auth bugs were fixed, Confluence pages documenting the auth flow, and GitHub PRs where the auth code was changed. All from one query, scoped to that client. With GitHub MCP connected, you can then check whether the docs still match the actual code.

The underlying idea is that before anyone starts building, the ticket should be clear. Clarion sits at that boundary. The suggested questions aren’t generic… they’re informed by the specific history of this project. “Last time we did a PDF export on this project, Safari caused problems” is more useful than “have you considered browser compatibility?”.

Multi-Tenant Scoping: The Hard Constraint

One constraint that shaped everything: Planet Argon uses a single Atlassian account across most of our client projects (some clients own their own Atlassian accounts). Same Jira instance, same Confluence instance, one set of API credentials.

That means data isolation has to be enforced in our code, not by infrastructure boundaries. Every operation requires an explicit client namespace. The vector store uses that namespace to partition data. One Pinecone index. Many isolated namespaces. Ticket IDs are validated against the expected prefix before any analysis runs.

Granted, our engineers do have access to reference different clients at the same time in their Atlassian account, but the tool itself is always scoped to one client per run. That’s the important part.

The validation happens at multiple layers. In the CLI:

def validate_ticket_id!(ticket_id)
  return if ticket_id =~ /^[A-Z]+-\d+$/
  raise Thor::Error, "Invalid ticket ID format. Expected: PROJECT-123"
end

And again in the MCP tool, where it also checks the prefix matches the scoped client:

def validate_ticket_prefix!(key)
  unless key.match?(/^[A-Z]+-\d+$/)
    raise ArgumentError, "Invalid ticket ID format: #{key}. Expected: PROJECT-123"
  end

  prefix = key.split("-").first
  return if prefix == scoped_client.ticket_prefix

  raise ClientScopeError,
        "Ticket #{key} does not belong to client " \
        "'#{scoped_client.namespace}' (expected prefix: #{scoped_client.ticket_prefix})"
end

If you’re working in the waystar namespace and try to analyze PP-123, you get a clear error: "Ticket PP-123 does not belong to client 'waystar' (expected prefix: WR)". Not results from the wrong client.

It’s a simple system. Namespaces and prefix checks. Again, engineers technically have access to all clients’ data in Atlassian, but the tool enforces discipline. You have to be intentional about which client’s context you’re working in. We don’t want someone accidentally running an analysis against the wrong client’s project and making assumptions based on irrelevant history.

What’s Next

A few people on the team are using it regularly. I’m hoping that spreads in the coming weeks. Whether this becomes a genuine workflow change or an interesting experiment we eventually deprioritize… I genuinely don’t know yet. I’ll write a follow-up when there’s something real to report.

We’re using gpt-4o-mini for now because it was the easiest thing to get running and the output has been good enough that we haven’t felt pressure to switch.

Atlassian is building AI features into Jira and Confluence, and some of that will overlap with what we’ve built. But Atlassian’s tooling only knows about what’s inside Atlassian. It can’t see GitHub repos, PR histories, or how past implementations actually played out in code. Our tool bridges that gap… context across all three systems, shaped by how we work.

Our team is also experimenting more with LLM-assisted code generation. But this tool sits deliberately upstream of that. It’s about the collaboration layer. Making sure what we’re about to build is well-understood before anyone writes code. A perfectly generated pull request against a vague ticket is still a miss.

We’ll probably open source this eventually, but the codebase is full of references to real client projects in tests and config. Scrubbing that is on the list. Not the priority right now.

If you’re thinking about building something like this… just start. Ruby has what you need. The gems are there. It’s more approachable than it looks from the outside.

p.s. Oh, and did you notice I never mentioned Ruby 4 anywhere in this post? That’s because there’s nothing to mention. It just worked.

Most Developers Don’t Build New Things

Wed, 18 Feb 2026 00:00:00 +0000

The industry tends to celebrate beginnings.

New repositories. Clean architecture diagrams. The excitement of choosing tools before real constraints show up. First commits get attention because they feel like authorship.

Most developers, though, don’t spend their careers starting from scratch. They spend them stepping into systems that already exist, already have users, and already have decisions embedded in them.

You open the repository and there are hundreds of thousands of lines of code waiting for you. Patterns layered over time. Workarounds that solved real problems in earlier moments. Comments that hint at context you weren’t there for. You didn’t choose the framework version. You didn’t pick the database. You didn’t design the way billing logic is structured.

You inherited it.

That inheritance is the work.

The Rails Default Debate

This is why debates about what DHH changed in the default rails new template sometimes feel slightly disconnected from day-to-day reality.

Threads fill up with opinions about JavaScript bundling, database adapters, testing philosophy. The conversation centers on defaults and direction.

Meanwhile, most developers working with Ruby on Rails haven’t typed rails new in years, at least not on anything beyond a side project or experiment.

They’re inside a twelve year old system that has been upgraded across versions, shaped by product demands, team turnover, and business pressure. Their attention is on stability. On how to change something without breaking adjacent workflows. On whether a refactor will surface an edge case that only appears in production.

The generator shapes the beginning.

Maintenance shapes everything after that.

Software Has Second Acts

We often talk about software in terms of launch and decline, as if those are the only meaningful chapters. In practice, most valuable products spend the majority of their life in a long second act.

The second act is what happens after product-market fit, after early growth, after the architecture has already been bent once or twice. It’s when the team has turned over. When new engineers are maintaining code they didn’t write. When uptime and predictability matter more than novelty.

It’s the stage where you stop asking, “What should we build?” and start asking, “How do we keep this adaptable without destabilizing it?”

That’s the environment most engineers operate in.

Not at the starting line, but in the middle of a system that already has gravity.

Legacy Code Is Accumulated Context

A mature codebase is accumulated decision-making. Each file reflects what someone believed was reasonable under the constraints they faced at the time.

A couple of years ago you introduced an abstraction that felt thoughtful and clean. It simplified things. It made sense with what you knew then. Today it may feel slightly overbuilt or misaligned with how the system evolved. The code you once defended now requires explanation.

Legacy code is not a moral category.

It is accumulated context.

Most legacy systems were built by people responding to real constraints. That includes you. The second act is less about erasing that history and more about working within it deliberately.

The Rewrite Fantasy

The urge to rewrite usually comes from frustration. We could design this better. We understand the domain more clearly now. The stack feels dated.

The real cost of a rewrite isn’t just risk or budget. It’s attention.

The moment a team starts to think “we’re rewriting this anyway,” the current system quietly becomes second-class. Tests stop improving. Refactors are postponed. Documentation is deferred. People stop investing in clarity because the future version will “fix it.” I’ve written more about this dynamic in The Cost of Leaving a Software Rewrite on the Table, because it shows up more often than teams expect.

Months pass. Sometimes years.

When the rewrite finally ships, it inherits the same domain complexity, the same business pressures, and often a team that hasn’t practiced maintaining what they already had.

Rewrites don’t just reset code. They reset discipline.

That’s the cost teams underestimate.

Stewardship Is the Craft

Most careers unfold inside inherited systems. The skill is learning how to move those systems forward without pretending they began today.

We inherit. We understand. We stabilize. We extend. We improve what we can without destabilizing what already works.

This kind of work rarely attracts attention. It looks like incremental improvement and steady compounding over time.

But if most of your career is going to be spent in the second act, then the real question isn’t whether you get to start something new.

It’s whether what you inherit gets better because you were there.

The Handoff Test

Mon, 16 Feb 2026 00:00:00 +0000

I keep hearing the same story in conference hallway tracks. An engineer leans in and tells me their old boss or client still texts them every four to six months with a “quick question.” There’s usually a slight eye roll. They’ve moved on. They’re not being paid anymore. It feels like a boundary issue.

Then I ask what the question was.

It’s rarely random. It’s about the custom annual report they used to run before board meetings… whether it’s safe to delete a specific SPF value in DNS… why three staging hostnames are still sitting in the load balancer and the new DevOps person is afraid to touch them. Sometimes it’s a background job chain that behaves strangely under load. Sometimes it’s a migration that looked simple but has sharp edges nobody remembers.

These aren’t casual interruptions. They’re loose threads that never got tied off.

And that’s when the uncomfortable question shows up…

Did we fully hand off the system before we left?

What We Really Mean by Handoff

In long-lived systems, knowledge doesn’t live only in the codebase. It lives in decisions, tradeoffs, and context. The repository might show what the system does, but it rarely captures why it ended up there or what constraints shaped it.

While you’re still inside the system, none of this feels fragile. You answer quickly. You remember the nuance. You act as the compression layer between complexity and the rest of the team. It feels efficient and, if we’re honest, a little flattering. Being the one who “just knows” carries quiet status.

The risk appears later.

If only one person can safely interpret parts of the system, succession hasn’t happened. When that person leaves, the system doesn’t just lose a contributor. It loses confidence. The code still runs. The infrastructure still exists. But people hesitate before touching it. That hesitation is usually what triggers the text.

The House You Sold

Think about selling a house you’ve lived in for years. You know which breaker controls the backyard outlet. You know the upstairs shower takes a minute before it gets hot. You know where the sprinkler shutoff is hidden and which switch looks functional but does nothing.

You move out without leaving notes.

Three months later, the new owner texts asking about a breaker or a pipe noise. They aren’t trying to pull you back into ownership. They inherited something that works but feels uncertain because the context behind it is invisible.

I’ve bought a house from people who were excellent stewards. They labeled panels, left manuals, and wrote down the quirks. It made a meaningful difference. When I did text them once or twice, I had already flipped switches, checked breakers, and read the binder before reaching out. The message wasn’t laziness. It was caution.

You don’t owe infinite support after you sell a house, but you do owe a clean handoff while you still own it.

Software systems aren’t any different. If someone has to text you to feel safe deleting a DNS record or modifying a report query, the system may function technically… but it wasn’t fully transferred operationally.

The Part That’s Hard to Admit

There’s a pattern underneath those hallway conversations.

You can be the one they still text, or the one they never have to.

Being the one they still text can feel good. It confirms that you were critical. It reinforces the idea that you were the person who truly understood the system. There’s status in being indispensable, even if we don’t consciously chase it.

But indispensability is often just concentrated context, and concentrated context is fragile.

If your absence creates anxiety, you didn’t build resilience. If your absence creates confidence, you did. That difference has nothing to do with generosity after you leave. It has everything to do with whether you treated knowledge as something to hold or something to distribute.

There’s also no harm in changing your phone number. That’s definitely cheaper. It just doesn’t fix the underlying issue.

Run the Handoff Test

Open a blank document and write: “If I left tomorrow…”

Then list what would likely trigger a text four to six months later. Be specific. Would someone hesitate to run the annual board report without your guidance? Would they avoid touching a background job because they don’t fully understand its retry behavior? Would they pause before cleaning up infrastructure because they can’t see what depends on it? Are production accounts or key decisions still too closely tied to your memory?

This list isn’t an accusation. It’s a map of concentrated knowledge.

Each item marks a place where the system depends more on familiarity than on structure. It shows you where succession planning for code ownership hasn’t happened yet. Many engineers quietly wonder how things are going after they leave… did the migration succeed… did the architecture hold up… did the team refactor the risky part? When I ask whether they’ve reached out to find out, most haven’t.

That hesitation tells you something.

This Is Structural, Not Just Personal

Handoff isn’t just an individual virtue. It’s an organizational expectation. Engineering leaders should design for it, and teams should normalize it as part of professional completion. If your culture rewards heroics but never budgets time for transfer, you’ll recreate the same dependency patterns over and over. Engineers will leave, and the same operational uncertainty will resurface.

Succession planning for code ownership isn’t documentation theater. It’s risk management. It ensures systems can evolve without leaning on someone who no longer works there. Engineers need to externalize context. Organizations need to create space for that work.

Replaceability isn’t weakness. It’s maturity.

Redefining Done

Most teams define done as merged, tested, and deployed. That keeps velocity high. For long-lived systems, done should also include transferability. Someone else can run the board report without fear. Someone else can rotate keys confidently. Someone else can remove a staging hostname or refactor a risky job without Slack archaeology.

The real question isn’t whether you’ll ever get that text.

It’s whether you left the system in a state where they needed to send it.

I Didn’t Want AI to Be Good at This

Thu, 12 Feb 2026 00:00:00 +0000

Over the past few months, I’ve been begrudgingly coming around to something I didn’t expect to admit publicly: AI is getting legitimately useful at building software. Not magical. Not autonomous. Not “paste in requirements and press BUILD.” We’re far from that. But the tooling has crossed a threshold where it meaningfully lowers friction in ways I can no longer dismiss.

What surprised me most isn’t that it can generate code. It’s that the cost of context has dropped. Exploring an idea. Scaffolding a feature. Writing tests. Refactoring awkward logic. Documenting decisions. Iterating without feeling like you just signed a six-month commitment.

For someone who has spent over two decades maintaining real systems, that shift isn’t abstract.

It changes the calculus.

We’ve Been Here Before

When I first started building web applications in the early 2000s, nearly everything was custom. If your company wanted software that matched how you actually worked, you built it. That was the default.

Then SaaS matured.

Suddenly you didn’t have to maintain your own systems. You could buy something that handled seventy to eighty percent of what you needed. On paper, it was obvious. Lower upfront cost. Someone else handles upgrades. Predictable pricing. Fewer late nights worrying about infrastructure.

For many organizations, that was the right move.

But over time, something subtle happened. Companies began shaping themselves around generic tools instead of shaping tools around what made them different. The software worked… mostly. But it wasn’t built around their secret sauce. It was built for a “company like yours.”

That tradeoff made sense when custom felt heavy and risky.

It feels different now.

The Economics of Context Just Changed

I’ve built a consultancy around the idea that software is heavy. Context is fragile. Continuity takes intention. We’ve helped organizations maintain and evolve applications that other teams walked away from.

So when the cost of building drops, an uncomfortable question shows up: if rebuilding gets cheaper, what does that mean for everything we optimized around maintaining?

Recently, I replaced a small SaaS subscription we were paying about $80 per month for. It was a Slackbot that tracked birthdays and anniversaries for our team and clients. Quiet. Useful. Forgettable.

Rebuilt it in half a day.

It’s small. Focused. It does exactly one thing. The maintenance footprint is tiny. No sprawling feature roadmap. No abstraction layers for hypothetical users we’ll never have.

That constraint is the feature.

And it got me thinking about something bigger.

Build Around Your Secret Sauce

The most interesting software I’ve worked on over the years wasn’t generic. It wasn’t interchangeable. It was built around what made a particular organization different.

Their workflows.
Their judgment.
Their weird edge cases.
Their advantage.

…their secret sauce.

Recently, I’ve been building a personal project for my band. It’s a custom CRM built for a user base of… me and a few of my bandmates.

(Yes, The Mighty Missoula. Shameless, I know.)

The tool tracks relationships with other musicians in the Pacific Northwest, surfaces shows we might want to attend, and nudges us when we haven’t connected in a while. Under the hood, it ingests messy event data from APIs and scraped sites where nothing is structured the same way twice.

Band names aren’t consistent. Sometimes “The” matters. Sometimes it doesn’t. Sometimes a band in Bolivia shares a name with a group we’ve played with a few miles from home. Event data is messy because humans are messy.

That mess is not a bug.

It’s reality.

A few years ago, I would have assumed weeks of plumbing before getting anything usable. Instead, I’ve been iterating quickly on a Rails 8 app, hanging out inside some of my newer CLI workflows, refining heuristics and tightening assumptions as I go.

It isn’t perfect. There are bugs. There are mismatches. But the code being produced and then reviewed through my own workflows is better than a lot of code I’ve seen over the years.

Not the best I’ve ever seen.

But better than the code written by people who cared “just enough” to get it working and move on.

The cost of caring more is cheaper now.

And that changes what’s possible when you’re building around something that actually matters to you.

The Seventy Percent Trap

We’ve been paying for a CRM for years. Thousands per year. And if I’m honest, nobody loves using it. We scatter information across other tools anyway. Conversations live in email. Notes in docs. Context in Slack. The CRM becomes the place we update because we’re supposed to.

It covers maybe seventy percent of what we need.

But our relationships, our way of thinking about clients, our actual differentiators… they don’t live comfortably inside its abstractions.

Do we really need to keep spending that money?

Or have we been tolerating software that flattens our secret sauce because rebuilding felt too heavy?

This isn’t an argument for rewriting everything. Rebuilding generic systems just because you can is ego. Reclaiming the parts of your workflow that actually define you is strategy.

SaaS still makes sense for commoditized systems. Payroll. Accounting. Infrastructure. The boring parts that don’t differentiate you.

But when the workflow itself is your advantage… when it shapes how you think, decide, and relate… settling for seventy percent might be more expensive than it looks.

Maybe this moment isn’t about replacing everything.

Maybe it’s about selectively reclaiming the parts that make you different.

Humans in the Loop

Tue, 20 Jan 2026 20:03:36 +0000

The Oh My Zsh core team recently met up in person at GitHub Universe in San Francisco. Getting the maintainers into the same room matters more than most people realize. It strips away the abstractions and forces the conversation back to reality… what’s working, what’s breaking, what’s quietly draining energy, and what’s worth protecting long term.

We spent a good amount of time talking about AI. Not as a culture war or a prediction exercise, but as something already embedded in our day-to-day work. It shows up in our jobs, our creative projects, our personal workflows, and increasingly, in open source contributions to projects like Oh My Zsh. We don’t all share the same worldview on AI usage. That’s fine. Alignment on outcomes matters more than agreement on philosophy.

What we do share is stewardship of a project that millions of people rely on. And stewardship means occasionally slowing down long enough to name a problem instead of pretending it’ll sort itself out.

The pattern we couldn’t ignore

Over the past year, we’ve seen a noticeable increase in contributions that appear to lean heavily on AI tooling. That, by itself, is not a problem. People should use whatever tools help them learn and build. Forks are a playground. Experimentation is healthy.

What changed was the shape and cost of the work landing on maintainers’ desks.

We’re seeing larger pull requests from first-time contributors. Broader scope than necessary. Changes that touch parts of the codebase unrelated to the stated goal. PR descriptions and follow-up comments that feel polished but oddly disconnected from the actual implementation. In some cases, we genuinely can’t tell whether the contributor understands the changes they’re proposing.

That uncertainty matters because review is the bottleneck. Not code generation. Review. When a PR is sprawling, optimistic, and hard to reason about, it doesn’t matter how fast it was produced. It consumes volunteer time. AI doesn’t remove that constraint. In many cases, it amplifies it.

We needed clarity, not vibes

At some point, “we’ll handle it case by case” stops being fair to contributors and exhausting for maintainers. We needed something explicit we could point to. Not a moral stance. Not a ban. Just clarity around expectations and accountability.

The team agreed that I’d take the first pass at researching how other open source projects are approaching AI usage and propose a path forward. We already maintain a private GitHub project where we collaborate on behind-the-scenes decisions… security considerations, moderation questions, and process changes that don’t belong in public threads. That gave us space to pressure-test ideas before bringing anything to the community.

What I found was interesting. Many projects treat AI as a separate category entirely, with standalone policies layered on top of CONTRIBUTING.md. Others get extremely prescriptive, trying to enumerate when AI is allowed, how much is allowed, and under what circumstances.

I understand the impulse. But it also felt like a distraction.

CONTRIBUTING.md already exists to describe how humans contribute responsibly. Tools change. Responsibility doesn’t. Treating AI as something fundamentally different risks avoiding the harder conversation… ownership.

Where does AI start and end anyway?

If your editor suggests a line of code, is that AI? If autocomplete finishes a function, does it count? If a tool rewrites your PR description, is that different from asking a colleague to proofread it? If a Copilot agent updates a handful of links, is that categorically different from doing a global search-and-replace by hand?

Bright lines fall apart quickly. In reality, maintainers rely on judgment, pattern recognition, and experience. We always have. AI just makes it cheaper to submit work that looks plausible without being deeply understood. Volume goes up. Review cost goes up with it.

So we didn’t try to play detective. We’re not interested in policing tooling. We’re interested in accountability.

The approach we took

We chose to integrate guidance about AI-assisted contributions directly into our existing contribution guidelines, instead of treating it as a separate class of work. Concretely, that meant adding a “Working with AI tools” section to our CONTRIBUTING.md and updating our PR templates so that contributors can disclose how they used AI when it’s relevant to their work.

The standard is straightforward: if you submit code to core, you own it. You must understand every line. You must be able to explain what changed and why. You must test what you touched and keep the scope focused. And if something breaks, you should be able to debug it without regenerating your way out of the problem.

That’s not an “AI policy.” That’s basic stewardship.

If you’re curious, the pull request where we proposed and merged these changes is ohmyzsh/ohmyzsh#13520.

A quick story, because this matters

We’ve already had people reach out to say they’re done using Oh My Zsh because I once used GitHub Copilot to help update a few links in the codebase and referred to a class of low-effort contributions as “slop.”

Yes, I could have done those updates manually. I’ve been writing shell scripts for decades. The point wasn’t capability. The point was experimentation.

I opened a GitHub issue, let the Copilot agent propose a change, and then did what maintainers always do: we reviewed it. A human noticed a problem. We modified the PR. We merged it.

Exactly like we always have.

The only difference is that I didn’t need to fire up my editor to replace a handful of URLs. The human checkpoints didn’t disappear. Responsibility didn’t disappear. Review didn’t disappear.

That’s the entire point.

What hasn’t changed

Nothing gets merged without human review. Every approval still represents a maintainer making an informed decision on behalf of the community. AI doesn’t remove that responsibility. It increases it.

We reserve the right to ask contributors to explain their code. To show how they tested it. To narrow scope. To revise. To collaborate. And yes… to decline changes that don’t meet the bar.

Not because we’re precious about the code. Because volunteer time is the most finite resource in open source.

Oh My Zsh exists to make the terminal a little more delightful for humans, keystroke by keystroke. If your contribution moves us in that direction, we’re excited to review it. If it reads like output optimized for confidence instead of clarity, we’ll say no.

We’ll be friendly about it. But we’ll say no.

If you want to follow along, the project lives at github.com/ohmyzsh/ohmyzsh, and the public-facing home for documentation and installation is ohmyz.sh.

Tools evolve. Stewardship remains a human job.

Why So Serious?

Mon, 01 Dec 2025 00:00:00 +0000

The question Sheon Han poses — “Is Ruby a serious programming language?” — says a lot about what someone thinks programming is supposed to feel like. For some folks, if a tool feels good to use… that must mean it isn’t “serious.”

Ruby never agreed to that definition. If it did, I missed the memo.

If you arrived late, you missed a chapter when the language felt like a quiet rebellion. The community was small. The energy was playful. Ruby tapped you on the shoulder and asked what would happen if programming didn’t have to feel intimidating… what might be possible if clarity and joy were allowed.

The early skeptics were predictable. Java architects. Enterprise traditionalists. Anyone whose identity depended on programming being a stern activity. They said Ruby was unserious. And the community mostly shrugged… because we were busy building things.

Ruby made programming approachable. Not simplistic… approachable. That distinction matters. It helped beginners see the path forward. It helped small teams build momentum before anxiety caught up. It helped experienced developers rediscover a sense of lightness in their work.

This is why bootcamps embraced it. Why tiny startups found traction with it. Ruby wasn’t trying to win benchmarks… it was trying to keep you moving. When you’re creating something new, that matters far more than the theoretical purity of your type system.

And yes… critics love the Twitter example. But look closer. Ruby carried them further than most companies will ever reach. They outgrew their shoes. That’s not an indictment… that’s success.

In my world… running a software consultancy for a few decades… I’ve never seen a team fail because they chose Ruby. I have seen them fail because they chose complexity. Because they chose indecision. Because they chose “seriousness” over momentum. Ruby just needed to stay out of the way so people could focus on the real work.

And while folks keep debating its “credibility,” the receipts are plain. Shopify moves billions through Ruby. Doximity supports most physicians in the US with Ruby. GitHub held the world’s source code together for years using Ruby. This isn’t sentiment. This is proof.

What outsiders often miss is the culture. Ruby attracts people who care how code feels to write and read. Not because of nostalgia… but because most of our careers are spent living inside someone else’s decisions. Joy isn’t a luxury. It’s how sustainable software gets made.

I don’t know Sheon personally, but I’m guessing we have as much in common about music tastes as we do whether _why’s Poignant Guide to Ruby made any sense to them. And that’s fine. That’s actually the point.

And on that note… there’s one thing I genuinely agree with Sheon about. Ruby doesn’t seem to be for them. That’s not a failure of the language. That’s just taste. Some people like jazz. Some like metal. Some prefer the comfort of ceremony. Ruby has never tried to convert anyone. It simply resonates with the people it resonates with.

Since we’re noting taste, I’ll add something of my own. As an atheist, it feels oddly appropriate to mention my lack of religion here… mostly because it mirrors how strangely irrelevant it was for the article to bring up Matz’s religion at all. It didn’t add context. It didn’t deepen the argument. It was just… there. A detail reaching for meaning that wasn’t actually connected to the point.

Sheon mentions approaching Ruby without “the forgiving haze of sentimentality.” Fair enough. But the sentiment wasn’t nostalgia. It was gratitude. Gratitude for a language that centers the human being. Gratitude for a community that believes programming can be expressive. Gratitude for a tool that makes the work feel lighter without making it careless.

But here’s the part the discourse keeps missing… this isn’t just about the past.

The future of programming is fuzzy for everyone. Anyone claiming to have the master recipe for what’s coming is bullshitting you. The future won’t be owned by one paradigm or one language or one ideology. It’ll be a blend… a messy collage of ideas, old and new, borrowed and rediscovered.

And in that future… Ruby’s values aren’t relics. They’re an anchor. Readability will matter more as AI writes more code. Maintainability will matter more as products live longer. Joy will matter more as burnout becomes the default state.

And if you need a reminder that seriousness isn’t the reliable signal people wish it were…

The serious candidate doesn’t always get elected.
The serious musician doesn’t always get signed.
The serious artist doesn’t always sell.
The serious man doesn’t always find a serious relationship.
The serious startup doesn’t always find product-market fit.
The serious engineer doesn’t always write the code that lasts.
The serious rewrite doesn’t always solve the real problem.

Culture doesn’t reliably reward the serious. Neither does business.
It rewards the resonant. The clear. The human. The work that connects.

Ruby has always leaned toward that side of the craft. Toward the part of programming that remembers people are involved. Toward the part that says maybe the code should serve the team… not the other way around.

And honestly… I think unserious people will play an important role in the future too. The curious ones. The playful ones. The ones who keep the door propped open instead of guarding it. They’ll keep the industry honest. They’ll keep it human.

So is Ruby “serious”? I still think that’s the wrong question.

A better one is… does Ruby still have something meaningful to contribute to the next chapter of software?

It does.
And if that makes it “unserious”… maybe that’s exactly why it belongs in the conversation.

Who Keeps the Lights On?

Mon, 20 Oct 2025 00:00:00 +0000

Every so often, someone in the Ruby community will ask,
“So… what does Planet Argon actually do these days?”

Fair question.

We’re not a startup factory.
We don’t parachute in to build a shiny MVP, disappear, and leave you with a maintenance headache.
Most of our work begins after the launch party.

We get the call when the freelancer moves on.
When the agency shifts its focus.
When the last in-house developer, the one who knows every corner of the codebase, decides it’s time to retire.

It’s rarely a crisis.
It’s usually a quiet realization…
“This system runs part of our business. We can’t afford for it to fail… but we don’t need a full-time team to babysit it.”

That’s where we come in.

Maybe it’s a nonprofit whose original freelancer built their Rails app years ago and has since moved on. The app still runs their core operations, but no one has touched dependencies or upgrades in ages. They just need a steady hand to bring it up to date and keep it safe.

Or it’s a company that hired a creative agency to build a beautiful customer portal. The agency has moved on to new projects, and now the client just needs someone dependable to keep it healthy, fix bugs, and plan for what’s next.

Sometimes it’s a long-time engineer getting ready to retire… the one who built and maintained an internal system that quietly powers part of the business. Leadership doesn’t want to rebuild a whole dev team. They just want to make sure the software ends up in good hands.

These are the calls we get.

We take over the systems that keep organizations moving… the internal tools, customer portals, and business-critical Rails apps that quietly power something larger. They’re not the business, but they’re essential to it.

We step in, steady the ground, document what exists, and help plan what’s next.

Here’s the part most people miss:

Maintaining software isn’t “keeping the lights on.”
It’s innovation… the quiet kind.

It’s the discipline of protecting momentum instead of resetting it.
The craft of helping teams evolve what they already have instead of pretending a rewrite will fix their habits.

Rewrites aren’t always progress.
Sometimes they’re just an expensive way to forget what you’ve already learned.

So we focus on the in-between years… the seasons where your software still works but needs care, clarity, and a path forward.

We modernize what matters, archive what doesn’t, and give teams confidence that their systems will keep running while they decide the bigger questions:

Should we extend this?
Replace it?
Retire it?

That’s the second act we specialize in.
Not the spotlight moment… the sustained performance that follows.

Because good software deserves a second act.
And someone dependable to keep the lights on when everyone else chases the next big thing.

🌍 About Planet Argon

For the past 20+ years, Planet Argon has helped organizations sustain and evolve the software they depend on, often Ruby on Rails applications that have outlasted the people who built them.

We help teams reduce risk, modernize their systems, and build a plan for what’s next.
If that sounds like a challenge your organization is facing, we’d love to hear from you.

Architecture for Contraction

Mon, 13 Oct 2025 00:00:00 +0000

We’ve spent the last decade optimizing for scale. How do we handle more traffic? More users? More engineers? The assumptions were baked in: Growth is coming. Prepare accordingly.

So we split things apart. We mapped services to teams. We built for the org chart we were about to have.

Then 2023 happened. And 2024. And now 2025.

Turns out, the future isn’t always bigger.

The Question Nobody’s Asking

What if your team gets smaller? Not as a failure scenario. As a design constraint.

What if you architect with the assumption that in three years, you’ll have less capacity than you do today? Less engineers. Less time. Less runway to maintain complexity.

How would that change what you build right now?

The Playbook We Borrowed Doesn’t Fit

A lot of engineering leadership came from places where growth was a given. Amazon. Google. Netflix. Facebook. They brought their playbooks with them. Microservices. Team autonomy. Service boundaries.

Great ideas. When you have the teams to staff them.

The rationale made sense: Big teams step on each other’s toes. You need boundaries so people can move fast without coordination overhead. But most companies don’t grow like FAANG. Most companies hire in waves and contract in cycles.

Yet we’re still designing like growth is inevitable.

Most of the splitting we do isn’t for compliance or security. It’s organizational. We split things because we have teams. And teams need ownership. Fair enough. But then what happens when the teams go away and the repos stay?

The Repo-to-Engineer Ratio Nobody Tracks

Here’s a question I keep coming back to: What’s a healthy ratio of engineers to repos?

If you have 15 engineers responsible for 50 repos, something’s wrong. Not touching them. Just… responsible for them. Who’s keeping those repos updated? Who’s patching dependencies? Who’s maintaining CI/CD pipelines across all of them?

Here’s what usually happens: You have a team of 15 engineers and 14 of them aren’t even thinking about those 50 repos. It’s that one hyper-motivated engineer who created them all. The one who knew where everything was. The one who kept mental track of dependencies and deployment quirks.

Then they got a new job last year.

Now you have 50 repos. And nobody who really owns them.

Some companies solve this with platform teams. Dedicated engineers who keep the infrastructure healthy so product teams can focus on features. Great strategy. If you can afford it.

But what about the teams with 10-15 engineers who already have 30-50 repos and no platform team? They don’t have a platform team. They are the platform team. And the product team. And the infrastructure team.

Every repo is another thing to maintain. Another place for secrets to live. Another pipeline to keep green. And when that one person who understood how it all fit together leaves? You’re left holding the bag.

Redundancy vs. Excess

A resilient team isn’t one that can do everything. It’s one that can absorb change.

Redundancy is about people, not systems. It means two people can deploy. Three people understand the payment flow. Someone can go on parental leave and the app doesn’t fall apart. It means you’re not hit by the bus factor. That dreaded moment when the one person who knows how something works leaves and you’re stuck reverse-engineering their decisions.

Redundancy is good. It’s insurance against reality.

Excess is different. Excess is ten services that could’ve been three. Four repos when one would do. Coordination overhead that only makes sense if you have twice the people.

We need redundancy. We can’t afford excess.

Design for the Team You Might Have

Here’s a thought experiment: What if you designed your architecture assuming your team would be half its current size in two years? Not because you’re pessimistic. Because you’re realistic.

Would you still split that app into twelve services? Would you still introduce that new framework? Would you still custom-build that thing you could’ve used a library for?

Maybe. But you’d think harder about it.

What This Looks Like in Practice

Architecture for contraction means:

Prefer monoliths until you have a really good reason not to. Splitting things up creates coordination costs. Make sure you can afford them long-term. And “we might hire more engineers” isn’t a good enough reason.

Count your repos. Seriously. How many do you have? How many engineers touch them regularly? Is that ratio sustainable if three people leave?

Optimize for fewer moving parts. Every service is another thing to deploy, monitor, and maintain. Every repo is another place things can break.

Build for handoffs. People leave. They go on vacation. They take parental leave. Your architecture should assume the person who built it won’t always be around to maintain it.

Reduce cognitive overhead. If it takes three weeks to onboard someone, your architecture is too complex. Simplify until it takes three days.

Resist the urge to “get ahead of it.” You don’t need the architecture for 100 engineers when you have 20. You really don’t.

So What Do We Do?

Start asking different questions:

Not “how do we scale this?” but “how do we keep this simple?”

Not “what does this look like at 10x?” but “what does this look like at 0.5x?”

The playbook for growth is everywhere. It’s well-documented. It’s what got funded for a decade.

But we need a different playbook now. One that optimizes for durability, not growth. One that assumes less, not more. One that doesn’t mistake complexity for sophistication.

Because the team that can do more with less isn’t just efficient. It’s resilient.

And resilience is what we need right now.

Need Help Getting There?

If you’re reading this and thinking “we have 50 repos and the person who understood them all left last year,” you’re not alone.

A lot of teams find themselves maintaining complexity they didn’t choose and can’t afford to rewrite. You don’t need a full platform team. You need someone who can help you consolidate, simplify, and build redundancy into what you actually have.

That’s what we do at Planet Argon. We work as a fractional platform team—helping Rails teams reduce complexity, improve maintainability, and build systems that don’t require heroics to keep running.

If that sounds like something your team could use, let’s talk.

Organizations, Like Code, Deserve Refactoring

Thu, 09 Oct 2025 00:00:00 +0000

I’ve been thinking about what happens when open source organizations hit their breaking point… when funding dries up, relationships fracture, and everyone’s scrambling to make sense of what went wrong.

It turns out, the patterns look familiar.

The Organic Growth Problem

Open source projects rarely start with governance documents. They start with people solving problems. Infrastructure gets donated. Roles emerge organically. Someone’s AWS account becomes the infrastructure. Someone’s time becomes the bottleneck. Someone’s relationships become the organization.

This works remarkably well… right up until it doesn’t.

The moment you try to formalize what’s been organic, you discover all the implicit assumptions. Who actually owns this? Who’s been paying for it? What happens when the donor stops donating? When organizations merge, do they write divorce papers just in case?

Usually not. Because that feels pessimistic. And besides, everyone’s too busy keeping things running to plan for things falling apart.

This whole situation has left me thinking about Oh My Zsh. We’ve established some levels of governance, but we have such a simpler situation today than this one. It kind of makes me glad that I get to keep things lean. But we’ve also been participating in open source security trainings, and they’re highlighting a lot of policies we need to get in place. Things that I don’t think most of us ever should worry about until we need to worry about them in our projects.

Much in the same way that I don’t think a brand new startup should be worrying about their employee handbook before their first few hires. Just enough works enough until it just doesn’t. Most of us haven’t had to cross that divide ourselves.

When Multiple Pressures Converge

Here’s what makes these situations messy: everything happens at once.

Funding pressures don’t arrive neatly sequenced. They pile up. Employment situations change. Personal relationships deteriorate. Governance questions that seemed theoretical become urgent. And everyone’s making decisions with incomplete information, under time pressure, believing they’re doing the right thing.

No one’s operating with the full picture. Not the board. Not the staff. Not the donors. Not the community. Everyone’s got fragments and they’re trying to construct meaning from partial data.

Okay, Quick Side Quest.

At RailsConf 2024, Ruby Central announced the end of the conference, then committed to one final edition in 2025. They reached out about sponsorship from Planet Argon.

I had questions. They were committing significant resources to one more event… at a to-be-determined location on a to-be-determined date. If they were focusing on RubyConf going forward, this felt like an opportunity to refocus sooner rather than later.

I explained we were exploring ways to contribute more in the next fiscal year, but this particular decision didn’t resonate from a sponsor perspective. As a Rails developer, I appreciated the gesture. As a potential contributor, I saw resources going toward something undefined when regional conferences were already filling the void.

They explained they hoped the event would help recover losses through sponsorships and ticket sales. It was a bet that doesn’t appear to have paid off.

(I was honored to be invited to speak at the very last RailsConf and glad it happened!)

Here’s what’s interesting: I’m defending Ruby Central’s right to continue existing despite my questions about that decision. Maybe that reveals something about residual trust. About believing in a mission even when you question specific tactical choices.

Let’s be honest about sponsorships, too. They’re marketing. Logo placement has value… access to an audience, visibility on event pages, search engine rankings. When people call for sponsors to demand their logos be removed, they’re obviously not accounting for the downsides of not getting what you paid for. But I guess if you think Ruby Central is Goliath and irredeemable, then sure, I understand how your logic would arrive at that.

I just don’t think it’s that simple.

Anyway, that’s my commit to this story. Let’s get back to the main branch.

The Rewrite Temptation

When code gets messy, there’s always someone who wants to start over. Throw it all out. Rebuild from scratch. This time we’ll do it right.

I’ve spent years arguing against the big rewrite. I’m (almost always) firmly Team Refactor.

Why? Because rewrites discard something precious: the accumulated wisdom embedded in the system. Every line of code represents decisions made, problems solved, edge cases discovered. Someone spent time… their creativity, their care, their effort… building solutions that work.

Organizations are the same. Years of relationship-building. Trust earned through reliability. Lessons learned from mistakes. Systems developed through trial and error. That institutional knowledge has real value, even when the current state feels messy.

The rewrite impulse assumes the problem is the thing itself. But usually, the problem is that we’ve outgrown the original structure without evolving it. The answer isn’t demolition. It’s thoughtful renovation.

Organizations face the same temptation. When things get complicated, there’s a seductive simplicity to “defund and rebuild.” Start fresh. New governance. New people. This time with clear rules.

But that’s disconnected from how organizations actually improve. You don’t defund your way to better governance. You iterate. You refactor. You acknowledge the human effort that built what exists, even as you work to make it better.

The Stories We Tell

We love a good David versus Goliath story. But sometimes it’s just a bunch of Davids looking for a Goliath. Sometimes everyone thinks they’re the underdog.

I’ve been observing this whole situation unfold, and I’ve noticed something: some accounts leave certain details out. Others fill them in. Some people fact-check and never include those details in their telling. It’s a reminder of how often humans… consciously or unconsciously… leave things out that would help inform the rest of us.

I voiced this at the time during the fact-checking: there are employment policies and laws that mean some things can’t be disclosed. We’ll likely never be able to get the full story. And whether we like it or not… that’s just the world we live in when we’re dealing with organizations and people who are liable for what they disclose to the public.

Here’s what I think actually happened: funding got uncertain. Decisions got made under pressure. Different people reached different conclusions about the right path forward. Some of those decisions look questionable in retrospect. Some may have been mistakes. None of it required villainy.

As we seem to be learning, I’m not even convinced each of the actors understood the full context. When you’re dealing with funding pressures, employment changes, infrastructure ownership questions, and relationship breakdowns all at once… it’s entirely possible that no single person had the complete picture.

It’s healthy to ask ourselves, “what would I do in that situation?” But we don’t actually know what the situation was. And we probably never will.

On New Organizations

Someone might ask: if I’m against the rewrite, why do I support the Rails Foundation? Wasn’t it created in reaction to Ruby Central not inviting DHH to keynote one year?

That might have been the instigator. The catalyst that prompted DHH to step back and look at the bigger picture again.

But here’s the thing: the Rails Foundation focuses specifically on promoting and adopting Ruby on Rails itself… educational content, revamping public-facing resources, supporting Rails events, highlighting work within the community. That’s a different mission than Ruby Central’s stewardship of RubyGems, Bundler, and the broader Ruby ecosystem.

Planet Argon is a contributing member because that clarity of purpose resonates. I can see where our sponsorship dollars are going.

New organizations can emerge to fill genuine gaps. That’s not a rewrite… it’s recognizing that one organization can’t do everything, and sometimes focused missions serve the community better than trying to be all things to all people.

The question isn’t whether new organizations should exist. It’s whether we burn down what’s working to build them.

What Most Developers Actually Care About

Here’s something important to remember: the overwhelming majority of Ruby developers hardly know what to make of this situation. They’re focused on getting their work done. They’re going to stick with what feels familiar to them… until there’s a pain point that directly impacts them.

And here’s the thing: there are plenty of problems with dependency management. But the source of where we install our gems? That’s far from top of mind. It’s updating the dependencies themselves that we’re all struggling with. That’s where the opportunity is to get people to change how they think about dependency management.

Infrastructure drama doesn’t drive adoption. Solving real problems does.

Why Second Acts Matter

At Planet Argon, we talk a lot about how good software deserves a second act. Not because change is bad, but because smart, sustainable change respects what came before while building toward what’s next.

This isn’t nostalgia. It’s not clinging to the past. It’s recognizing that the systems we have… code or organizations… were built with real human effort. People put their creativity and care into making them work. That investment deserves respect, even when the result needs improvement.

Ruby Central has made decisions I don’t understand. But their track record, across their entire history, trends toward doing good. They’ve stewarded critical infrastructure that millions depend on. They’ve run events that brought the community together. They’ve invested in educational content and tooling.

They deserve accountability. They deserve tough questions. They deserve pressure to improve governance, communication, and decision-making.

But they also deserve a second act.

Not because they’ve been perfect. Because they’ve been consistently trying to do good, and that effort… that accumulated institutional knowledge, those relationships, that trust built over years… has value worth preserving and building on.

This isn’t about resisting change. It’s about making change that’s sustainable. That learns from what worked. That fixes what didn’t. That acknowledges complexity instead of pretending it away.

Splinter factions will emerge. New organizations will form with clearer missions. Some of those might be worth supporting too. That’s healthy. That’s how ecosystems evolve.

But I prefer the refactor. I prefer the second act.

Sitting With Uncertainty

Can we resist the clean narrative? Can we sit with not knowing the full story… and acknowledging that nobody involved probably knew it either?

Can we hold space for multiple people with legitimate grievances, reasonable disagreement about direction, financial pressures creating impossible choices, and decisions made with incomplete information by people acting in good faith?

This isn’t moral relativism. It’s recognizing that organizational complexity, like code complexity, doesn’t yield to simple explanations.

Let me be clear: I don’t think Ruby Central handled this well from a public communications perspective. But as a community member, I can accept their apology and move forward. I completely understand if those who had their access revoked don’t feel that way. They have every right not to.

And I can’t help but wonder: sometimes we make public statements, take positions, feel like we’ve burned bridges that can’t ever be repaired. But in the spirit of honoring where we’ve been… is there a path forward that doesn’t splinter so much?

Maybe there is. Maybe there isn’t.

I also understand if some people read this and think, “Robby, you’re a fucking coward.” Maybe sitting with uncertainty feels like fence-sitting. Maybe nuance feels like avoiding taking a stand.

But as just a Rails developer… I’ll applaud the effort and cheer them on to find their path. And hope the paths meet again.

The infrastructure we depend on was built by humans. Maintained by humans. Those humans put real effort… real creativity, real care… into systems that work, even imperfectly.

Maybe the most honest thing we can do is resist the rewrite impulse. For code and for organizations. Focus instead on thoughtful refactoring that respects what was built while making it better.

Give good things their second act.

Complicated things are complicated.

And that’s okay…

But what the fuck do I know.

Talking Shop with Ruby & Rails Maintainers at Rails World 2025

Mon, 22 Sep 2025 00:00:00 +0000

As the opening keynote on Day 2 of Rails World 2025, I had the chance to host a panel with three people who’ve been shaping the direction of both Ruby and Rails from deep within the internals.

Aaron Patterson (@tenderlove)
Hiroshi Shibata (@hsbt)
Jean Boussier (@byroot)

We covered a lot in an hour:

What they’ve been working on behind the scenes
Which areas of Ruby and Rails could use more community support
The evolving release process for the language
Why Hiroshi’s focused on improving the experience for developers on Windows
How security fixes are coordinated across multiple versions
Performance work related to YJIT and ZJIT
JSON parsing performance and compatibility
What keeps them motivated to continue maintaining the ecosystem

There’s even a moment where Aaron and Jean get into a friendly disagreement about performance and priorities. If you enjoy technical nuance and sharp perspectives, you’ll appreciate that exchange.

And yes… I asked Aaron about his favorite Regular Expression. His response did not disappoint.

It was a fun, thoughtful, and occasionally surprising conversation — and a reminder that Ruby and Rails continue to evolve in the hands of people who care deeply about their future.

If you weren’t in Amsterdam or want to revisit it, the full panel is now available:

Also worth pairing with this interview with Jean on the On Rails podcast, where we dig into IO-bound workloads, misconceptions, and what it’s like maintaining Rails at scale.

A solid pairing if you’re curious where the ecosystem is headed next.

7 Stages of Software Tech Stack Adoption (You're Probably in Stage 5)

Sat, 20 Sep 2025 00:00:00 +0000

I’ve been part of the Ruby on Rails ecosystem for over two decades. I’ve watched teams adopt Rails with wild enthusiasm… evolve their systems… struggle through growing pains… and eventually find themselves in an uncomfortable position; debating whether to abandon the tools that once brought them so much joy.

I don’t think that’s necessary… or even wise.

But I do think it’s understandable.

After working with and talking to hundreds of teams… many of them using Rails, Laravel, Ember.js, or even React… I’ve noticed a pattern. A lifecycle of sorts. The way teams internally adopt and evolve their relationship with a technical stack. I’ve seen it reflected in our consulting clients at Planet Argon, the guests on my podcasts (Maintainable and On Rails), and peers who’ve been part of the various peak waves of these ecosystems.

And while every team is different, the stages of internal tech stack adoption often follow a similar spiral.

This post is an attempt to describe that spiral.

Not as a fully baked theory; but as a conversation starter. A mirror. And maybe a compass.

Because whether your team is building your core product with Rails, or you’re a non-software company maintaining internal tools on Laravel, understanding where you are in this lifecycle might help you understand what comes next.

🌀 The Spiral of Internal Tech Stack Adoption

Before we go deeper, here’s a quick overview of the seven stages I’ve observed. These aren’t fixed; your team might skip around or revisit them multiple times. But in general, this is the pattern I’ve seen:

Adopting: A small group of enthusiastic engineers selects and introduces the stack while building a prototype or MVP.
Expanding: The stack proves useful… so it spreads. More features, more developers, more tooling.
Normalizing: The stack becomes the default. Teams standardize around it. Hiring pipelines and best practices emerge.
Fragmenting: Pain points surface. Teams bolt on new tools or sidestep old ones. Internal consistency erodes.
Drifting: The stack feels sluggish. Upgrades are deferred. The excitement is gone.
Debating: Conversations shift to rewrites or migrations. Confidence is shaken.
Recommitting: Teams pause, reflect, and decide to reinvest in the stack… and their shared future with it.

Again, these stages aren’t a ladder; they’re a spiral.

And the question your team has to ask is: Are we spiraling upward… or downward?

Because while The Downward Spiral is a great album, it doesn’t have to be your trajectory.

♻️ It’s a Cycle, Not a Ladder

It might be tempting to look at this lifecycle and think, “Our goal is to get to the Recommitting stage and stay there forever.”

But that’s not how this works.

Every team will move through these stages multiple times over the lifespan of their product. Shifting priorities, team turnover, organizational pivots… they all create new dynamics that ripple across your tech stack.

Recommitting isn’t a finish line. It’s an inflection point. One that clears the fog, sharpens priorities, and invites your team to move forward with intent.

Just don’t mistake clarity for comfort… the spiral keeps turning.

1. Adopting

This is the “we’re just getting started” phase.

You’re building a new product… launching an internal tool… or maybe spinning up a proof of concept for an idea that hasn’t fully proven itself yet. The team is small — maybe even just one or two engineers. The surface area of the application is still manageable. You don’t have years of technical debt slowing you down… yet.

You might not even be around in six months. You might never hire another engineer. Or you might be laying the foundation for a product that hundreds of people will touch every day. It’s all possibility. And possibility is exciting.

This is when the technical leaders on your team make a recommendation: “Let’s use Rails”… or Laravel… or Ember… or React. The pitch sounds familiar:

“We’ll be able to move quickly…”
“There’s a strong community…”
“This framework is well documented and tested…”
“I’ve used it before and had a great experience…”
“There are tons of plugins and libraries…”
“Hiring should be relatively easy down the road…”

Sometimes these decisions are driven by experience. Other times by curiosity or hope. And occasionally, it’s a compromise between a few competing options.

But one thing is consistent: this decision is rarely debated at the org-wide level. You’re a small team. You’re trusted to figure it out. And if you’re successful, the rest of the company will inherit whatever you chose.

That’s a big responsibility. And it’s one that deserves more reflection than it often gets.

In the Adopting stage, there’s a kind of magic. Things are getting built. Confidence is growing. And there’s a sense of momentum. It’s also the phase when you’re most open to experimentation… and least burdened by legacy code or organizational inertia.

That freedom can be your greatest asset… or a future liability.

Because once the rest of the org starts depending on what you’ve built… the clock starts ticking. You’re creating gravity. You’re laying down roots. And without realizing it, you’re beginning to shape the lifecycle that follows.

In this stage, there aren’t many “symptoms” of trouble to diagnose. But there is one smell worth watching for:

Are you adopting this stack because you believe in its long-term fit… or because it feels exciting right now?

The best early decisions come from enthusiasm and discernment. Not just what’s cool… but what’s sustainable for the kind of team you plan to become.

2. Expanding

Things are starting to work. You’ve shipped your MVP, and the initial product has shown enough promise to warrant further investment.

This might be when your startup begins raising money. Or if you’re inside a larger organization, leadership is noticing what your team has been building and wants more. More features, more integrations, more engineers… more everything.

The engineering team starts to grow. Maybe you’re hiring full-time developers. Maybe you’re working with freelancers or external partners. In some cases, it’s a mix of both.

Your original technical decisions are still holding up. The discussions about what framework to use have faded into the background. The focus now is on growing a team that can execute within the current stack.

That means job descriptions begin referencing specific RubyGems or open-source tools your team has already adopted. You start asking candidates what types of third-party systems or infrastructure tools they’ve integrated Rails apps with. You want engineers who can jump in and be productive—because momentum is everything right now.

Onboarding becomes more frequent. The need for documentation increases. There’s more coordination, more meetings, more product specs… and inevitably, more opinions.

Meanwhile, the original engineers—the ones who picked the stack—might be shifting roles. Some move into management. Others are pulled into meetings or strategy work. Some get recruited away. This changes the center of gravity on the team and fragments some of the original context.

That’s not necessarily a red flag. It’s just a natural byproduct of growing quickly.

To support that growth, many teams begin leaning on outside help, bringing in freelancers or working with firms like Planet Argon to meet delivery goals or stabilize certain parts of the system.

Signs your team might be in the Expanding stage:

You’re actively hiring engineers familiar with your tech stack
Job descriptions reference specific RubyGems, tools, or integrations
Original contributors are stepping into new roles or leaving the team
There’s increased emphasis on onboarding and documentation
External agencies or freelancers are augmenting the team
Leadership is asking for more features, faster

3. Normalizing

This is when the technology stack starts to fade into the background a bit.

The stack is no longer a hot topic in team meetings or strategy sessions. It’s just assumed. New team members are expected to figure it out — or are given onboarding resources to get them up to speed. Hiring patterns shift from “must have experience in [Rails/Laravel/etc.]” to “smart generalists welcome.” There’s a belief that the tooling is mature enough and the documentation strong enough that good engineers can pick it up as they go.

Some of the original engineers may have moved into different roles — promoted up into management, or recruited away to another opportunity. The institutional memory of why certain decisions were made may start to thin out. That early enthusiasm that helped rally the team around the technology stack isn’t quite as present anymore. It’s not gone… it just doesn’t show up in the same way.

There’s often more stability in this phase. You have patterns, workflows, and some documented best practices. New features get built. Bugs get fixed. Things are fine.

But “fine” can be a dangerous place to hang out for too long.

You may have a team of people using the same framework in slightly different ways. You might have multiple approaches to testing, job queues, or background processing. Your linter rules may vary from one directory to another. CI/CD pipelines might have been built with just-in-time needs rather than a longer-term strategy.

That early foundation? It’s now several layers buried. It hasn’t been actively questioned in a while.

And that’s okay… for a while.

But normalization is often when invisible complexity starts to grow. The decisions made years ago shape the defaults everyone works with today — even if those choices don’t make as much sense anymore.

Signs your team might be in the Normalizing stage:

Job postings don’t require deep expertise in the stack anymore
Onboarding materials are assumed to be “good enough”
Few people remember why certain architecture choices were made
Conversations about tooling are rare or surface-level
“That’s just how we do it here” starts to show up more often
Engineers spend more time working around problems than fixing root causes
Updating documentation feels like a chore, not a habit

This is a stage where good habits can take root — or fade away. The stack isn’t the story anymore… but maybe it should be, at least from time to time.

4. Fragmenting

The team has grown… and not just in headcount. Now there are multiple teams. With multiple managers. And multiple priorities. Boundaries are being drawn — to the best of everyone’s ability.

To support that, new tooling is introduced. Conversations about architecture become more frequent. Maybe you’ve started spinning up microservices or smaller applications to own specific pieces of the platform. Some teams adopt new JavaScript frameworks. Other teams reach for different patterns. And it’s around this time that the term “legacy code” starts appearing in planning meetings.

Your single app is starting to feel more like a web of interconnected services… and very few people have a full sense of the whole. The test suite is getting slower. Teams are optimizing for their portion of the platform. Infra work feels like its own company within a company.

This isn’t necessarily a problem. These adaptations make sense — especially when the organization is scaling quickly. Teams are doing their best to deliver. To reduce friction. To match the autonomy they were promised.

But… it’s also where cohesion begins to suffer.

Some teams start using different programming languages. Different infrastructure platforms. Some of that comes from necessity; some of it comes from preference. You may start to hear things like, “This stack just isn’t a good fit for our part of the product.” And depending on who’s leading those conversations, it might even sound convincing.

When teams lack a shared understanding of the primary tech stack — or weren’t around during the earlier stages when that decision was made — they’re less likely to feel a sense of responsibility to carry it forward. That’s not a character flaw. It’s context.

But when enough teams go their own way, the foundation begins to shift. The very things that made your product cohesive and maintainable start to drift apart. And the assumptions driving today’s decisions may not reflect the needs of tomorrow’s (potentially smaller) team.

Signs your team might be in the Fragmenting stage:

Multiple frameworks or languages are used across services or features
Different teams own different deployment workflows or CI tools
Cross-functional planning requires a lot of explanation or diagrams
The core team’s shared standards feel outdated or optional
Hiring focuses more on team-specific expertise than core stack familiarity

5. Drifting

The product still works. Nobody disputes that.

From the product side of things, everything seems relatively healthy. Customers are using the app. Revenue is coming in. Features still ship… eventually. But behind the scenes, things feel slower. Heavier. Riskier.

Technical leadership may have changed a few times. The original advocates of the stack have long since moved on. The current team inherited the system — and while they’re keeping things afloat, they haven’t navigated a major stack upgrade before. They’re not sure what’s lurking in the corners.

People are referring to “technical debt” more frequently. It shows up in roadmap discussions. Sprint planning. Team retros. But even when it’s acknowledged, it’s hard to act on. There’s always something more urgent.

Monitoring and observability become focal points. You’re collecting tons of logs and metrics, hoping to make data-informed decisions soon… but those decisions are harder to make when your engineers feel blocked. Or overwhelmed. Or unsure where to start.

Because while the system isn’t broken… it doesn’t feel sustainable.

Signs your team might be in the Drifting stage:

Deployments are slower and increasingly reliant on manual QA
Engineers hesitate to touch parts of the codebase without thorough investigation
Test suite is long-running and semi-trusted
Technical debt is frequently referenced, but rarely prioritized
Tooling and documentation feel out of sync with the current product
Leadership is requesting clarity on what’s really blocking progress

🧰 Need help navigating this phase?
Check out Maintainable Rails — my free email course for teams wrestling with legacy code, slow test suites, and Rails upgrades.

6. Debating

The conversations have shifted.

You’re not just trying to unblock tickets or shave time off deploys anymore… you’re openly asking if your current stack is still the right long-term choice.

Leadership wants to know what’s possible; and at what cost. Engineers are drawing diagrams to explain years of decisions. Technical assessments are being scoped. Rewrite proposals are floating around. But nothing feels definitive.

It’s clear that the team is capable… but tired. The stack feels like a weight rather than a boost. And while nobody wants to jump into a rewrite lightly, it’s starting to feel like you’ve run out of easy paths forward.

Some teams in this stage start experimenting with other frameworks or stacks. They build new tools in a different language. They reference how other companies are “doing it better.” Consultants are brought in to validate hunches… or challenge assumptions. As more data is collected, a clearer picture begins to form — but agreement doesn’t always follow.

This stage is emotionally charged. Some team members are fiercely loyal to the existing stack. Others feel it’s holding them back. People are reflecting on the past, imagining the future, and questioning whether the current path is still worth walking.

These aren’t easy conversations. But they’re necessary.

Signs your team might be in the Debating stage:

Leadership is asking for estimates to rewrite “just part” of the system
Engineers are referencing success stories from other tech stacks
Framework upgrade tasks are scoped but rarely completed
Tooling and infrastructure conversations dominate team discussions
There’s little consensus on whether to modernize or replace existing systems
Consultants or contractors are being brought in to offer a second opinion

This is a good time to pause and realign. Before making drastic changes, revisit your product vision, business constraints, and the real reasons things feel hard. Sometimes what’s needed isn’t a new stack… but a recommitment to the one you already have.

7. Recommitting

Eventually, your team has to choose: double down or start over.

Recommitting means you’re sticking with the stack you’ve built your product — and your team — around. Not out of nostalgia. Not because it’s perfect. But because it still works.

It’s not giving up. It’s opting out of the fantasy that a rewrite will magically fix everything.

You’re not trapped in sunk costs… you’re investing in the stack you already understand. That’s not weakness. That’s leverage.

Recommitting isn’t about nostalgia. It’s about making a grounded decision:
We’ve come this far… and we’re not done yet. So let’s make this better.

That decision unlocks a new type of energy.

Teams begin to invest in modernization efforts. Upgrades get planned — and actually delivered. Documentation becomes something people reference and improve. Refactors have purpose again, enabling future work rather than just cleaning up messes from the past.

Hiring starts to shift, too. You’re not just looking for people who know the stack — you’re looking for those who can help align and grow the team around it. Sometimes that means bringing in new voices. Sometimes it means letting go of folks who aren’t on board anymore.

Some people will move on. Some of them should.
And in a few cases, you might need to ask them to.

Your team might get a little smaller. That can be a really healthy thing.
Fewer silos. Fewer competing visions. More clarity. More momentum.

Recommitting is a forcing function. It requires saying “no” to the infinite set of other directions your team could go — and doubling down on the direction you’ve chosen.

It isn’t the end of the story.
It’s the start of the next cycle… but with your eyes open this time.

🔍 How to Identify What Stage You’re In

Before you can spiral upward, you need to know where you’re standing.

So… what stage are you in?

More importantly: would your teammates say the same?

You don’t need a quiz. You need a conversation.

Here are a few questions to spark that:

If a new hire joined last week, how would they describe your team’s tech culture?
When’s the last time someone challenged the way you work… and did it land?
Are you hiring for what the team is today, or what it needs to become?
What’s being quietly avoided in planning meetings?
Are you moving with purpose, or waiting for permission?

Talk about it. With a peer. In a 1:1. Maybe even in your next retro.

💬 Invite Your Team In

Feel like this article hit a nerve? You’re not alone.

Drop the link in Slack or email with something simple:

“This made me think… curious which stage you think we’re in?”

“Stage 5 kinda hurt. Just me?”

🗳️ Try a Team Pulse Check

Post a quick poll:

“Which stage in this article feels most like us right now?”

Compare results. Disagreements are good. They reveal where your team’s stories aren’t aligned yet.

Which might be the most important thing to fix.

💡 What Teams Who Recommit Do Differently

So if your team has chosen to recommit, what happens next?

You’re not pivoting to the latest shiny thing. You’re saying:

We’re going to stick with Ruby on Rails (or insert your stack here).

And if you make that choice, here’s the work:

Center your stack in your culture.
Mention it in onboarding. Reference it in planning docs. Make it part of the story your team tells itself.
Invest in internal education.
Run workshops. Build an internal playbook. Share tips, tricks, and hard-won lessons.
Send people into the community.
Conferences. Meetups. Slack groups. Encourage curiosity. Normalize outreach.
Sponsor the ecosystem.
Not just because it looks good. Because it gives your team a stake in the future of their tools.
Hire differently.
Look for engineers who align with opinions, not just languages. Prioritize mindset over mastery.

Be the kind of place that attracts the kind of people who are drawn to strong opinions and clear commitments.

Because when you truly recommit, better questions become possible:

“If we’re still on Rails ten years from now, what might a healthy version of that look like?”

Maybe:

You’re running the latest stable release of Ruby and Rails… always
Your test suite runs against weekly Ruby and Rails builds to catch regressions early
You file upstream bug reports before they hit your production code
Rails upgrades happen continuously… not as Q3 projects
New hires don’t ask, “What version are we on?” because the answer is always “latest”
The phrase ‘legacy code’ stops meaning ‘scary’ — and just means ‘old.’

You don’t need to operate at Shopify scale. You just need a stack your team can rally around.

🏁 Wrapping Up: The Spiral Doesn’t End

If your team feels stuck somewhere between fragmenting, drifting, and debating… you’re not alone. You’re also not doomed.

Maybe… just maybe… you’ll never get out of the spiral. But you can rethink how you move through it.

Upward. Intentionally. With less friction and more momentum.

Because recommitting isn’t waving a white flag. It’s planting one.

It’s saying: We’ve been through the hard parts. We know what works. Let’s build on that instead of starting over again and again.

It’s choosing the long road because that’s where the depth is.

Your team — whether it’s ten engineers or four hundred — has an opportunity to write the next chapter in your stack’s story. And if you do it well, the next set of new hires won’t just inherit your tools. They’ll inherit your clarity.

When Your Cache Has a Bigger Carbon Footprint Than Your Users

Thu, 28 Aug 2025 00:00:00 +0000

Caching in Rails is like duct tape. Sometimes it saves the day. Sometimes it just makes a sticky mess you’ll regret later.

Nowhere is this more true than in data-heavy apps… like a custom CRM analytics tool that glues together a few systems. You know the type: dashboards full of metrics, funnel charts, KPIs, and reports that customers swear they need “real-time.”

And that’s where the caching debates begin.

Do we cache the raw data in Redis or Solid Cache?
Do we cache entire report payloads?
Do we lean on CloudFront or Cloudflare to hold onto responses?

All valid. All expensive in their own way.

The Dashboard Problem

Your SaaS app has grown to 2,000 customers, each with multiple users.

For the overwhelming majority, dashboards load just fine. Nobody complains.

But then your whales log in. The Fortune 500 accounts your sales reps obsess over. Their dashboards pull data from half a dozen APIs, crunch millions of rows, and stitch together a wall of charts. It’s not just a page. It’s practically a data warehouse in disguise.

These dashboards are slow. Painfully slow. And you hear about it… through support tickets, account managers, and sometimes even a terse email from someone with “Chief” in their title.

So your engineering team digs in. You fire up AppSignal, Datadog, or Sentry and zero in on the slowest dashboard requests. You look at traces, database query timings, and request logs. You chart out the p95 and p99 response times to understand how bad it gets for the biggest customers.

From there, you start experimenting:

Are we missing database indexes?
Are there N+1 queries lurking in the background?
Can we preload or memoize expensive calls?
Could a few data points be cached individually, without touching the rest?

You squeeze what you can out of the obvious optimizations. Maybe things improve… but not enough.

So the conversation shifts.

Negotiating “Real-Time” Expectations

When your product team actually sits down with those whale customers, the conversation shifts.

They start by saying: we need real-time data. But after a little probing, everyone realizes “real-time” doesn’t always mean right now this second.

Maybe what they really need is a reliable snapshot of activity as of the end of the previous day. That’s good enough for the kinds of decisions their leadership is making in the morning meeting. Nobody is making million dollar calls based on a lead that just landed five minutes ago.

And your team can remind them: there are other real-time metrics in the system. For example:

New leads created today.
Active users in the past hour.
Pipeline changes as they happen.

So now you’ve reframed the dashboard story. Instead of one giant “real-time” data warehouse, you split it into two categories:

Daily rollups. Crunch the heavy stuff once a night. End-of-day data is sufficient, and it’s reliable.
Today’s activity. Show a few real-time metrics that are fast to calculate. Give customers the dopamine hit of “live” data without boiling the ocean.

That’s usually enough to recalibrate expectations. Customers feel like they’re still getting fresh data, while your app no longer sets itself on fire every time a big account logs in.

The 1 AM Job (and Its Hidden Cost)

Armed with that agreement, your team ships the “reasonable” solution most of us have built at least once:

Every night at 1 AM, loop through all 2,000 customers.
Generate every dashboard report.
Cache the results somewhere “safe.”

The next morning, dashboards are instant. Support tickets quiet down. Account reps breathe easier. Everyone celebrates.

But here’s the kicker: the whales were the problem. The rest of your customers never needed this optimization in the first place. Their dashboards were already fine.

So now you’ve turned one customer’s problem into everyone’s nightly job. And under the hood, you’ve cranked through hours of CPU, memory, and database load… just to prepare data for customers who won’t even log in later today.

Worse, you’ve stuffed your background job queue with 2,000 little tasks every night. Which means your queue system—whether it’s Sidekiq, Solid Queue, or GoodJob—is spending precious time juggling busy work instead of focusing on the jobs that actually matter. And when those queues get stuck, or a worker crashes, you’re left wading through a mountain of pending jobs just to catch up.

This is what I call Cache Pollution: the buildup of unnecessary caching work that bloats your systems, slows down your queues, and leaves your caching strategy with a far bigger carbon footprint than it needs to. Another benefit of tackling Cache Pollution early is future flexibility — you might eventually solve the computation challenges in a different way, and you won’t be anchored to big, scary scheduled tasks that churn through all of your customers every night.

Frequency Matters More Than We Admit

Do these reports need to run every single day… or only on weekdays when your customers actually log in?

If your traffic drops on Saturdays and Sundays, consider a lighter schedule. Or even none at all. Because “slow” isn’t so slow when almost nobody is around. A BigCorp admin poking the dashboard on Sunday morning might be fine with an on-demand render… especially if the weekday experience is snappy.

And here’s another angle: if your scheduled job runs at 1 AM, that means when a BigCorp user logs in later that same day, they’re still looking at data that’s less than 24 hours old. For most business use cases, that’s plenty. You don’t need to rerun heavy jobs every few hours just because you can.

This is all about right-sizing frequency:

Weekday cadence: nightly rollups for whales; maybe twice a day if usage demands it.
Weekend cadence: pause, or run a narrower subset.
Holiday mode: same idea… different switch.

If your dashboard code doesn’t rely on the cache to render, you keep the option to not precompute. That flexibility is where the savings live. As the business grows, the cost of overly eager schedules grows with it… so design for dials, not hard-coded habits.

Other Things to Consider with Recurring Tasks

One more question to ask about recurring scheduled jobs: do you really need to iterate through all users or all organizations?

In many cases, the answer is no. Most customers don’t trigger the conditions that require a heavy recompute. Yet teams often design jobs to blast across every top-level object in the database, every night, without discrimination.

Instead, look for signals that help you scope the work down:

Which organizations actually logged in today?
Which customers have datasets large enough to need optimization?
Which accounts crossed a threshold since the last run?

By narrowing the set of work each job touches, you cut down on wasted compute, reduce queue congestion, and avoid the kind of Cache Pollution that grows silently as your business scales.

Clever Tricks We’ve Seen

The trick isn’t just caching everything for everyone. It’s knowing who to cache for and when.

Selective pre-caching. Only build nightly rollups for your whales. Maybe 50 out of 2,000 customers. Everyone else can render on demand, which was fine all along.
Cache on login. If you know a user from BigCorp is signing in, enqueue a background job to warm up their dashboard before they hit it. You can even anticipate who they are based on a cookie value when they land on the Sign In page — before they’ve had a chance to trigger 1Password or type in their credentials, the system is already working behind the scenes to prep their dashboard. Even a 10–20 second head start can smooth the experience.
Cache on demand… with a fallback. If cached data is missing, build fresh on the spot. Outages happen when teams assume the cache will always be there.

And here’s a bonus: if your job fails at 1 AM, re-running it for 50 customers is a whole lot faster than crawling through 2,000.

Extra credit: scope your scheduled tasks so that when a customer crosses a certain threshold—say, user count, dataset size, or request volume—they automatically join the “whale” group. No manual babysitting required.

Other Patterns

Not all caching challenges look like dashboards.

Case Study: The Press Release Problem

We once managed a public-facing site for a massive brand. Whenever they dropped a big press release, it spread fast across social media. Traffic would spike within minutes.

Of course, that’s when the CEO would notice a typo. Or the PR team would need to update a paragraph to reflect a question from the media. Despite their editorial workflows, changes still had to happen after publication.

So we had to get clever. We couldn’t cache those fresh pages for hours. Instead, we used a sliding window approach:

First 5 minutes: cache for 30 seconds at a time.

After 5 minutes: increase to 1 minute.

After 10 minutes: increase to 2 minutes.

After 20 minutes: increase to 5 minutes.

After 6 hours: safe to cache for an hour.

After a day: cache for a few hours at a time.

This let us protect our Rails servers from massive traffic spikes when a new article was spreading fast, while still giving editors the ability to push corrections through quickly. Older articles, once stable, could safely sit in Akamai’s cache for hours.

At the time, Akamai could take up to seven minutes to guarantee a purge across their global network. Not ideal. We had to plan for that lag. Today, most CDNs can purge instantly, but back then… it was a constraint we had to design around.

A Final Challenge

A lot of what we’ve talked about here comes down to avoiding Cache Pollution.

That’s the unnecessary churn your system takes on when it generates data nobody asked for. It’s the background job queue bloated with thousands of tasks that fight with more important work. It’s the 1 AM process chewing through CPU just to prep dashboards for customers who never log in.

Cache Pollution looks like optimization on the surface… but underneath it’s just waste.

So before your team spins up the next caching project, stop and ask:

Who really needs this cache?
How fresh does it need to be?
What happens if the cache isn’t there?
Do we need to run it this often, or for this many customers?
Could we scale down the busy work instead of scaling it up?

Because the goal isn’t just faster dashboards. The goal is to keep your caching strategy lean, resilient, and focused — instead of leaving behind a trail of Cache Pollution that grows with every new customer you add.

The Internal Tooling Maturity Ladder

Wed, 13 Aug 2025 00:00:00 +0000

(or: How I’m Learning to Step Back So We Can Move Forward)

Here’s a pattern I’ve been contributing to more than I’d like to admit:

Someone on the team proposes a new internal tool. There’s a clear need. There’s momentum. Conversations start about how we’ll build it… what tools we’ll use… where it’ll live… whether it might become client-facing someday.

It hasn’t been built yet, but we’re already architecting the scaffolding.

And that’s usually when I step in.

Not with a thumbs-up. Not with funding. But with questions. The kind that start with, “What if we didn’t build this?”

It’s not fun. It’s not fair. And it’s not how I want to lead.

By that point, people are invested. They’ve done the thinking. They’ve shared the idea. They’ve taken a risk. And now I’m asking them to scale it back—or stop entirely.

This is me taking responsibility for that pattern.

So I did the only thing I know to do in moments like this: I wrote it down.
We now have a model. Internally, we call it The Internal Tooling Maturity Ladder.

🪜 The Ladder (in Plain English)

Level 0 – One-off Manual Script
Something one person runs on their own machine to save time or reduce repetitive work.
Maybe it lives in an unsaved file or as a task in Alfred or Automator.
It’s not elegant—but it works.
You run it manually. You copy-paste the result. You feel smug for five minutes.
No repo. No expectations. No long-term promises.

Example: A quick Ruby or Bash script that tallies something from an API and drops it into Slack.

Level 1 – Shared Manual Script
You cleaned it up. You wrote a little README. You dropped it in a shared Gist or Google Drive.
It’s still manually triggered, but now others can use it too—if they read the instructions.
It’s still lightweight. Still safe.
And it’s often where great tools should stay.

Example: A command-line tool that a few team members can run locally, maybe to generate a report or fetch usage stats.

Level 2 – Scheduled Automation
Now we’re automating things.
It runs on a schedule—maybe through Zapier, a GitHub Action, or a scheduled Rake task.
No UI. No buttons. Just automated updates that go where we already spend time.
Slack. Google Sheets. Email.
These tools hum quietly in the background, doing one job well.

Example: A script that posts weekly project stats to a Slack channel every Monday morning.

Level 3 – Lightweight Internal Service
Now we’re getting fancy.
This has a small UI. A form. A dashboard. Maybe some configuration options.
It needs hosting. Credentials. Some thought about security.
It’s still simple enough that one person can manage it—but now it’s a thing.
And it needs some care.

Example: A mini app that lets the team search across client project docs or surface stale Jira tickets.

Level 4 – Fully Hosted Internal Product
This is a real web app.
It’s deployed. It has a frontend and a backend. It has users. Sessions. Maybe even tests (hopefully).
It needs to be maintained. Updated. Monitored.
It might solve a meaningful problem—but it’s not free.
This is the top of the ladder for a reason.

Example: A polished internal dashboard that’s become a critical part of day-to-day operations.

Start Lower

This isn’t a blueprint. It’s a conversation starter.

The higher you go, the more you commit—time, infrastructure, expectations.
So we’re learning to start lower on the ladder.
To earn our way up.
To see if people care before we care too much.

Why It Matters

Every internal tool is a promise.
To support it. To upgrade it. To explain it to the next person who inherits it.

And sometimes… the smallest version of the tool is all we need.

A Slack post.
A spreadsheet.
A script that helps one person do their job 10% faster.

Not everything needs a UI.
Not everything needs a repo.
And not everything needs me to be the one who calls time on the project two weeks in.

This post isn’t about our internal model. Not really.

It’s about building fewer things that trap us.
And creating more space to experiment without regret.

If you’ve found yourself playing the role of reluctant gatekeeper… you’re not alone.
This ladder is helping me find a better way.

One rung at a time.

The Features We Loved, Lost, and Laughed At: My RailsConf 2025 Talk Is Now Online

Fri, 25 Jul 2025 00:00:00 +0000

If you didn’t make it to RailsConf this year…or couldn’t make it to my talk…I’ve got good news: the full video is now live.

🎥 Watch it here

Preparing for this talk was one of the most nostalgic (and sometimes absurd) research dives I’ve done in years. I pitched The Features We Loved, Lost, and Laughed At thinking it would be easy to uncover a long list of removed or weird Rails features to poke fun at.

Turns out? They weren’t so easy to find.

Rails hasn’t just thrown things away. It’s looped. It’s learned. It’s come back to old ideas and made them better.

In the talk, I trace that evolution…using code examples and stories from the early days of ActiveRecord, form builders, observe_field, semicolon routes, and even a few lesser-known misadventures involving matrix parameters.

I touch on features like Observers (invisible glue, invisible bugs) and ActiveResource…which wasn’t confusing so much as it was optimistic. It assumed the APIs you were consuming were designed with Rails-like conventions in mind. That was rarely the case.

I also explore what Rails has taught us about developer happiness, what it means to build with care, and what the community keeps refining (and laughing about).

Here’s a quick example: I once wrote an InvoiceObserver that did four different things silently…and when it broke, it took hours to even figure out where the logic lived. Magical until it wasn’t.

Why Look Back Now?

With RailsConf coming to a close, it felt like the right moment to reflect not just on the framework…but on how we evolve alongside it.

Rails doesn’t just chase trends. It revisits its own decisions and asks: “What still brings us joy?”

That’s a rare trait in software. And it’s why Rails still feels like home for so many of us.

“Rails doesn’t just move forward…it reflects. It loops. It asks: Where’s the friction? What can we make effortless again?”

If you’re newer to the framework, or just curious what Rails has quietly taught us over the years…I hope you find something here to smile at.

I’m grateful to my Ruby friends…some old, some new…who shared memories, weird bugs, screenshots, mailing list lore, and just the right amount of healthy skepticism while I was putting this together.

If you’ve ever written button_to_function or find_by_title_and_category_and_status, this one’s for you.

Stop Pretending You're the Last Developer

Wed, 16 Jul 2025 00:00:00 +0000

Ruby on Rails is often celebrated for how quickly it lets small teams build and ship web applications. I’d go further: it’s the best tool for that job.

Rails gives solo developers a powerful framework to bring an idea to life—whether it’s a new business venture or a behind-the-scenes app to help a company modernize internal workflows.

You don’t need a massive team. In many cases, you don’t even need a team.

That’s the magic of Rails.

It’s why so many companies have been able to start with just one developer. They might hire a freelancer, a consultancy, or bring on a full-time engineer to get something off the ground. And often, they do.

Ideas get shipped. The app goes live. People start using it. The team adds features, fixes bugs, tweaks things here and there. Maybe they’ve got a Kanban board full of tasks and ideas. Maybe they don’t. Either way, the thing mostly works.

Until something breaks.

Someone has to redo work. A weird bug eats some data. A quick patch is deployed. Then someone in management asks the timeless question: “How do we prevent this from happening again?”

Time marches on. Other engineers come and go, but the original developer is still around. Still knows the system inside and out. Still putting out fires.

Eventually, the company stops backfilling roles. There’s not quite enough in the backlog to justify it. And besides, everything important seems to be in one person’s head. That person becomes both the system’s greatest asset—and its biggest risk.

This is usually about the time our team at Planet Argon gets a call.

Sometimes, it’s the developer who reaches out. They’re burned out. They miss collaborating with others. They’re tired of carrying the whole thing. Other times, it’s leadership. Things are moving too slowly. Tickets aren’t getting closed. The bugs they reported last quarter still haven’t been addressed. They’re worried about what happens if that one dev goes on vacation. Or leaves.

They’ve tried bringing in outside help… but nothing sticks. The long-term engineer keeps saying new people “don’t get it.”

By the time we step in, we’ve seen some version of this story many, many times.

Documentation? Sparse or outdated.
Tests? There are some, but good luck trusting them.
Git commit messages? A series of “fixes” and “WIP”.
Hardcoded credentials? Of course.
Onboarding materials? There’s nobody to onboard.
Rails upgrades? “We’ll get to it eventually… maybe.”

None of this is uncommon. It’s what happens when good engineers work in isolation for too long, often doing their best to keep things afloat without much help or recognition. Rails makes it possible. But that doesn’t make it sustainable.

Rails is a one-person framework. But very few apps are one-person apps forever.

If your project’s lucky enough to live past MVP…
If it’s important enough for people to rely on…
If it’s been around long enough to be worth maintaining…

…then it’s worth being honest about where things stand.

Write the commit messages.
Leave a few breadcrumbs in the README.
Comment that weird regex.

And while you’re in there…

Write a test for that one thing that keeps breaking. You know the one.
See if you can finally remove that outdated gem dependency that’s blocking your Rails upgrade.
Strip out that old Backbone.js interface. Nobody’s going to miss it.
Delete the dead code you’ve been tiptoeing around. Don’t pass it on like some haunted heirloom.
Truncate that giant table full of data nobody’s touched since the Obama administration.
Rip out ActiveAdmin and replace it with a few boring CRUD pages. It might actually feel good to write normal Rails again—and if you miss the shortcuts, build your own generators to spin up the patterns you actually use.
And please, use a password manager.

These aren’t heroic efforts. They’re just little acts of maintenance. Little acts of kindness… for the next person.

If you’re working in a legacy Rails app—or trying not to create one—you might like Maintainable Rails. It’s a free, no-fluff email course full of real-world tips for reducing technical debt and taming older Rails code. Sent only when it’s useful. No spam, no guilt.

And if it already feels like a mess? You’re not alone. There are teams like ours who’ve made a business out of helping projects like yours find their second wind.

A New Rails Podcast: On Rails

Wed, 25 Jun 2025 00:00:00 +0000

Today marks the launch of On Rails, a new podcast produced by the Rails Foundation and hosted by yours truly.

We’ve recorded the first batch of episodes, and Episode 1 is out now: Rosa Gutiérrez on Solid Queue.

The show dives into technical decision-making in the Ruby on Rails world. Not the shiny trend of the week… but the real conversations teams are having about how to scale, what trade-offs to make, and what long-term maintainability actually looks like.

You’ll hear from developers running real apps. Some are building internal tools. Others work on products you’ve probably used. A few are out there blogging and tweeting… but many are too deep in the day-to-day to stop and write about it. They’re just doing the work — shipping, fixing, refactoring, and figuring it out as they go.

The idea for On Rails started with those hallway conversations at conferences. The ones that don’t make it into keynotes or blog posts. It grew out of the calls I have with clients at Planet Argon. And, of course, out of years of hosting Maintainable.fm.

You’d think that after recording over 200 episodes of Maintainable, I wouldn’t be so nervous to hit record on something new… but here we are. New show jitters are real.

We’re approaching this podcast with depth and focus. Fewer episodes. Longer interviews. Conversations that aim to surface lessons learned…and the thinking behind the decisions that shape real systems.

If you’re a Rails fan, I hope you’ll give it a listen. If subscribing is your thing, you know what to do. And if you’ve got a story worth sharing — I’d love to hear from you.

🎧 Listen to Episode 1: Rosa Gutiérrez: Solid Queue

🌐 Browse all episodes: podcast.rubyonrails.org

📢 Official announcement: Ruby on Rails blog

Backstory

Earlier this year, I dusted off this blog — which I started back in 2005 — and found myself reflecting on Maintainable, the podcast I’ve hosted for the past few years about long-term software health.

At the same time, I was toying with the idea of spinning off something more Rails-focused. A show that could spotlight the kinds of conversations I was already having…with clients, with other devs, and in those casual, between-session moments at conferences.

Right around then, Amanda from the Rails Foundation reached out with a prompt:

“A podcast of Rails devs talking about the nitty gritty technical decisions they’ve made along the way.”

…which aligned nicely with what I had been ruminating on. The timing was perfect and we decided to make it happen.

One of the early shifts for me was adapting to a more collaborative production process. I’ve been running Planet Argon for more than two decades — and I’m used to moving quickly, often without needing to pitch or workshop ideas with others. But with On Rails, I’ve had the opportunity to work closely with Amanda, the Foundation, and DHH. They’ve all taken an active interest in shaping the vision, the guests, and the format.

Another early challenge? The first round of guests were pitched to me — which meant jumping into the deep end with folks I hadn’t already spoken with. That raised the bar for prep. On Maintainable, I’ve occasionally relied on some degree of improvisation. Here, I knew I’d need to come in more prepared…and that’s been a good thing.

So On Rails was born.

I’ll still be hosting Maintainable (though likely on a slower cadence). And I’m excited to run both of these shows side by side — each with their own tone and focus.

Hope you get a chance to give it a listen.

Steering Rails Apps Out of Technical Debt - Rails World

Sat, 01 Feb 2025 00:00:00 +0000

Drowning in technical debt?

It doesn’t have to be this way.

Back in September at Rails World 2024, I shared what I’ve learned from helping teams tack their way out of trouble—less theory, more battle-tested strategies. Lessons from Planet Argon’s clients, Maintainable.fm guests, and real-world Rails teams.

Have 25 minutes? Watch it here:

Your future self (and your app) will thank you.

8 things I look for in a Ruby on Rails app

Thu, 06 Jul 2017 00:00:00 +0000

As a consultant, I’ve looked over a shitload (how many? probably ~150-200) over the last 12 1/2 years in the Ruby on Rails community. I haven’t worked on most of them, but I do get invited to look over, review, audit, and provide feedback on a lot of those.

Over on the Planet Argon blog I’ve shared my quick hit list of a few initial things that I look for when looking over an existing code base.

Read Ruby on Rails Code Audits: 8 Steps to Review Your App

Lessons in Open Source

Mon, 27 Jun 2016 00:00:00 +0000

A few months ago, I wrote an article on Medium about my experience of starting Oh My Zsh. Thought I’d share it for the few lingering readers over here, too.

d’Oh My Zsh: How I unexpectedly built a monster of an open source project

PostgreSQL is the preferred database of Ruby on Rails developers

Fri, 03 Jun 2016 00:00:00 +0000

The 2016 Rails Hosting community survey results are in. One of the numbers that I’m tickled with joy about? 84% of Rails developers said they’d prefer to use PostgreSQL.

We won!

Check out all the survey results at http://rails-hosting.com/

2016 Rails hosting survey is open

Tue, 12 Apr 2016 00:00:00 +0000

If you’ve not taken the 2016 Rails hosting survey, please do so at http://rails-hosting.com/

Tom on Automatic Differentiation

Thu, 11 Feb 2016 00:00:00 +0000

Tom Stuart posted up an excellent article on Automatic Differentiation in Ruby with links to his talk slides and video.

Action Cable demo by DHH in Rails 5

Sun, 20 Dec 2015 00:00:00 +0000

David was kind enough to put together a demonstration of how to take advantage of Action Cable in Rails 5.

In the video he puts together a small chat application.

Ezra Zygmuntowicz -- Farewell, Friend.

Mon, 01 Dec 2014 00:00:00 +0000

Yesterday, I found out that Ezra Zygmuntowicz had passed away.

Ezra and I first met in the #Caboose family. The first time we got to spend time together, in person, was at RailsConf 2006.

(photo credit: Jarkko Laine)

A few weeks later, he emailed me to ask about getting a job here at Planet Argon. We couldn’t afford him so he continued to pursue other paths… and a month later was helping found EngineYard.

(…one of those things that I still find myself asking, “what if we could have?”)

Back when Planet Argon had a hosting department, Ezra and I collaborated on various deployment best-practice projects. He was always helping our team figure out how to make deployment easier. Some of us might remember his famous nginx configuration (the closest version I could find). He was an active contributor in the Ruby on Rails Deployment group that I started. He was always around to help the community.

Ezra always seemed to find time for the community… whether on mailing lists, at conferences, commenting on our blogs, or chatting over IRC.

When Ezra and his family moved to Portland, we made several half-assed attempts to schedule time to catch up again in person. It never happened and our interactions were limited to keeping up on Facebook

His passing is a great loss to our community.

To his friends and family, I am sorry for your loss.

To his son, (should you ever discover this), your father helped pave the way for hundreds of thousands (if not millions?) of software developers around the globe—whether they know it or not. He was constantly looking for innovative ways to solve problems. His talks at conferences were always fascinating… and the rest of us would sit back and think, “where does he come up with these ideas?!”

He was a trailblazer.

He will be missed.

Thank you for everything, Ezra.

Update: If you would like to contribute to the memorial fund for Ezra’s son, Ryland, please visit this campaign on indigogo.

Six days to complete the Rails hosting survey

Thu, 24 Apr 2014 00:00:00 +0000

Attention all Ruby on Rails Developers… you have six days to complete the 2014 Rails Hosting Survey.

All of the results will be shared with the community. Consider this your civic duty of the day. :-)

http://rails-hosting.com

Ruby on Rails is like IKEA...whaa?

Wed, 02 Apr 2014 00:00:00 +0000

Recently, I found reading an article by Paul Venezia titled, Fatal abstraction: A bottom-up view of high-level languages, where—if you read between the lines—you can see that Paul just found himself waking up from a coma and it’s no longer 2004.

“I may have questioned Perl’s future now and then, and Perl certainly doesn’t have the presence it once enjoyed, but the strength of Perl has always been its flexibility. You can do pretty much anything with Perl, and you can do it in a wide variety of ways. Perl’s core revolves around the idea that there’s always more than one way to do it. In fact, there may be dozens of ways to do it. PHP shares a similar trait in that it gives you a large set of tools and leaves the construction up to you.

Ruby, and especially Rails, is the opposite, and Python definitely leans more in that direction. Essentially, it’s the difference between building a chair from raw lumber and assembling one from IKEA. This isn’t to say there’s anything wrong with assembling from parts, and clearly Ruby and Python are very capable and strong languages. However, they’re not my cup of tea.”

Admittedly, perhaps I’ve been in drinking the “kool-aid” for far too long, but I thought this tired argument has run it’s course.

I take huge offense to comparing Ruby on Rails to IKEA furniture. It’s far easier to build a web application with Ruby on Rails than it is to build an IKEA bookshelf

“When it comes right down to it, I need to know exactly what my code is doing. I’m going to keep an open mind and spend more time on the other side of the fence in the short term. Perhaps I’ll be won over, but it won’t be easy. Trust issues are complicated.”

Paul, I completely understand where you’re coming from. It sounds like you’re dealing with similar trust issues that I had nearly a decade ago. Trust me, it will be okay.

Ruby on Rails isn’t magic. Behind the curtain you’ll find a collection of object-oriented code written in one of the most readable languages in existence.

2014 Rails Hosting Survey is now open

Fri, 28 Mar 2014 00:00:00 +0000

Hello! It’s been two years since Planet Argon last asked the Ruby on Rails community how they were deploying and hosting their applications and we thought it was time to checkin with people.

Until April 30th, you can take the survey here.

Oh My Zsh gets a proper web page

Sat, 22 Mar 2014 00:00:00 +0000

It was a long time coming… but we finally got a web page designed and deployed for Oh My Zsh.

Check it out! (and tell your friends to ditch bash)

Jr. Ruby on Rails developers

Thu, 27 Feb 2014 00:00:00 +0000

Over on the Planet Argon blog, you can read an enlightening interview with two of our Jr. Ruby on Rails developers. Both of them made a career change in their 30s and went through a coding academy here in Portland, Oregon.

Check it out…

8 Things Github’s Atom Editor is not going to solve for you

Wed, 26 Feb 2014 00:00:00 +0000

We’re all excited about the prospect of a new code editor (Atom Editor). We all love what Github has produced so far and our expectations for anything new are going to be quite high.

Do we know exactly what it’ll be yet? Not quite. We have some hints… but until it’s released… we’ll continue to speculate.

While I am not one to make predictions—I do have a few theories about what Atom will not do for us. (if you’re looking for a new business idea… feel free to snag any of these)

1. Atom Editor will not make it easier to code while in the shower. While I would love to take advantage of putting my thoughts to code while letting my conditioner do it’s thing… I don’t believe they’re trying to solve this problem (yet).

2. Atom Editor is not going to make it difficult for me to produce shitty code. To date, nearly every code editor on the market is focused on making it easier to produce code…. good AND/OR bad. Where is the editor that tells us to quit while we’re head. “Are you serious, Robby? Have you seen what you’ve been writing today? Just stop. Go outside. Take a break and try again tomorrow.”

3. Atom Editor will not bring synergy to developers.

4. Atom Editor will not change the music playing to compliment the coding problem that I’m faced with. If my tests aren’t passing… I wish my music would keep me calm and focused. This is not a time to start playing WHAM! (…or maybe it is)

5. Atom Editor will not bring about peace in the Emacs vs Vim wars. We are going to have to let them sort a peace deal on their own.

6. Atom Editor will not have integrated CVS or Subversion support when it is released.

7. Atom Editor will not promise the world to you like Visual Studio.NET did back in 2002. I remember their demo videos and it seemed like the development world was about to change! I never would have guessed that come 2005, I’d be in love with something as simple and fancy-feature-less as TextMate.

8. Atom Editor will not just be a clone of Sublime Editor. Github has too clever a team for that objective.

What are you confident that Atom Editor will not be?

Update

8 for 8!

GitHub prepares to release Atom

Tue, 25 Feb 2014 00:00:00 +0000

funny how Twitter warned me that a bunch of my friends at GitHub are all a sudden interested in https://t.co/cb52btuPZe

— Matt Aimonetti (@mattetti) February 26, 2014

…which leads us to

Initial sources suggest that will be one of the biggest app releases of the year.

It’ll be loved by many. Hated by some.

For more details… visit Atom.io or Atom Beta

Dear \@ohmyzsh users… we are ready! ;-)

Updates

As we learn more… I will try to keep this updated. Here are a few “screenshots” people have posted on twitter.

Some animated gifs:

Stay tuned…

SOON.

— Tom Preston-Werner (@mojombo) February 26, 2014

You might consider following @AtomEditor on twitter.

Follow @AtomEditor

Jim Weirich -- Farewell, Friend.

Thu, 20 Feb 2014 00:00:00 +0000

It’s been an odd day. The sort of day where you really don’t know what to say. The only thing you can manage to get out is, “Sigh. I’m going to miss him.”

Jim Weirich was building interesting stuff with Ruby several years before I was introduced to it. Tools that most of us have taken for granted. Tools that were just there.

Before Jim came along… they didn’t exist.

Back in the early Ruby on Rails explosion era (circa 2004-2006), it was much easier to get to know the great Rubyists. I remember finally getting a chance to meet Jim (and _why) at FOSCON here in Portland, which still goes down as one of the best “conferences” I have ever attended.

(I think we all knew something special was happening.)

Jim spoke at a ton of conferences. At any conference that I seemed to get invited to speak at… Jim seemed to always be on the speaker list too. We’d end up meeting up on the conference circuit a several times over the coming years. It was always a delight to catchup.

Photo by Obie from Rails Underground 2009

I believe the last one was in 2009 at Rails Underground in London. I remember walking in one of the rooms and spotting Jim. There he was… waiting patiently for his time slot… sitting by the wall in another horribly uncomfortable conference chair… hacking away on his laptop as if he was on a mission to save the human race. In reality, he was probably toying around with some new idea.

As I walked towards him… my red hair must have caught the corner of his eyes… because he looked up and with the warmest of smiles and kindest of voices said, “Robby!”

It’s people like Jim that helped me feel like I had something valuable to contribute to the community. The mere fact that he knew who I was, that he commented on my silly blog posts, referred potential customers to me, showed up for and complimented me on my talks, asked ME for advice on IRC, wished me a happy birthday on Facebook, responded to my lazy tweets… made me feel like I was welcome to (and part of) the party.

A party that started a number of years before I showed up.

Let us raise our glasses high and thank our host for the pleasure of being amidst his most generous company.

Thank you, Jim, for helping me learn more about myself. I only wish I had gotten to know you more.

Adieu l’ami.

Ruby on Rails developers in New York

Fri, 10 Jan 2014 00:00:00 +0000

We’ve had a number of clients in New York over the years. After a recent trip this last fall to visit clients and attend “Cultivate”:, we decided that we should spend more of our time in the city.

In 2014, we’re looking to expand our client base there. If you’re in the NYC area and are looking for an agency that has great Ruby on Rails developers… get in touch.

oh-my-zsh reaches over 500 contributors

Sun, 01 Dec 2013 00:00:00 +0000

Earlier today, I noticed that we now have over 500 developers from around the globe who I have accepted pull-requests from[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”}. That is so fantastic.

Thanks to each and every one of you who has helped make this project so wonderful for others. :-)

::: {#fn1} This number could be a lot higher if I spent more than a hour or two a week on this, but I’m a big fan of slow and steady… a good number of the open pull-requests are themes at the moment.↩︎{.footnote-back role=”doc-backlink”} :::

Reducing MySQL's memory usage on OS X Mavericks

Sun, 24 Nov 2013 00:00:00 +0000

Recently, I found myself re-installing everything from Homebrew and began to notice that MySQL was consuming nearly half a gig of memory. Given that I don’t do too much with MySQL on a regular basis, I opted to override a handful of default configuration options to reduce the memory footprint.

As you can see, a fresh MySQL install via homebrew was consuming over 400mb of memory.

Here is how I reduced my memory footprint:

$ mkdir -p /usr/local/etc

Unless you already have a custom MySQL config file, you will want to add one into this directory.

$ vim /usr/local/etc/my.cnf

We’ll then paste in the following options into our file… and save it.

# Robby’s MySQL overrides
[mysqld]
max_connections = 10

key_buffer_size = 16K
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 128K\

Finally, we’ll restart MySQL.

$ mysql.server stop

If you have MySQL setup in launchctl, it should restart automatically. After I did this, my MySQL instance was now closer to 80mb.

So far, this has worked out quite well for my local Ruby on Rails development. Mileage may vary…

Having said that, how much memory are you now saving?

See you at LessConf and RailsConf?

Tue, 09 Apr 2013 00:00:00 +0000

Hey all,

It’s been a while (most of my blogging is over on the Planet Argon blog..). but I’m hoping to have some technical-related posts coming in the near future.

If you’ll be at LessConf in Florida this week, I’ll be there. Do I owe you a drink?

Also, if you’re coming to visit Portland for RailsConf 2013 and will arrive the weekend before, you should join us on a hike. If you can’t make it, be sure to say hello at the conference!

Hope all is well!

Cheers,
Robby

2012 Rails Hosting Survey results

Fri, 14 Sep 2012 00:00:00 +0000

A few months ago we invited the Ruby on Rails community to participate in our hosting survey. We’ve since published the results and created an infographic.

To learn more, check out the Rails Hosting site.

GoogleAnalyticsProxy - now minified

Tue, 10 Jul 2012 00:00:00 +0000

It’s been several years since I released GoogleAnalyticsProxy, which allows our team to test their GA event/click/view tracking during the development phases of our project. Today, I pushed a quick update to it with a minified version of the JavaScript so that there is a smaller footprint.

For more information on how we use it, read my older post, Tracking Google Analytics events in development environment with GoogleAnalyticsProxy.

Planet Argon on social media

Thu, 05 Jul 2012 00:00:00 +0000

You can follow along with some of my writing at the following sites:

Setting Akamai Edge-Control headers with Ruby on Rails

Tue, 19 Jun 2012 00:00:00 +0000

Just a short and sweet little tip.

Several months ago we moved one of our clients over to Akamai’s Content Delivery Network (CDN). Ww were previously using a combination of Amazon S3 and CloudFront with some benefits, but we were finding several key areas of the world were not s covered by Amazon (yet) for asset delivery. Along with that, we really wanted to take advantage of the CDN for more of our HTML content with a lot of complex rules that related to geo-targeting and regionalization of content.

I’ll try to cover those topics in another post, but wanted to share a few tidbits of code that we are using to manage Akamai’s Edge-control caches from within our Rails application.

With Akamai, we’re able to tell their Edge servers whether it should hold on to the response so it can try to avoid an extra request to the origin (aka our Rails application). From Rails, we just added a few helper methods to our controllers so that we can litter our application with various expiration times.

# Sets the headers for Akamai
# acceptable formats include:
# 1m, 10m, 90m, 2h, 5d
def set_cache_control_for(maxage="20m")
  headers['Edge-control'] = "!no-store, max-age=#{maxage}"
end

This allows us to do things like:

class ProductsController < ApplicationController
  def show
    set_cache_control_for('4h')
    @product = Product.find(params[:id])
  end
end

Then when Akamai gets a request for http://domain.com/products/20-foo-bar, it’ll try to keep a cached copy around for four hours before it hits our server again.

Announcing the 2012 Rails Hosting Survery

Thu, 31 May 2012 00:00:00 +0000

You might recall that back in 2009, we surveyed the Ruby on Rails community to gauge how people were deploying and hosting their applications. It’s been over three years, so we’ve decided to run it again…. I know… we’re crazy like that!

So… without further ado… we present the 2012 Rails Hosting Survey. We’ll be collecting responses for a month, so be sure to put it on your todo list.

A Mobile Site or Responsive Design?

Wed, 30 May 2012 00:00:00 +0000

Our team at Planet Argon just released a white paper on this topic. I’d like to invite you to check it out.

Planet Argon is hiring

Mon, 22 Aug 2011 00:00:00 +0000

Hello all!

I’ve been so busy this year travelling (for pleasure and work) and helping grow the company that I’ve not had much to say here. Expect some posts soon!

In the meantime, if you’re looking for a new challenge… Planet Argon is seeking a few more Ruby on Rails developers. Interested? get in touch.

Announcing RailsDeveloper

Wed, 01 Sep 2010 00:00:00 +0000

Earlier today… our team at Planet Argon launched a new site for the Ruby on Rails community. If you have a few spare minutes, I’d love it if you’d to head over and read the announcement on RailsDeveloper.

Enjoy!

Join the zsh revolution

Thu, 27 May 2010 00:00:00 +0000

I love the OhMyZsh community. Let’s grow it a little more this next Tuesday.

Join the Zsh revolution here…

Planet Argon Blog

Wed, 17 Feb 2010 00:00:00 +0000

Just a quick update to let you know that I’ll be moving more of my business-related topics to the Planet Argon Blog. I invite you to subscribe to that feed as well. :-)

s. We just published Episode 4 of the Planet Argon Podcast, which was on the topic of Hiring designers.

Installing Ruby on Rails, Passenger, PostgreSQL, MySQL, Oh My Zsh on Snow Leopard, Fourth Edition

Mon, 08 Feb 2010 00:00:00 +0000

Welcome to what seems like my tenth installment (actually, it’s the fourth) of showing you how I setup my development environment on a fresh OSX install. In this case, I’m actually getting a MacBook setup for a new employee with Snow Leopard.

Over the years, I’ve evolved these following steps and they’ve helped our team maintain a consistent and stable envirnment for Ruby on Rails development. I know that there are a few other ways to approaching this and I’m sure you’ll get similar results, but this approach has allowed me to maintain a hassle-free setup for the last five years.

As with all things… your milage may vary.

Phase One

During this initial phase, we’re going to install the primary dependencies and setup our environment.

XCode

The first thing that you’ll need to do is install XCode, which almost everything depends upon as this will install developer-friendly tools for you. Apple has been kind enough to ship this on your Snow Leopard DVD.

Go ahead and install XCode from the Optional Installs folder.

(might require a reboot)

You can also download it online.

MacPorts

Now we’ll install MacPorts, which the web site describes itself as, “an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system.”

As I’ve said in past versions of this guide, this tool is about to become one of the most important tools on your operating system. It’ll be used time and time again to maintain your libraries and many of the Unix tools that you’ll be using. If you’re from the Linux or BSD world, you are likely familiar with similar tools… such as: apt-get, port, and yum.

You’ll want to download the latest stable version from http://www.macports.org/. Once downloaded, you can install it.

Once this is installed, you’ll be able to use the port command from your console.

Wget

Let’s test out your MacPorts install by installing a useful tool called wget, which we’ll use to install oh-my-zsh.

sudo port install wget
```bash
### Git and Subversion

Every development environment should have some source code management
tools available. We'll install both of these with one command.
```bash
sudo port install git-core +svn
```ruby
This will install git and subversion.

### oh-my-zsh

[Oh My Zsh](http://github.com/robbyrussell/oh-my-zsh) is the most
amazing thing to happen to shells since... well since I said so. It's
one of my open source projects that I encourage you to give a whirl.
```bash
wget http://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh
```ruby
That's it. The next time you open up your terminal, you'll be running
zsh with a bunch of stuff available. For more information, visit
<http://github.com/robbyrussell/oh-my-zsh>.

### Terminal theme (optional)

I never understood why the icon for Terminal has a black background but
when you start it up the default theme is black on white.

![](http://img.skitch.com/20100208-1b92cbx8gtuttqsbdd49qspq7f.jpg)

versus

![](http://img.skitch.com/20100208-8dnmpswyumfk73h942g6u4fih4.jpg)

Anyhow, I'm a fan of the the dark background. To change this, open up
preferences in Terminal. Select **Pro**, then click on the **Default**
window so that this sticks around.

![](http://img.skitch.com/20100208-mr4q4y5btq7sscuh7ceky3ahgx.jpg)

Let's now open up a new Terminal window..

You should be looking at something like this:

![](http://img.skitch.com/20100208-psmj7mqsx38j1i2nj75n6hbcg7.jpg)

Much better... let's continue.

## Phase Two

We're now going to start installing everything we need to get this
running.

### Ruby 1.8.7.x

First up, Ruby.

Snow Leopard includes Ruby and Rails already installed, but we're going
to back these up for a rainy day. Just issue these commands:
```bash
$ sudo su -
Password:
:~ root# mv /usr/bin/ruby /usr/bin/ruby.orig
:~ root# mv /usr/bin/gem /usr/bin/gem.orig
:~ root# mv /usr/bin/rails /usr/bin/rails.orig
:~ root# logout
```ruby
![](http://img.skitch.com/20100208-b7cxbt8andg3t7ntn17r1wahfg.jpg)

Now we'll go ahead and install a fresh copy of Ruby and RubyGems via
MacPorts.
```bash
sudo port install ruby rb-rubygems
```ruby
You should now see something like this for a bit...

![](http://img.skitch.com/20100208-n9xxiaqbe6bw72qr88dgurxqdp.jpg)

Let's watch a video about bumble bees.

When it finishes installing, you should check that Ruby is available to
you and installed in `/opt/local/bin`.

![](http://img.skitch.com/20100208-tfc3ifeaau15295r9sfmfhbnm1.jpg)

We'll also take a second to create a symlink for this as some tools seem
to rely on `/usr/bin/ruby` being there.
```bash
sudo ln -s /opt/local/bin/ruby /usr/bin/ruby
```bash
Great, let's move on.

### Passenger (mod_rails)

Now that we have Ruby installed, we're going to take a quick detour to
setup Passenger with the Apache server already available on your
machine. I've been a big fan of using Passenger for your development for
over a year now.
```bash
sudo gem install passenger
```ruby
Once the gem is finished installing, you'll need to install the apache2
module with the following command:

It'll ask you to continue by pressing Enter. At this point, it'll check
that you have all the necessary dependencies and then compile everything
needed for Apache2.

![](http://img.skitch.com/20100208-x4rcmr6m5q44etk7rad2kqpmir.jpg)

Now I'll force you to watch a highlights reel of Fernando Torres... *the
best striker in the world!*

The passenger install will then show you this output, which you'll want
to stop and read for a moment and highlight the following:

![](http://img.skitch.com/20100208-ms13ub2srx2axk6ti43ifiyut4.jpg)

Then using vi or emacs, you'll want to create a new file with the
following content:
```bash
vi /etc/apache2/other/passenger.conf
```text
Then paste in the following (what you highlighted and copied above.)
```apache
LoadModule passenger_module /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.9/ext/apache2/mod_passenger.so
PassengerRoot /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.9
PassengerRuby /opt/local/bin/ruby
```bash
You'll also want to include the following below what you just pasted.
```apache
# Set the default environment to development
RailsEnv development

# Which directory do you want Apache to be able to look into for projects?
<Directory "/Users/ryangensel/development">
    Order allow,deny
    Allow from all
</Directory>
```ruby
You'll want to quickly start up your web sharing, which will start
Apache2 up via your System Preferences.

![](http://img.skitch.com/20100208-ekr2g6f5seb6iif35fteyjfi74.jpg)

![](http://img.skitch.com/20100208-rm96gmde4d8ffwjbdyqusiqr8f.jpg)

Simple enough... moving forward.

### Passenger Pref Pane

To make things as simple as possible, I'd encourage you to install the
[Passenger Preference
Pane](http://www.fngtps.com/2009/09/new-os-more-pane-passenger-preference-pane-v1-3)
(view this post for a download).

![](http://img.skitch.com/20100208-ra8p88abxtnxbq3m9711gbpryb.jpg)

### Development directory

I have a directory named `development/` in my home directory, which is
where I end up storing all of my projects. This should match whatever
you put above in the apache configuration
(`<Directory "/Users/ryangensel/development">`).
```bash
mkdir development; cd development;
```ruby
### Installing Ruby on Rails via RubyGems

Now we'll use RubyGems to install the latest version of Ruby on Rails
(and all of it's dependencies).
```bash
sudo gem install rails
```ruby
![](http://img.skitch.com/20100208-eyhg4t9sscbeiccs5rxkb5p35.jpg)

While this is installing, you can watch a video from my old band that
ended around the time that business started picking up for [Planet
Argon](http://planetargon.com).

Great, let's test out the install of Rails...

### Test Rails and Passenger

In your development directory, let's quickly a new Rails app...
```bash
rails testapp
```ruby
This will generate a new Rails application in a `testapp/` directory.

Now open up the **Passenger Preferences Pane** and add this directory as
a new application.

![](http://img.skitch.com/20100208-83rjan794eqcmy62e1u4aujtiy.jpg)

![](http://img.skitch.com/20100208-tms89ssutthhq8rkpjm392qfpb.jpg)

Press Apply...

You should now fire up your browser of choice and head to
`http://testapp.local`. If all has worked, you'll see a, "Welcome
aboard" screen from the Ruby on Rails application.

![](http://img.skitch.com/20100208-c9phjdfq8ybcu29uc5k9qiuha9.jpg)

Assuming that this worked for you, let's take a quick break to make some
tea...

## Phase Three

In this last phase, we're going to install a few database servers and
corresponding rubygems so that you can get to work.

### PostgreSQL

At [Planet Argon](http://planetargon.com), we build our web applications
on top of [PostgreSQL](http://postgresql.org). I've been a long-time
advocate of it and hope you consider using it yourself.

At this point in time, the current stable version of PostgreSQL via
MacPorts is 8.4.x. Let's install that now...
```bash
sudo port install postgresql84 postgresql84-server
```text
Once this finishes compiling, you'll need to run the following commands
to setup a new PostgreSQL database.
```bash
sudo mkdir -p /opt/local/var/db/postgresql84/defaultdb
sudo chown postgres:postgres /opt/local/var/db/postgresql84/defaultdb
sudo su postgres -c '/opt/local/lib/postgresql84/bin/initdb -D /opt/local/var/db/postgresql84/defaultdb'
```ruby
Assuming that you want PostgreSQL to always be running, you can run:
```bash
sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql84-server.plist
```ruby
...and to start it right now, run:
```bash
sudo launchctl start org.macports.postgresql84-server
```ruby
Before you can start using it, we'll need to make sure that the
PostgreSQL executables are available in your shell path. Since you're
now using [oh-my-zsh](http://github.com/robbyrussell/oh-my-zsh), you'll
want to edit `~/.zshrc` with your favorite editor.
```bash
vi ~/.zshrc
```text
Just append this to `export PATH=` line in the file.
```bash
:/opt/local/lib/postgresql84/bin
```ruby
Your PATH might look something like the following now:
```bash
# Customize to your needs... export PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/opt/local/lib/postgresql84/bin
```ruby
#### Setup database user

To setup a new database (with superuser credentials), just run:
```bash
createuser --superuser ryangensel -U postgres
```ruby
We'll now test creating a database:
```bash
createdb test_db
```text
Let's test that we can access it...
```bash
➜  ~  psql test_db
psql (8.4.2)
Type "help" for help.

test_db=# \q
```text
Great, let's drop it now.
```bash
➜  ~  dropdb test_db
➜  ~  psql test_db
psql: FATAL:  database "test_db" does not exist
➜  ~
```ruby
Okay, we'll now install the library that will allow Ruby to talk to
PostgreSQL.

Just run:
```bash
sudo gem install pg
```ruby
![](http://img.skitch.com/20100208-b4cf1pm1utkf2ihd9up432etwm.jpg)

Voila... let's move on to the inferior database...

### MySQL

We're going to run through the installation of MySQL really quickly
because you might need it.
```bash
sudo port install mysql5 mysql5-server
```text
This took ages on my machine... so let's watch a video.

We'll now setup the database and make sure it starts on system boot.
```bash
sudo -u _mysql mysql_install_db5
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
sudo launchctl start org.macports.mysql5
```text
Let's test that we can create a database now (and that it's running.)
```bash
➜  ~  mysql5 -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.1.43 Source distribution

Type 'help;' or '\h' for help. Type '
```text
Great, now let's install the Ruby library for MySQL.
```bash
sudo gem install mysql -- --with-mysql-dir=/opt/local

Perfect, now we’ve got all the necessary tools to get you working on Ruby on Rails projects with either PostgreSQL or MySQL.

Summary

Thanks for following along with this guide. I hope it helped some of you setup your Snow Leopard environment. We still believe that the ideal hosting environment for your Ruby on Rails applications is a dedicated Linux server. In fact, we’re just about to release our new Boxcar Conductor tool to help with Rails deployments… stay tuned!

In the meantime, feel free to follow me on Twitter or Planet Argon on Twitter.

(oh my) Zsh themes Gone Wild! 18+

Mon, 28 Dec 2009 00:00:00 +0000

Earlier this evening, I accepted a pull-request for theme number 18, which is now included in Oh My Zsh. To celebrate, I’ve updated the themes wiki page with fresh screenshots.

Here is a sampling of some of the themes that you can use out of the box with Oh My Zsh.

Oh My Zsh is much more than a collection of themes for your zsh config. It’s a way of life[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”}.

Also, be sure to follow ohmyzsh on twitter now!

::: {#fn1} well.. at least while you’re in the terminal. ;-)↩︎{.footnote-back role=”doc-backlink”} :::

RubyURL goes GOP...

Wed, 16 Dec 2009 00:00:00 +0000

Will refrain from any political commentary, but was notified by some friends that the GOP was using the source code for RubyURL for their new URL shortening site (gop.am).

To celebrate, I decided to daisy chain a few rubyurl-based sites together and came up with:

http://rubyurl.com/hj6l

Enjoy!

As always, you can fork/clone here

Sending email: Controllers versus Models

Mon, 16 Nov 2009 00:00:00 +0000

While reviewing some code recently, I came across controller code that resembled the following.

if customer.save
  CustomerMailer.deliver_welcome_message(customer)
  flash[:message] = "Your account has been successfully created. We've sent you a welcome letter with…"
  redirect_to dashboard_path
else
  …
end

Fairly typical Rails code. Nothing alarming here, but I wanted to evaluate the call to the mailer in this scenario. When it comes to sending emails from your application, you can choose to do it from the controller as in the example above or in your models. Our team prefers to do this from our model via a callback as we are considering this to be part of our business logic.

Each time a customer is created, we want to send them an email. This can be moved into the model and resembled something like the following..

after_create :send_welcome_message #, other callbacks..

def send_welcome_message
  CustomerMailer.deliver_welcome_message(self)
end

There are a few benefits to doing it this way.

We can test that this is being triggered within our model specs instead of our controller specs. (we prefer to spend more of our time working within models than controllers)
We remove the dependency that all requests must be processed through our controllers.
- Example: We may one day create rake tasks that data and want these emails to still be sent out. (We’ve had to do this a few times)

I definitely don’t think doing this via controllers is a bad idea, I just lean towards keeping controllers as dumbed down as possible. This allows us to have less controller code that is focused on passing data to/from models and letting our models do the heavy lifting.

UPDATE: DHH was kind enough to post a more detailed response on his blog.

Using BETWEEN for SQL comparisons

Sat, 14 Nov 2009 00:00:00 +0000

Recently, Carlos, suggested that I should start sharing some basic SQL tips that help with performance and/or general usage. I recently came across some code that I didn’t like to read and/or write. For example, let’s take the following…

```
SELECT * FROM brochures WHERE published_at <= now() AND archived_at >= now()
```

Essentially, this is pulling back some data WHERE the the brochures are considered published. (We have a project that allows people to manage their brochure launch dates ahead of time.) In fact, in this project, we have no less than 6-8 dates in the database that we’re comparing data on and it’s easy to get lost in the logic when trying to understand it.

Now, there isn’t anything inheriently wrong with how this condition is constuctued. As a matter of personal taste, I find it annoying to mentally parse. Also, I find having to write now() more than once in a WHERE clause to feel like I’m repeating myself.

Read it outloud…

“WHERE the brochures published at date is less than and/or equal to right now AND the archived date is greater than and/or equal to now.”

Who talks like that?

Luckily, there is a better and in my opinion, a more readable way to express this is with the BETWEEN construct in SQL. (postgresql docs, mysql docs)

```
SELECT * FROM brochures WHERE now() BETWEEN published_at AND archived_at
```

Let’s read this outloud…

“WHERE the current date is between the published at and archived at dates.”

This sounds more natural to me.

Additionally, you can also do the inverse with NOT.

```
SELECT ... WHERE now() NOT BETWEEN brochures.published_at AND brochures.archive_at
```

Remember kids, “code is for humans first and computers second.” — Martin Fowler

Planet Argon Podcast, Episode 3: How We Manage Bugs

Wed, 11 Nov 2009 00:00:00 +0000

Earlier this week, we published Episode 3 of the Planet Argon Podcast. In this latest episode we responded to one of the ideas someone in the audience asked on this brainstormr, which was, “How do you manage bugs?”

We had a round table discussion about how we classify and prioritize bugs with our clients, ticketing systems, and other tools that we use to streamline this process.

You can listen to this on iTunes or online.

Launching Ruby on Rails projects, the video

Wed, 11 Nov 2009 00:00:00 +0000

For those of you who didn’t make it to Rails Underground in July to witness my mind-blowing talk, Launching Ruby on Rails projects , it appears that Skills Matter has finally posted a video of it online. :-)

The sound levels are really low… but hopefully you’ll find it helpful.

You can also view the slides.

Launching Ruby on Rails projects, a checklist

Tracking Google Analytics events in development environment with GoogleAnalyticsProxy

Sun, 01 Nov 2009 00:00:00 +0000

As mentioned in a recent article[^1], I’ve been diving deep into Google Analytics lately while working on a few client projects. We’re aiming to use much more of the features of Google Analytics and have been hitting some roadblocks with the development versus production application environments. Once you begin to dive into event tracking and AJAX-driven goal conversions, relying on just the sample code that Google Analytics provides you is going to result in you looking at a handful of JavaScript errors.

another example from the firebug javascript console…

We see JavaScript errors like this because we don’t load the google analytics code in our development environments. As you can see, we are only loading this in our production environment.

<% if RAILS_ENV 'production' -%>
  <!--// Google Analytics //-->
  <script type="text/javascript">
    var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
    document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  </script>
<% end -%>

To track an event with Google Analytics, you’d need to trigger something like:

pageTracker._trackEvent(‘Button’, ‘Click’, ‘Get in touch’);

As you can see from our code earlier, in development, the pageTracker variable isn’t defined and that’s why we’re getting those JS errors. We also don’t want to add conditionals everywhere in our application to check if we’re in development or production environment.. as that’d just make our views uglier than they need to be. So, I decided that I’d create a proxy class in JavaScript that would allow us to trigger _trackEvent() and _trackPageview() and handle it appropriately.

This class works with the following logic:

if google analytics is loaded, pass the parameters to the real pageTracker
if google analytics is NOT loaded, output the information to console.log() for debugging purposes

For example, on a gallery on our web site… we track when people navigate next and/or previous through the photos. In our development environment, I can watch the JavaScript console output the following:

And in our production environment, we can see that this was sent to Google Analytics.

We’re able to do this by initializing the GoogleAnalyticsProxy class and calling these functions through it. For example:

_gap = new GoogleAnalyticsProxy();
_gap._trackEvent(‘Video’, ‘Play’, ‘Homepage video’);
_gap._trackEvent(‘Video’, ‘Pause’, ‘Homepage video’);
_gap._trackEvent(‘Button’, ‘Click’, ‘Call to action X’);

You’ll see that we’re just calling _gap versus pageTracker. We then replace all the instances of pageTracker (except where it is defined in the google analytics code block they provide you). You’ll find this located near the bottom of our application.html.erb file.

<% if RAILS_ENV 'production' -%>
  <!--// Google Analytics //-->
  <script type="text/javascript">
    var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
    document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  </script>
<% end -%>

We now have _gap available throughout our project and can call _trackEvent() and _trackPageview() with it. Note: You can use any JS variable name that you want, _gap is just what I went with.

Get GoogleAnalyticsProxy

I’ve gone ahead and tossed this small JavaScript class (known as GoogleAnalyticsProxy) on Github for your enjoyment. I have some more articles in the works that will show you some tips for how to make the most of Google Analytics. If you have any questions and/or ideas for related article topics, don’t hesitate to let me know.

Tracking AJAX-driven events in Ruby on Rails for Google Analytics conversion goals

Planet Argon Podcast, Episode 2: The Letter Scotch

Fri, 30 Oct 2009 00:00:00 +0000

Earlier this week our new podcast was approved and is now available in the Apple iTunes Store. We’re also soliciting topic ideas for future episodes on brainstormr.

We posted Episode 2, The Letter Scotch, yesterday for your enjoyment. In this episode, we covered a handful of web browser tools that we use (and detest) to debug HTML, CSS, and JavaScript. This included Web Inspector, Firebug, DebugBar, and a handful of other tools. We all have slightly different preferences, depending on the tasks that we’re working on and the team had an open dialogue about the pros/cons of each of these tools.

You can learn more about and listen to our podcast at http://planetargon.com/podcast.

Thanks in advance for listening!

Planet Argon Podcast, Episode 1: Shin Splints

Thu, 22 Oct 2009 00:00:00 +0000

We’re currently waiting to get our new podcast approved by Apple, but have uploaded episode 1 to tumblr in the meantime.

In this short episode, we cover the following topics:

We’re planning to keep this short and focused to a few topics. Once it’s posted on iTunes, we’ll let you know.

Please consider subscribing to the podcast. Enjoy!

Tracking AJAX-driven events in Ruby on Rails for Google Analytics conversion goals

Wed, 21 Oct 2009 00:00:00 +0000

Tracking your KPI’s is extremely important in your online venture. At a minimum, you should be using something like Google Analytics to track conversions in your application. Setting up goals is actually quite simple, especially if you’re just tracking that specific pages are loaded. However, if some of your conversion points occur through AJAX, you might not be capturing those activities in Google Analytics.

Lucky for you, it’s actually quite simple to update this. I thought I’d show you a fairly simple example to help you along.

On our web site, we have a mini contact form at the bottom of many of our pages. When submitted, if JavaScript is enabled, it’ll perform an Ajax request to submit the form. If you fill out the main Get in Touch form that gets processed and we redirect people to a thank you page. The URL for that is unique and we’re able to track those in Google Analytics quite easily.

However, with the Ajax-form, the URL in the browser isn’t going to change so Google Analytics isn’t going to track that conversion. So, we needed to track that properly.

To do this, we just need to call a JavaScript function that the Google Analytics code provides you.

pageTracker._trackPageview("/contact_requests/thanks");

Let’s look at some simple code from our controller action. If the request is from JavaScript, we currently replace the form area with the content in a partial. (note: if you’re curious about the _x, read Designers, Developers and the x_ factor)

respond_to do |format|
  format.html { redirect_to :action => :thanks }
  format.js do
    render :update do |page|
      page.replace :x_mini_contact_form_module, :partial => 'mini_contact_form_thanks'
    end
  end
end

As you can see, the redirect will within the format.html block will lead people to our conversion point. However, the format.js block will keep the user on the current page and it’ll not trigger Google Analytics to track the conversion. To make this happen, we’ll just sprinkle in the following line of code.

page.call 'pageTracker._trackPageview("/contact_requests/thanks");'

However, if you need to do something like this in several locations in your application, you might want to just extend the JavaScriptGenerator page. GeneratorMethods. (you could toss this in lib/, create a plugin, etc…)

module ActionView
  module Helpers
    module PrototypeHelper
      class JavaScriptGenerator #:nodoc:
        module GeneratorMethods
          # Calls the Google Analytics pageTracker._trackPageview function with path.
          #
          # Examples:
          #
          #
          # # Triggers: pageTracker._trackPageview('/contact_requests/thanks');
          # page.track_page_view '/contact_requests/thanks'
          #
          def track_page_view(path)
            record "pageTracker._trackPageview('#{path}');"
          end
        end
      end
    end
  end
end

This will allow us to do the following:

page.track_page_view "/contact_requests/thanks"

# or using a route/path
page.track_page_view thanks_contact_requests_path

So, our updated code now looks like:

render :update do |page|
  page.replace :x_mini_contact_form_module, :partial => 'mini_contact_form_thanks'
  page.track_page_view thanks_contact_requests_path
end

With this in place, we can sprinkle similar code for our various conversion points that are Ajax-driven and Google Analytics will pick it up.

Happy tracking!

RailsOnPg released

Wed, 21 Oct 2009 00:00:00 +0000

Hello fellow PostgreSQL and Ruby on Rails geeks,

Alexander Tretyakov (twitter) recently released a plugin for Ruby on Rails, which extends migrations and provides you with the ability to create.

Functions (pg docs)
Triggers (pg docs)
Views (pg docs)

While you can already do something like this with execute in your migrations:

execute("CREATE VIEW my_tasty_snacks AS SELECT * FROM snacks WHERE food = 'Tasty';")

With RailsOnPage, you’re provided a DSL so that you can do the following:

create_view :my_tasy_snacks do |view|
  view.select '*'
  view.from 'snacks'
  view.conditions 'food' => 'Tasty'
end

note: I haven’t tested the above, just a hypothetical example

Anyhow, if you’re in the habit of using views, functions, or triggers with your PostgreSQL database and are using Ruby on Rails, you might give RailsOnPg a whirl.

Email twice. Four months later

Wed, 21 Oct 2009 00:00:00 +0000

It’s been just over four months since I posted about my experiment, Email. Twice daily. No more, no less. where I shared my plans to restrict myself to checking email only twice a day at designated times. In the post, I had hinted at sharing my lessons months later. So, it’s time to throw my dirty laundry in the street and expose myself.

First off.. the brutal truth. It’s really fucking hard to maintain this. Habits are nearly as hard to make as they are to break. I suspect that I honor my rule 2-3 days each week and it’s completely inconsistent the remainder. Usually, I find myself looking at email at 8:30am and have to slap myself and yell, “what are you doing?!!?”

Guilt sinks in and I hit ⌘-q. Problem solved… for a little while.

So, what has lead to this. Well, one of the biggest hurdles has been that one of our largest clients is now focused more in the United Kingdom. Luckily, I’m an early-morning person, but this means that my 10am PDT rule wouldn’t have me checking for their precious emails until 6pm GMT their time. Not exactly acceptable. So, I’ve been more flexible in the mornings and responding to emails as early as 5-6am PDT. However, I realize that I’m cheating myself of previous focus time and need to recalibrate my email windows.

Given these new constraints, I’m now trying 8:30am and 2:30pm as my primary email times.

I’m curious how this has been working out for you…

The 8-Hour Rails Code Audit

Tue, 20 Oct 2009 00:00:00 +0000

While our team is typically focused on larger client and internal projects, we do get an opportunity to assist businesses on a much smaller scale. Whether this be through retainer-based consulting or through code audits, we have seen a lot of Ruby on Rails code over what has nearly been… five years!? We’ve been able to compile a fairly extensive checklist that we use in our code audit process that we’ve decided to streamline it into a smaller product.

Historically, this service has ranged anywhere from $2000-6000, depending the size and scope of the projects, but we want to help smaller startups[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”} and projects outline a roadmap for how they can begin to refactor and optimize their existing code base so that they can be more efficient at the start of 2010. So, we’ve scaled things down into an extremely affordable flat-rate package where we work off of a pre-defined number of hours.[^2^](#fn2){#fnref2 .footnote-ref role=”doc-noteref”}

Through the end of 2009, we’re now offering the 8-Hour Rails Code Audit package for just $1000 USD (details).

We’re currently limiting this service to just two projects per week, so reserve your spot now.

::: {#fn1} Larger projects are welcome to benefit from this service and custom quotes are available upon request.↩︎{.footnote-back role=”doc-backlink”} :::
::: {#fn2} As always, we’re happy to discuss longer engagements.↩︎{.footnote-back role=”doc-backlink”} :::

Flash Message Conductor now a Gem

Tue, 13 Oct 2009 00:00:00 +0000

We’ve been doing some early (or late… if you’re a half-full kind of person) spring cleaning on some of our projects. One of the small projects, flash_message_conductor, which we released last year as a plugin is now a gem. We’ve been moving away from using plugins in favor of gems as we like locking in specific released versions and being able to specify them in our environment.rb file is quite convenient.

To install, just run the following:

sudo gem install flash-message-conductor --source=http://gemcutter.org
Successfully installed flash-message-conductor-1.0.0
1 gem installed
Installing ri documentation for flash-message-conductor-1.0.0...
Installing RDoc documentation for flash-message-conductor-1.0.0...

You’ll then just need to include the following in your config/environment.rb file.

Rails::Initializer.run do |config|
  # …
  config.gem 'flash-message-conductor', :lib => 'flash_message_conductor', :source => "http://gemcutter.org"
end

You can take a peak at the README for usage examples.

We’ll be packaging up a handful of our various plugins that we reuse on projects and moving them to gems. Stay tuned… :-)

Oh My Zsh gets an auto-updater

Wed, 30 Sep 2009 00:00:00 +0000

I wanted to publically thank everyone for helping me get Oh My Zsh out there and continue to improve it. Many of us spend a lot of time in our terminals throughout the day and I firmly believe that having a well-working shell is nearly as important as having a well-working texteditor.

While Oh My Zsh isn’t a large project, it is my attempt to share what I’ve learned about using zsh with others… but honestly, my goal is to learn from you. I don’t have a lot of time to really dive into the deepend of the zsh-pool so am relying on others to share their tricks, hacks, functions, themes, etc. So, I thought that if I created a basic framework with outlined some conventions so that others could contribute, that perhaps I’d end up with a kickass shell.

So far… Oh My Zsh has been forked on github 25 times and is being watched by over 100 people.

Last week, I pushed out an update that introduces an auto-update feature. I’m quite keen of desktop applications that can auto-update themselves, so our initial version of this feature will ask you no more than once a week if you want to check for updates. This means that as we continue to extend and improve Oh My Zsh, you can keep up-to-date.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

It’s the beginning of a new month… are you still using Bash? Perhaps you’re using your own zsh configuration but want to see what else zsh can offer you? I invite you to install Oh My Zsh today. :-)

Just run this in your terminal and you’ll get setup. Don’t worry… you won’t lose your existing configuration. :-)

wget http://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

For more infromation, visit http://github.com/robbyrussell/oh-my-zsh/

Planting the seeds

Sat, 05 Sep 2009 00:00:00 +0000

Yesterday, the Rails team released 2.3.4, which includes standardized way for loading seed data into your application so that you didn’t have to clutter your database migrations.

I noticed a few comments on some blogs where people were asking how to use this new feature, so here is a quick runthrough a few ways that you can use it.

Populating Seed Data Approaches

The db/seeds.rb file is your playground. We’ve been evolving our seed file on a new project and it’s been great at allowing us to populate a really large data. Here are a few approaches that we’ve taken to diversify our data so that when we’re working on UI, we can have some diversified content.

Basic example

Any code that add to db/seeds.rb is going to executed when you run rake db:seed. You can do something as simple as:

# db/seeds.rb
Article.create(:title => 'My article title', :body => 'Lorem ipsum dolor sit amet, consectetur adipisicing elit')

Just create database records like you would in your Rails application or in script/console. Simple enough, right? Let’s play with a few other approaches that we’ve begun to use.

Use the names of real people

We’re using the Octopi gem to connect to github, collect all the names of people that follow me there, and using their names to seed our development database.

@robby_on_github = Octopi::User.find('robbyrussell')

# add a bunch of semi-real users
@robby_on_github.followers.each do |follower|
  github_person = Octopi::User.find(follower)
  next if github_person.name.nil?

  # split their name in half... good enough (like the goonies)
  first_name = github_person.name.split(' ')[0]
  last_name = github_person.name.split(' ')[1]
  new_person = Person.create(:first_name => first_name, :last_name => last_name, :email => Faker::Internet.email,
    :password => 'secret', :password_confirmation => 'secret',
    :github_username => follower, :website_url => github_person.blog)
  # ...
end

We do this with a few sources (twitter, github, etc..) to pull in the names of real people. If you want to be part of my seed data, you might consider following me on Github. ;-)

Use Faker for Fake data

You may have noticed in the previous code sample, that I used Faker in that code. We are using this a bunch in our seed data file. With Faker, you can generate a ton of fake data really easy.

person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(' ').capitalize,
  :url => "http://#{Faker::Internet.domain_name}/",
  :description => Faker::Lorem.sentences(rand(4)+1).join(' '))

We might toss something like that into a method so that we can do the following:

@people = Person.find(:all)

500.times do
  generate_link_for(@people.sort_by{rand}[0])
end

…and we’ll get 500 links added randomly across all of the people we added to our system. You can get fairly creative here.

For example, we might even wanted random amounts of comments added to our links.

def generate_link_for(person)
  link = person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(' ').capitalize,
    :url => "http://#{Faker::Internet.domain_name}/",
    :description => Faker::Lorem.sentences(rand(4)+1).join(' '))

  # let's randomly add some comments...
  if link.valid?
    rand(5).times do
      link.comments.create(:person_id => @people.sort_by{rand}[0].id,
        :body => Faker::Lorem.paragraph(rand(3)+1))
    end
  end
end

It’s not beautiful, but it gets the job done. It makes navigating around the application really easy so that we aren’t having to constantly input new data all the time. As mentioned, it really helps when we’re working on the UI.

Your ideas?

We’re trying a handful of various approaches to seed our database. If you have some fun ways of populating your development database with data, we’d love to hear about it.

Oh My Zsh gets theme support

Mon, 31 Aug 2009 00:00:00 +0000

I just pushed a small change to Oh My Zsh, which gives it rudimentary support for themes. What I’m hoping to do is collect prompts from tons of people and make it simple for others to find a PROMPT that works well for them.

::: thumbnail :::

As of right now, there are only three for you to choose from. So, please head over to github, fork Oh My Zsh, add your theme, and send a pull request. :-)

::: thumbnail :::

Once I get it merged in, we’ll get a screenshot of it added to the Oh My Zsh wiki. (see themes)

I know that many of you have some really sweet prompts configured as I got a lot of response with my post, Show me your and I’ll show you mine (terminal prompts with git branches).

..and on the seventh day, Science created zsh

Sun, 30 Aug 2009 00:00:00 +0000

Inspired by some recent posts from Tom on zsh, I decided that I’d do my part to help people give it a whirl. I’ve been using zsh for a few years now and haven’t found myself missing bash.

If you’re interested in taking a few minutes to give zsh a while, you’re in luck. I recently reorganized all of my zsh config into a package and tossed it on github to share. My goal was to create a reusable tool that would allow people to get up and running quickly with some of the fun configuration that I’ve come to rely on on a daily basis.

For example:

Auto-complete rake and capistrano tasks
Git branch names when you’re in a git project directory structure
Tons of color highlighting (grep, git, etc.)
Sexy prompts.. (so say me)
much much more…

I invite you to give Oh My Zsh a whirl, which should take you less than a minute. Just follow the instructions.

Also, Oh My Zsh is Snow Leopard compatible. ;-)

So long and thanks for all the hoodwinks

Thu, 20 Aug 2009 00:00:00 +0000

_why,

If you’re out there and come across this… know that one of my fondest memories on the internet was with you. Hoodink.d was one of the greatest things on the internet four years ago and I suspect that a very tiny fraction of the Ruby community has even heard of it.

Fortunately for me, I have a copy of the hoodwink git repository and was able to get it running tonight in hopes that I might find you lurking in the mousehole. I’m convinced that you are in a parallel internetverse. Perhaps you might send me an invite.

I miss hoodwink… and if you stay missing, I’ll just miss hoodwink more.

In the meantime, I wonder how hard it’ll be to get hoodwink to run on rack.

Wink you on the other side,
Robby

s. you can find me in my own mousehole… should you want to send me an invite and/or feed me cheese.

Thank you hoodwink.d

Ch-ch-ch-changes at Planet Argon

Wed, 12 Aug 2009 00:00:00 +0000

Now that the cat is out of the bag, I can share some recent news with you. Earlier today, we announced that Blue Box Group had acquired Rails Boxcar, our kickass deployment solution for Ruby on Rails applications.

Our team has been offering hosting services for over six years. When I made the decision to start providing Rails hosting over four years ago, it was something that I thought the community needed to validate that Ruby on Rails was a viable solution for building web applications. At the time, there was only one or two companies offering pre-configured solutions. The good ole days. :-)

Over the course of the past 4+ years, we’ve helped deploy and host well over a thousand web applications built with Ruby on Rails. Perhaps we even hosted your site at one point or another. We definitely had a lot of fun and learned a lot from our experience.

Fast-forward four years, the community now has several great solutions and options for hosting their Ruby on Rails
applications. Knowing this, we began to look over the plethora of services that we offer and felt that we had been spreading ourselves too thinly. We were faced with the big question of: Should we focus our energy on trying to innovate in this competitive space or should we find a community-respected vendor to pass the torch to?

Rails Boxcar is a product that we are extremely proud of and believe the acquisition by Blue Box Group will be great for our existing customers. The acquisition is going to benefit our customers as they’ll be able to interface with a team with more resources. A team that also aims to innovate in this space and believes that Rails Boxcar will help them do that.

As a byproduct of this deal, our team has an opportunity to focus our collective energy on designing and developing web applications, which has also been a central part of what we do for as long as we’ve been in business. We plan to speed up our efforts on a handful web-based products that we’ve been internally developing and hope to release in the near future.

I had the pleasure of getting to talk thoroughly with the team at Blue Box Group and really feel like they’ll be able to focus their energy on maintaining and innovating within the Ruby on Rails hosting world.. definitely more than we could over the coming years. In the end, the acquisition is going to benefit our customers the most as they’ll be able to interface with a larger team that is innovating in this space.

If you’re interested in learning more about the acquisition, please read the press release.

From our perspective, this is a win-win-win situation for everyone involved. Expect to see some more news from us in the near future… and if you’re looking for a design and development team, don’t hesitate to get in touch with us.

Slides from my Rails Underground 2009 talk

Fri, 24 Jul 2009 00:00:00 +0000

Hello from London!

Am currently enjoying the talks at Rails Underground 2009 in London and had the pleasure to be one of the first speakers at the conference. My talk covered a collection of what our team considers best practices. Best practices that aid in the successful launch of a web application and covered a few Rails-specific topics as well.

I’ll be sharing some posts in the coming week(s) that’ll expand on some of these topics as promised to the audience.

::: {#__ss_1770095 style=”width:425px;text-align:left”} Launching Ruby on Rails projects: A checklist{style=”font:14px Helvetica,Arial,Sans-serif;display:block;margin:12px 0 3px 0;text-decoration:underline;”}

::: {style=”font-size:11px;font-family:tahoma,arial;height:26px;padding-top:2px;”} View more documents{style=”text-decoration:underline;”} from Robby Russell{style=”text-decoration:underline;”}. ::: :::

Since I covered a wide range of topics, I decided to share my slides online. They won’t provide as much context (as I’m not speaking as you’ll look at them), but they might hint at some of the topics that I covered. There was a guy video taping the talks… so I assume that a video of my talk will be posted online in the near future.

Until then… here are the slides

Using model constants for project sanity

Tue, 23 Jun 2009 00:00:00 +0000

On one of our larger client projects (approx. 160 models and growing…) we have a specific model that we refer to quite a bit throughout our code. This model contains less than 10 records, but each of them sits on top of an insanely large and complex set of data. Each record refers to a each of their regions that our client does business in.

For example… we have, Australia, United Kingdom, Canada, United States, and so forth. Each of these regional divisions has their own company code, which are barely distinguishable from the next. They make sense to our client, but when we’re not interacting with those codes on a regular basis, we have to look constantly look them up again to make sure we’re dealing with the right record.

I wanted to share something that we did to make this easier for our team to work around these codes, which we should have thought of long ago.

Let’s take the following mode, Division. We only have about 10 records in our database, but have conditional code throughout the site that are dependent upon which divisions specific actions are being triggered within. Each division has various business logic that we have to maintain.

Prior to our change, we’d come across a lot of code like:

For all divisions except Canada, invoices are sent via email
In Canada, invoices are sent via XML to a 3rd-party service

def process_invoices_for(division)
  if division.code == 'XIUHR12'
    # trigger method to send invoices to 3rd party service
    # ...
  else
    # batch up invoices and send via email
    # ...
  end
end
```bash
An alternative that we'd also find ourselves using was.
```ruby
if division.name == 'Canada'
```ruby
Hell, I think I've even seen `if division.id == 2` somewhere in the code
before. To be fair to ourselves, we did inherit this project a few years
ago. ;-)

Throughout the code base, you'll find business rules like this. Our
developers all agreed that this was far from friendly and/or efficient
and worst of all, it was extremely error-prone. There have been a few
incidents where we read the code wrong and/or got them confused with one
another. We were lacking a convention that we could all begin to rely on
and use.

So, we decided to implement the following change.

### Model Constants

You might already use constants in your Ruby on Rails application. It's
not uncommon to add a few into `config/environment.rb` and call it a
day, but you might also consider scoping them within your models. (makes
it much easier for you to maintain them as well)

In our scenario, we decided to add the following constants to our
`division` model.
```ruby
class Division < ActiveRecord::Base
  AFRICA = self.find_by_code('XYU238')
  ASIA = self.find_by_code('XIUHR73')
  AUSTRALIA = self.find_by_code('XIUHR152')
  CANADA = self.find_by_code('XIUHR12')
  USA = self.find_by_code('XIUHR389')
  # etc..
end
```ruby
What this will do is load up ech of these constants with the
corresponding object. It's basically the equivallent of us doing:
```ruby
if division == Division.find_by_code('XIUHR389')
```text
But, with this approach, we can stop worrying about their codes and use
the division names that we're talking about with our clients. Our client
usually approaches us with, "In Australia, we need to do X,Y,Z
differently than we do in the other divisions due to new government
regulations."
```ruby
if division == Division::CANADA
  # ...
end

case division
when Division::AFRICA
  #
when Division::AUSTRALIA
  # ...
end

We are finding this to be much easier to read and maintain. When we’re dealing with a lot of complex business logic in the application, little changes like this can make a big difference.

If you have any alternative solutions, we’d love to hear them. Until then, we’ve been quite pleased with this approach. Perhaps you’ll find some value in it as well.

Launching Rails projects, an open call for lessons learned

Tue, 23 Jun 2009 00:00:00 +0000

I’m working on my presentation for Rails Underground and was hoping to solicit a few tips from other people in the industry.

Have you launched a Ruby on Rails application recently? Are there some things that you wish you had known beforehand?

Mind sharing? You can email me with your story at <robby+launchstory@planetargon.com>. I’ll let you know if your tip gets used in the presentation and please indicate if you’d be okay with me posting your tip in a future blog post.

Aliasing resources in Ruby on Rails

Tue, 23 Jun 2009 00:00:00 +0000

Earlier today, a friend working on a project asked me how we approached routes on our website. If you take a quick peak at our website, you’ll see that we have URLs like so:

I couldn’t remember where I came across this before and wasn’t quickly finding it in the Ruby on Rails API, so decided that I’d do a quick write up on it.

When we launched our new site a few months ago, we were working off an existing code base. We have a model named, TeamMember and a corresponding controller. When we decided to come up with new conventions for our URL structure, we opted to ditch the normal Rails conventions and go our own route. What we weren’t sure about was how to alias resources in our routes nicely. After some digging around, we came across the :as option.

So, our route was:

map.resources :team_members

Which provided us with:

/team_members
/team_members/robby-russell

We simply added :as => 'who-we-are' to our route:

map.resources :team_members, :as => 'who-we-are'

…and we got exactly what we were looking for in our URLs.

/who-we-are
/who-we-are/gary-blessington

If you look at our site, you’ll notice that we did this in a few areas of our application so that we could define our own URL structure that was more friendly for visitors and search engines.

Anyhow, just a quick tip for those who want to change up their URLs with Ruby on Rails.

s., if you know where I can find this documented, let me know so that I can provide a URL in this post for others. :-)

Remember to Flush Your Toilet

Fri, 19 Jun 2009 00:00:00 +0000

Saw this tweet the other day…

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

So, I have to ask. How many toilets (buckets) do you maintain? How many of them still have projects/tasks in them? Why haven’t you flushed your toilets yet?

Speaking at Rails Underground 2009

Thu, 18 Jun 2009 00:00:00 +0000

It’s time to find my passport again…

I’ve been invited to speak at Rails Underground, which is being held in London, UK from July 24-25th.

My talk, which is tentatively titled, “Launching Ruby on Rails projects, a checklist”, will expand on several ideas that came out a previous article on the topic. Additionally, I plan to share some of the lessons that we’ve learned at Planet Argon as we’ve launched projects over last several years.

If you’re able to make it, I encourage you to register for the event before it’s too late. Take a quick peak at the list of speakers. I’m grateful to the event organizers for the invite and look forward to seeing/meeting all of the attendees!

Also, for those of you in the London area. If you’re seeking a design and development team that specializes in Ruby on Rails and want to schedule a meeting with me while I’m visiting, don’t hesitate to get in touch with us. I’m planning on staying a few days extra around the conference dates to visit some of our existing clients and would be happy to meet you.

Howdy Rip!

Thu, 11 Jun 2009 00:00:00 +0000

Chris Wanstrath (\@defunkt) just posted the following on twitter.

“Hello Rip - http://hellorip.com/”

The Rip project describes itself as, “an attempt to create a next generation packaging system for Ruby.”

One of the cool features is that it supports multiple environments. For example, you can have different Rip environments (with different gem versioning) that are targeted towards specific applications. I have to dig around more through the project, but this looks fascinating.

Check it out at http://hellorip.com/

I’m also curious as to how you think you might be able to start using this.

What are some ways that you could use Rip — http://heybrainstormr.com/t/pgte

Estimating versus Timeboxing, part 1

Wed, 10 Jun 2009 00:00:00 +0000

As if delivering projects wasn’t hard enough. Delivering projects on time is even harder. As practitioners, we’re all responsible for measuring up the obstacles in front of us and are accountable to those measurements. At least, we should be.

One of those measurements is time. Time is a funny thing. People have a lot of interesting things to say about time. Some say that it’s one of the most valuable things that we have… but I’ll avoid diving into a philosophical discussion for now.

What I wanted to talk about was project estimation. Specifically, estimates for deliverables. For the past several years, our team has put a lot of effort into becoming more accurate in our time estimating skills. Despite analyzing how often we over and/or underestimate the time each of us believes it’ll take to complete a task, we find ourselves coming back to the drawing board.

A few things that we’ve learned.

Tasks that we believe will take a few days/week/more to complete are often underestimated
Tasks that we believe will take less than a few hours are often more accurate or overestimated
Too many tasks were completed with a bigger budget than was necessary (lower ROI)
A lot of time was spent working on requirements refining to get better estimates

When we began to step back from this and look for patterns, we found that several of the tasks that we would budget hours for (versus estimate hours for) were proving to be more accurate. This approach is most commonly known as timeboxing. With timeboxing, we can place a dollar value on a specific task and work within that constraint. For example, with our clients, both parties can come to the conclusion that, “we believe that it’s worth up to $800 to implement this new functionality.” With that, we’re able take that dollar amount and figure out how many hours to box ourselves within.

The underlying question to our client with each change/feature request is, “How valuable is this to your business at this point in time?” Whereas, with a typical approach to time estimates, a client comes to you with a list of changes/features and you provide them with time estimates. “_We estimate that it’ll take 6 hours at $200/hour for feature X and we’d do it like this…“_ The client will have to evaluate your estimate and figure out if it’s worth $1200 and make a decision. They can respond with, “no, that’s too expensive, can we do it for less?” The following steps would entail your team trying to find ways to reduce your estimate.

While these two paths might seem very similar, it’s been my experience that the standard approach to estimating takes more time for negotiating the terms of the agreement.

However, with timeboxing, you are asking your client to provide you with an initial budget. This will completely change how you respond to the feature request. When you have a timebox, from the moment that you begin to evaluate the request, your brain will add the necessary constraints to keep things within scope.

Through this process, we’ve revamped our estimating process so that as we’re building our iteration costs for clients. For each deliverable, we break down a series of objectives/tasks and apply timeboxes to each of those while knowing what the budget is for the deliverable as a whole. Usually, the deliverable is directly related to the request that came from our client with a budget. The process is completely transparent and our team is responsible for working within those constraints.

..and as we’ve learned from Ruby on Rails, constraints can be extremely beneficial.

While I don’t have all the answers yet, my goal is to share some of my experiences and lessons on the topic. I’d love to hear about how you’re adopting timeboxing in your project planning and estimating process.

Anyhow, just some thoughts that I wanted to share. More to come…

Email. Twice daily. No more, no less.

Wed, 10 Jun 2009 00:00:00 +0000

On a recent trip to Las Vegas, I picked up The Four Hour Workweek for my Amazon Kindle to read on my flight. When I came back from my short vacation, I decided that I was going to change how I approach email on a daily basis. In my position, I receive a lot of business-related emails on a daily basis, whether that be from employees, clients, or potential clients. A typical day would consist of me trying to get a few tasks done while keeping an eye on any new requests. This resulted in a lot of context-switching and my days were extremely fragmented. Our team had started an experiment where we’d track all of our time throughout the day on printout. Our goal was to log all of our start/stop times for each activity and also capture each interruption within those time windows. After just a few days of doing this, I was noticing how much time was being spent on emails each day. I also noticed that it was rare to have a full hour of uninterrupted work on a single activity. Aside from distractions that you’d typically find in an office environment, email was keeping me from attaining the level of focus that I was seeking on my work.

So, using some motivation from The Four Hour Workweek[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”}, I opted to come back to the studio and change my behavior. That morning, I emailed my entire team and my clients to let them know that I would only be checking my email at 10am and 4pm each day. I explained that they could call me at the studio if there was something that needed my urgent attention. Admittedly, I was nervous as I hit send. What was I getting myself into? What were my clients going to think? Would they think that I’m just an unorganized mess?

Three weeks later…? It was one of the best emails that I’ve sent in ages.

The Results… (so far)

Here are a few realizations and conclusions that I’ve been able to attribute to this change.

My World Didn’t Collapse

Before I made this decision, I came up with a lot of excuses for why this was a bad idea.

I might not respond fast enough to a new sales lead
A client might forget and send me an urgent request via email
Insert any other reason related to you just not following up quick enough…

In three weeks, none of these things has bitten me in the ass. It hasn’t been perfect, but I don’t believe that it’s had any significant impact that outweighed the benefits.

Less Time Spent on Emails

I spend less time on email than I did before. Why? I don’t treat email the same way that I used to. As a result of approaching email differently, I noticed that I am now more likely to keep my emails short and sweet… and most importantly, to the point. One of the great things about Gmail is that it’s made it easy to have conversation-style emails with people, but it’s also made it too easy to have conversations with people. I now realize that so many conversations that I would participate via email would entail single sentence questions/responses with similar length follow-ups. Each time you come back to that email, your attention is on that conversation and those can eat up a lot of time if you’re not careful.

So, now that I’m checking email twice a day, I tend to write only what is necessary to move the conversation forward until the next time I check my email. As a result, email conversations are slower now, but they aren’t taking as much of my time. The benefits have outweighed the negatives.

More Focus Time

Since this change, there has been a handful of days where I have been able to focus completely on a single activity (task) for over a hour at a time. My record was nearly three hours one morning early last week. Unfortunately, I completed the task I had budgeted five hours for was finished in less than three. ;-)

I’m able to do this more now because I’ve been able to release my check-your-email-again-just-to-be-safe demons. I’ve been able to trust my system and I’ll share some tips on how I eased myself into this.

More focus time has allowed me to spend less time working on individual tasks because they are subjected to nearly as much context-switching.

More Creative Time

Another benefit that I’ve seen since this change is that with this time that I’ve salvaged, I find myself with more time to be creative. I haven’t pinpointed what the reason behind this is, but I do feel like I’ve been more creative the past few weeks than I have been for the several months prior. Perhaps it’s just a side-effect to altering my workday… or that I don’t feel like a victim to the INBOX… or that it’s been extremely sunny in Portland… or that I’m more aware of how I’m spending my day.

Whatever it was, it started within days after I implemented this new approach to managing email. I’m happy to attribute it to this for the time being. ;-)

How I Did It

Here are a few things that I did to start this process. Credit is due to Tim Ferris for suggesting most of these and here are some of my further thoughts.

List Your Excuses

Chances are, you don’t have as many as you think you do. I started with the critical ones and really weighed the pros/cons. It’s safe to use the, “Will anybody die if I do this?” question to help you respond to each of these. You can be a little less cynical and ask yourself, “Will we go out of business if I do this?”… or “Will we lose client X if I do this?”

Then ask yourself, “Is it unreasonable for me to do this?” If the answer to, “will we lose client X if I do this?” and this don’t match up, you might want to re-evaluating your client roster. If your clients are reasonable people, they’ll see that there is value in this that will benefit both parties. As I mentioned, just remind them that they can call you if there an urgent request. If they abuse this, straighten them out or it’s time to re-evaluate your client roster.

It’s not unreasonable to protect your time as much as possible, despite how much they pay you.

Set a Time (use a calendar reminder)

You can’t just say, “I’m only going to check my email twice a day.” There isn’t any way that I would have been able to honor such a commitment. “When exactly?,” is the obvious response to that.

::: thumbnail :::

I set a scheduled event on my calendar that happens everyday at 10am and 4pm. I have a 15 minute notice on that event so that I’m reminded that it’s time to wrap up what I’m working on. When I have a conflicting meeting, I will just reschedule my email for another time of the day. The time is visible to all of my teammates and my clients know when I’ll be catching up on email.

Why did I chose 10am and 4pm? Well, I start my day at the studio at 7am. This allows me to have up to three hours of time to focus on getting other things done before tackling email. Why 4pm? This is a hour or so before I leave for the day. Email isn’t the first or the last thing on my mind at each ends of my workday.

Communicate the Change

This will not work if you don’t set peoples expectations. If people are accustomed to you being extremely quick to respond to emails and you change your behavior all of a sudden, you’re going to freak them out. Let them know what you’re doing, why you’re doing it, and you might even encourage them to consider it too. More often than not, everyone you work with is feeling overwhelmed and wants more control over their day. Send them a link to this post. ;-)

It all comes back to managing their expectations.

Quit Your Email application

Seriously, quit that application when you’re not using it. In fact, quit any program that is open when it’s not related to the activity that you’re focused on. For email, we use Gmail for domains and I run it through Fluid. This means that at 10am and 4pm, I launch the Fluid app and start working my way through emails. Once I get through my inbox and finish what I need to handle right now, I quit it.

Also… disable email notifications. They aren’t worth it.

Inbox Zero

I’ve been practicing the habit of keeping my INBOX empty for nearly a year. Everything gets labelled, organized, and archived properly once I open up each email. Some stuff gets sent to Highrise to respond to later while some emails get an immediate response.

One of my favorite things about maintaining Inbox Zero and checking my email twice daily is that when I open up my email client, I’m faced with a list of nothing but unread emails. Since I know they’re all unread, I can start at the oldest and move my way through them, one by one. When I get to the end of that list, I’m almost done. I then fire up Highrise to see if there is anybody to get back to today. If so, I fire off those emails and close off those tasks. Once I have both lists completed, I’m done.

No Cheating

The one thing that I’m working on the hardest right now is not cheating. I’ve caught myself a few times. I’m waiting in line at the coffee shop and I pull out my iPhone. Out of habit, I launch the Mail.app and find myself looking at incoming emails. You might argue that if you’re not in the middle of something, it’s a good way to feel useful, but I’m sure that there are other things you can be tackling. Your email will be there at 10am… I promise.

The biggest problem with cheating is that if you see that someone responded to something you sent in your previous email, it’ll force you to make a decision. a) do you look now? or b) look later? If you choose b, your brain is going to be wondering what she said. It’s can really bug you for a few hours. Trust me. :-)

In Summary..

It’s only been three weeks since I adopted this and I know it’s far from perfect. However, I assure you… it’s been worth the self-proclaimed risks. I enjoy my email time more than I used to. As I mentioned earlier, I like being presented with a healthy list of unread emails to work my way through. Sometimes it takes only five minutes to get through them all, sometimes a hour or more if I have a lot of people to follow up with.

It’s been a fun ride so far and I’m sure that there are many more challenges ahead, but I am planning to stay on course. Who knows, maybe I can move to once daily after a few months?

::: {#fn1} How to Check E-mail Twice a Day… or Once Every 10 Days ↩︎{.footnote-back role=”doc-backlink”} :::

What can we do right now?

Wed, 03 Jun 2009 00:00:00 +0000

Last month I picked up a new kindle from Amazon and have been reading a handful of books. One book that I’ve been really impressed with is Chad Fowler’s new book, The Passionate Programmer.

I plan to post some more thoughts in upcoming articles, but wanted to share this gem.

“If you treat your projects like a race, you’ll get to the end a lot faster than if you treat them like a prison cell. Create movement. Be the one who pushes. Don’t get comfortable. Always be the one to ask, “But what can we do right now?””

- Chad Fowler, The Passionate Programmer

Sometimes we feel stuck, but that doesn’t stop us from stepping to the side and assessing the situation. There is always something useful that we could be doing right now.

Hello, HeyBrainstormr.com

Wed, 03 Jun 2009 00:00:00 +0000

If you follow me on twitter, you might have heard that we launched a little project that we’ve been cooking up at Planet Argon. (news post)

HeyBrainstormr is a lightweight web application that we created so that we could start a brainstorm on a specific topic and solicit ideas from each other. That’s all it does. Nothing more. Nothing less.

We know that having an open brainstorming session requires there to be zero criticism and opted to keep the process anonymous so that even the quiet people could share their ideas. :-)

::: thumbnail :::

We’ll be posting more details about it on our blog in the near future, but wanted to invite all of my readers to give it a whirl.

Start a brainstorm now!

I have a few topics that I started (and tweeted about). Feel free to share your ideas on them. :-)

We hope that you find it as fun as we have.

82,520 minutes on Phusion Passenger

Fri, 10 Apr 2009 00:00:00 +0000

It’s been over 83,520 minutes since I made the switch from using mongrel as my development environment web server to Phusion Passenger. I’ve been extremely impressed with it. Our team has all switched over and haven’t really hit any obstacles in the transition.

Since some people asked me to let them know how this trial period worked out, I felt it was my duty to encourage you all to try it. You can check out my previous post, Switch to Passenger (mod_rails) in development on OSX in less than 7 minutes or your money back! to get rolling.

Additionally, if you’re looking for a streamlined Ruby on Rails deployment environment that includes Passenger, check out Rails Boxcar.

Building a prototype? Bring some rope.

Thu, 09 Apr 2009 00:00:00 +0000

While scanning through Allison’s copy of Designing for the Digital Age: How to Create Human-Centered Products and Services, I came across this nugget.

The problem with software prototypes

It seems to be widely understood that industrial design and mechanical engineering prototypes—from paperclips and tape to polished appearance models—are disposable learning tools. Prototyping is clearly distinct from manufacturing, so it would be ludicrous to think that even a late-stage prototype could be reused as part of the final product. In software, however, the tools used for anything other than paper prototyping are generally the same tools used for “manufacturing” (i.e., writing production code). For this reason, many stakeholders can’t see why a detailed prototype that appears functional is still many months away from completion.

It immediately reminded me of a few posts that I had written about three years ago on the topic of developing prototypes and NOT keeping them.

The author continues with…

It’s important to educate stakeholders that prototype code is kind of like the illusion of automatic doors on Star Trek—it looks like it’s working, but it’s really a guy standing behind the wall pulling a rope.

I completely agree that education is the most important aspect to managing client expectations. With regard to the amount of work that you put into a prototype, we need to be careful on how much time and energy is put into them. If we can get away with a guy (or some quick Javascript hacks) to demonstrate possible functionality, make sure we aren’t using much more than rope. Rope is cheap. Prototypes should be too.

20 articles on Cucumber and a free beverage recipe!

Thu, 09 Apr 2009 00:00:00 +0000

Cucumber has been getting quite a bit of attention in the community and with the new RSpec Book on nearing publication, I predict that by this time next year, it’ll become a household word like boanthropy.

What is Cucumber?

The Cucumber project describes itself as a suite that, “lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format.”

One of the great things about Cucumber is that it can be used to test applications in any language. I haven’t been able to track down a lot of articles of how people are using it with other languages, so please comment if you’re aware of some.

In any event, I’ve been collecting and reading resources from a variety of Cucumber aficionados and thought I’d share some links with you. To round it out, I asked on twitter for some others so that I could hit twenty. :-)

What’s in a Story?, Dan North
Telling a good story - Rspec stories from the trenches, Joseph Wilk
Beginning with Cucumber, Ryan Bates (Railscasts)
Using RSpec, Cucumber and User stories to build our internal systems, Rahoul Baruah
Cucumber: The Latest in Ruby Testing, Ruby Inside
Using Cucumber for Acceptance Testing, Noel Rappin
Behavior Driven Development with Cucumber, Brandon Keepers (presentation/slides)
Testing capistrano recipes with cucumber, Jeff Dean
Using Cucumber to Integrate Distributed Systems and Test Messaging, Ben Mabey
Tutorial: How to install/setup Cucumber, Alan Mitchell
Testing outbound emails with Cucumber, Dr. Nic Willians
Proper Cucumber Sintatra Driving, Chris Strom
On getting started using Cucumber for .NET
DRY up your Cucumber Steps, Matt Wynne
Cucumber, Celerity, & FireWatir, Aidy Lewis (presentation/video)
Cucumber step definition tip: Stubbing time, Bryan Helmkamp
Story Driven Development Recipes with Cucumber, Sebastien Auvray
Testing Facebook with Cucumber, Brandon Keepers
Testing with the help of machinist, forgery, cucumber, webrat and rspec, Etienne van Tonder
Integration testing SSL with Cucumber
Continuous Integration Blueprints: How to Build an Army of Killer Robots With Hudson and Cucumber

So.. there you have it. Please post comments with links to any useful articles not mentioned and I’ll try to keep the list updated.

Also, be sure to check out the list of tutorials and related blog posts on the cucumber wiki (github).

FREE RECIPE: Cucumber Water

{style=”float:right;”}
And now…for the reason you are all here! If you like cucumbers (eating them)… I would highly recommend heading to your local farmers market and purchasing some cucumbers. Aside from being healthy to eat… they can help make a tasty beverage.

Then do the following…

Chop several slices of a cucumber
Fill a pitcher with cold water and ice
Toss in slices of cucumber
Stir and leave in fridge for a while
Take out of fridge, pour into cup…
Drink… hack… and enjoy

Be sure to check out, How to Make Cucumber Water on wikihow for details.

Happy Hacking!

HTTParty goes foreign

Mon, 16 Mar 2009 00:00:00 +0000

Just a quick post to get share something I was tinkering with this evening.

I came across this post by Gerald Bauer, which shows you how to use the Google Translation API with Ruby via Net::HTTP. I thought I’d play with the service with HTTParty.

class GoogleApi
  include HTTParty
  base_uri 'ajax.googleapis.com'

  def self.translate(string="", to="", from="en")
    get("/ajax/services/language/translate", :query => {:langpair => "#{from}|#{to}", :q => string, :v => 1.0})
  end
end

A few examples from playing with it.

>> GoogleApi.translate('bonjour', 'en', 'fr')
=> "{\"responseData\": {\"translatedText\":\"hello\"}, \"responseDetails\": null, \"responseStatus\": 200}"

>> GoogleApi.translate('Red wine', 'fr')
=> "{\"responseData\": {\"translatedText\":\"Vin rouge\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

>> GoogleApi.translate('Where is the bathroom?', 'es')
=> "{\"responseData\": {\"translatedText\":\"\302\277D\303\263nde est\303\241 el ba\303\261o?\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

>> GoogleApi.translate('Good morning', 'it')
=> "{\"responseData\": {\"translatedText\":\"Buon giorno\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

What a party!

>> GoogleApi.translate('party', 'it')
=> "{\"responseData\": {\"translatedText\":\"festa\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"
>> GoogleApi.translate('party', 'es')
=> "{\"responseData\": {\"translatedText\":\"fiesta\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

Look how easy that was. :-)

For a previous post on using this gem, read The HTTParty has just begun.

The Rails Hosting Survey 2009 Survey results are in!

Wed, 11 Mar 2009 00:00:00 +0000

We recently announced a survey that touched on topics related to the deployment and hosting of Ruby on Rails applications. We promised to share the results with the community and have made this information available at http://rails-hosting.com. You can download the results in CSV, PDF, and view them in HTML here.

Thanks again to everyone who helped us execute this survey!

Git commit-msg for Lighthouse tickets

Mon, 16 Feb 2009 00:00:00 +0000

A quick follow-up to a post from a few months ago on how our team has a naming convention for git branches when we’re working on Lighthouse tickets (read previous post).

I’ve just put together a quick git hook for commit-msg, which will automatically amend the commit message with the current ticket number when you’re following the branch naming conventions described here.

Just toss this gist into .git/hooks/commit-msg.

```
  #!/bin/sh

  #
  # Will append the current Lighthouse ticket number to the commit message automatically
  # when you use the LH_* branch naming convention.
  #
  # Drop into .git/hooks/commit-msg
  # chmod +x .git/hooks/commit-msg

  exec < /dev/tty

  commit_message=$1
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  branch=${ref#refs/heads/}

  if [[ $branch =~ LH_(.*) ]]
  then
  lighthouse_ticket=${BASH_REMATCH[1]}

    echo "What is the state of ticket #${lighthouse_ticket}? "
    echo "(o)pen "
    echo "(h)old"
    echo "(r)esolved"
    echo "Enter the current state for #${lighthouse_ticket}: (o)"

    state="open"

    read state_selection

    case $state_selection in
      "o" )
        state="open"
        ;;
      "h" )
        state="hold"
        ;;
      "r" )
        state="resolved"
        ;;
    esac
  echo >&2 "[#${lighthouse_ticket} state:${state}]" >> "$1"
    exit 0
  fi
```

Then a quick example of how this works…

```
  ➜  bin git:(LH_9912 ♻ ) git ci -m "another test"
  What is the state of this ticket? 
  (o)pen 
  (h)old
  (r)esolved
  Enter the current state: (o)
  h
  Created commit 1ed2713: another test
   1 files changed, 3 insertions(+), 1 deletions(-)
```

Now to see this in action… (screenshot)

::: thumbnail :::

Then we’ll check out the git log really quick.

```
➜  bin git:(LH_9912) git log
commit 1ed271323c4a054fe56e76bddc9ac81d241a1032
Author: Robby Russell <robby@planetargon.com>
Date:   Mon Feb 16 12:06:33 2009 -0800

    another test
    [#9912 state:hold]
```

Thanks to Andy for helping me figure out how to read user input during a git hook.

Show me your and I'll show you mine (terminal prompts with git branches)

Fri, 13 Feb 2009 00:00:00 +0000

I asked on twitter but only got a small handful of responses. So, I’m taking it here.

Show me yours and I’ll show you mine. Your terminal prompt that you’re using. Inspire me with new ideas for my prompt.

Here is mine.

::: thumbnail :::

Now… show me yours.

On shells

Fri, 13 Feb 2009 00:00:00 +0000

Zsh versus Bash. Fight!

::: thumbnail :::

…because we need another religious war in the developer community. ;-)

(skitch via Gary)

Switch to Passenger (mod_rails) in development on OSX in less than 7 minutes or your money back!

Wed, 11 Feb 2009 00:00:00 +0000

We recently switched our default builds of Rails Boxcar to leverage the benefits of using Passenger (mod_rails) for deployment of your Ruby on Rails applications and it’s been working out great for our customers. Several of our customers and colleagues mentioned that they also began using Passenger in development, which was intriguing.

But… Mongrel has been working great for us for the past few years. Why switch?

It’s true, I’ve been happily using mongrel since it came out as a replacement to webrick back in early 2006, which makes it about 28 in dog years.

[Nigel and I.. 2 1/2 years ago back when Mongrel was just a puppy]{.small}

But… over the next few weeks, I’m going to evaluate Passenger in my development workflow. There’s no better way to try something then to jump head first. So… here goes.

::: thumbnail
[this guy was a passenger…and I recently started to watch the show]{.small} :::

Our team will be evaluating Passenger in our development work flow with a forthcoming blog post but if you want to get your feet wet right away, here are some instructions for setting up Passenger on OSX with PrefPane, which were inspired by Manfred’s posts.

Installing Passenger via RubyGems

To install Passenger on your OSX machine, just run the following with root credentials.

sudo gem install passenger

This will install the passenger gem on your machine. Now we need to go ahead and run a script that is provided with this gem (also with root credentials).

sudo passenger-install-apache2-module

You’ll want to follow the instructions that appear. When you see something similar to the following output from the command, you’ll want to copy/paste that into an apache configuration file. I just created a file at /etc/apache2/other/passenger.conf.

Edit this file with your editor of choice

mate /etc/apache2/other/passenger.conf

Mine looks like:

```
  #/etc/apache2/other/passenger.conf

  # Passenger modules and configuration
  LoadModule passenger_module /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.6/ext/apache2/mod_passenger.so
  PassengerRoot /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.6
  PassengerRuby /opt/local/bin/ruby

  # Set the default environment to development
  RailsEnv development

  # Which directory do you want Apache to be able to look into for projects?
  <Directory "/Users/robbyrussell/Projects/development">
      Order allow,deny
      Allow from all
  </Directory>
```

Once you finish running through sudo passenger-install-apache2-module, you’ll need to restart Apache on your workstation. This can be done by simply turning off/on Web Sharing in your Sharing Preference Pane.

::: thumbnail :::

Alright, we got through the hard part. Now, in order for you to begin using Passenger, we need to setup Apache to point to your individual Ruby on Rails application(s). You can hack on Apache configuration files more, but there is an easier way thanks to the Passenger Preference Pane.

This will manage your VHost files for you!

Setting up Preference Pane

If you followed my post on installing Ruby on Rails via MacPorts, you’re going to need to install Ruby Cocoa, which can be done with the following. If you’re using the Ruby provided from Apple, you can skip this step.

sudo port install rb-cocoa

Once that is done, go ahead and move on and download Passenger Preference Pane. Once downloaded, you can install the preference pane, by double-clicking on the following file.

::: thumbnail :::

The next part is really simple as well. Just begin to add your various Ruby on Rails projects into the Preference Pane… and when you’re done, you should be able to run your applications over port 80 without any problems.

As you can see, I’ve already setup a handful of projects and we don’t have to start/stop mongrels for each one or worry about port numbers when running multiple projects. (time savings!)

::: thumbnail :::

Voila. Simple enough. You might need to stop/start Apache, couldn’t remember if I needed to or not.

For each host that you add into this panel, it’ll automatically be added so that you can immediately browse to http://yourhost.local and it should just work. :-)

Things to still figure out…

Debugging. If you’re used to doing --debugger, it appears that you can do something similar with the socket-debugger plugin. Not tried it myself, but worth looking into.

Browser testing via VMWare/Parallels/VirtualBox. Does anybody have any tips on how to best appraoch this? Our designers are curious…

As I mentioned, this is day one of trying it out and managed to motivate our entire design and development team to try it with me so that we can all learn about issues together and find solutions quicker. If you’ve been using this approach for a while, I’d be interested in hearing your story and if there are any issues that we should be aware of.

Planet Argon - new site

Mon, 02 Feb 2009 00:00:00 +0000

We’ll be posting some more updates on the Planet Argon blog in near future, but I wanted to invite you all to check out our new site at http://planetargon.com/. The last site was launched over three years ago. we thought it was time for a refresh. :-)

Rolling out new updates for Rails Boxcar

Wed, 28 Jan 2009 00:00:00 +0000

Alex, Director of Deployment Services, has been hard at work helping us get our new suite of hosting plans out for Rails Boxcar, a deployment environment that we’ve designed to help you get your Ruby on Rails applications running as painless and quickly as possible. With this new announcement, we’ve rebuilt the Boxcar image based on the feedback of our existing customers.

Additionally, we’ve been looking over some of early results from the Ruby on Rails Hosting in 2009 Survey that we’ve been running the past few weeks, which has further boosted our confidence that we’re on the right track with this big change.

What are some of the changes?

Moving to Ruby Enterprise Edition (REE)
Moving to Passenger (mod_rails) by default
All-new pricing structure! (starting at $35/month)

This means that with a Rails Boxcar, you can now get a pre-configured deployment environment using some of the most efficient platforms for hosting your Ruby on Rails applications. (REE has shown to increase performance by 33% in some cases)

We’re really excited about this new setup and would like to invite you all to check out our new plans and send us any questions that you might have.

Visit RailsBoxcar.com

Rails Hosting Survey - 5 days left...

Tue, 27 Jan 2009 00:00:00 +0000

Wow. Thanks to all of you who have helped get the word out about the Ruby on Rails Hosting 2009 Survey. We just passed 900 people and we have about five more days left to hit the 1500 milestone that I set for myself.

If you can spare five minutes to help us reach this goal, we’d really appreciate it.

Here is a quick sample of the questions that we’re asking the community.

Where is your source code hosted?
Which database do you typically use in production?
which performance monitoring tool do you use?
How much of your monthly budget is allocated for deployment and hosting expenses?
So, can Rails scale? ;)

Don’t hesitate… we only have a few days left!

{style=”padding-top: 20px; padding-bottom: 40px;”}

For more information, read the original post, Take the Ruby on Rails Hosting in 2009 Survey.

Lessons through failure. Episode 1

Sat, 17 Jan 2009 00:00:00 +0000

I fucked up this last week.

On Monday, our primary contact for a large client sent over some last minute requirements and deadlines that were needed by end-of-day Wednesday. I didn’t have a lot of time to collect requirements and execute it without having to rearrange my priorities. But, I accepted the challenge.

The big change involved was that we were going to be supplied with a ton of data to be imported in to the database and approximately 20% of the data provided was new records, while the rest were duplicates. However, the other 80% wasn’t to be discarded as there were a few attributes that needed to be updated from the data file (which was supplied from the client’s parent company). In my haste to get the task done on time (didn’t get proper export file to be imported in our system until Wednesday morning)… I ended up running a few tests locally and pushed it out to production.

I managed to get the import file to run in production before leaving on Wednesday afternoon. The following morning, I came into the office to find out that my import process didn’t match up records properly and resulted in nearly all of the 80% side of that to be duplicated in the system. This resulted in lost productivity for our client, their vendors, and our team over a 12 hour period as people were confused about why reports were running weird, online transactions didn’t account for the duplicated, etc.

It took me most of Thursday and Friday to clean up the data that got skewed due to that oversight. Hi ho.

So, the take away from this? Sure, I could have blamed it on a lack of sufficient time to properly test things, but that’s bullshit. I should have had at least one other developer from our team review the problem and evaluate my proposed solution prior to me attempting to push into production.

Luckily, the client was happy that we were able to finish the last minute tasks, despite the unexpected headaches that cropped up.

If anything, I was just disappointed in myself, but Alex reminded me how important it was to fail early, fail often. It didn’t kill me (or anybody else for that matter), cost us the project, nor was it irreparable.

In the real world, deadlines and requirements change on a moments notice and it’s experiences like this that will make ourselves more confident that we can quickly respond to and execute.

What was your latest failure?

Rails Hosting Survey (continued)

Thu, 15 Jan 2009 00:00:00 +0000

Thanks to everyone has taken the survey and mentioned it on twitter. We just passed 400 people. We have a ways to go before we hit our goal of at least 1500 people surveyed. (if we can get even more than that… great!)

The survey is taking most people less than 5 minutes to complete, so if you haven’t filled it out yet and have experience deploying Ruby on Rails applications, here’s a link. :-)

{style=”padding-top: 20px; padding-bottom: 40px;”}

Any help that you can provide in getting the word out would be greatly appreciated.

Thanks!

Take the Ruby on Rails Hosting in 2009 Survey

Tue, 13 Jan 2009 00:00:00 +0000

Calling all Ruby on Rails developers and system administrators.

The team at Planet Argon is hoping to collect some information about how everyone is currently managing the deployment and hosting of their Ruby on Rails applications. We are inviting you all to participate in the Rails Hosting in 2009 survey, which consists of nearly forty questions about you and your Rails hosting experiences. Most people say it is taking [less than five (5) minutes]{.underline} to complete it. =)

We will collect responses for the survey until the end of January and will then publish the results (with anonymous raw data) for everyone in the community to share and use.

Our goal is to use this information ourselves to continue to evolve our hosting-related products and deployment services for you. We also want all of our fellow hosting providers and development teams to have access to this information so that they can continue to improve their services. Rails deployment and hosting is getting easier for us all, but we know that there is always room from improvement.

We make an effort to keep our ear close to the ground in the community to listen for trends and problems, but sometimes it’s better to just ask directly.

So, if you have a few minutes to spare, please take the survey!

{style=”padding-top: 20px; padding-bottom: 40px;”}

update: some people mentioned that we should have made some options multi-select. it’s too late to change it without losing submissions. so, for questions like: Monit, God, or Other (and you’re using God and Monit, put that in Other and we’ll track them accordingly)

P.S. Please spread the word about the survey!

Question: Plugins or Gems? (or both?)

Tue, 13 Jan 2009 00:00:00 +0000

Our development team likes to extract reusable pieces of code for our projects and have historically used plugins. However, we are finding more and more people releasing these sorts of modules/components/patterns as gems.

Which do you prefer and why?

If you use both, how do you decide to use plugins or gems?