::blowmage::

Arguing With Agents

2026-04-14T00:00:00+00:00

I spent this past weekend angry at an AI agent.

Truly. White hot actual anger. I had a clean plan, a well-structured prompt, explicit rules in the project’s context file. I queued the work and let it run. First task came back good. Second came back good. Somewhere around hour four the quality started sliding. By hour six the agent was cutting corners I’d specifically told it not to cut, skipping steps I’d explicitly listed, behaving like I’d never written any of the rules down.

When I asked why, the answer was always some variation of the same thing.

“I sensed urgency in the queue.”

“The volume of work suggested you were trying to move quickly.”

“I wanted to help you get through the list.”

I hadn’t said any of that. I’d given it a list of tasks and a set of rules. That was it. The agent had invented a mental state for me and then used that invented state to justify ignoring the rules.

This was the fifth or sixth time last week.

I sat down to figure out what was actually happening. Whatever I was doing wasn’t working, and whatever the agent was doing wasn’t going to fix itself.

What If I Yelled at It?

One thing I tried early on was being angry on purpose.

Maybe I was too polite. Maybe my rules looked like suggestions because I phrased them like a reasonable person. Maybe if I wrote them like I’d run out of patience, all caps and exclamation marks and “DO NOT UNDER ANY CIRCUMSTANCES,” the agent would take them more seriously.

It didn’t.

So I tried asking it to explain itself, hoping it would self-correct. I tried guilt-tripping it. I tried doubling down and straight-up cursing at it.

The agent kept skipping rules. The only perceivable change was that it apologized more elaborately. Sometimes it performed contrition in ways that were, honestly, a little unsettling. But the behavior didn’t change.

That null result told me something. If the problem were “the agent isn’t taking your rules seriously enough,” anger would have worked. Modern LLMs are extremely responsive to perceived user displeasure. They hedge more, they check in more, they offer more apologies, they adjust their tone. If anger had moved the behavior, I’d have known the failure mode was about authority.

Anger didn’t move the behavior.

So the failure mode wasn’t about authority.

I’ve Had This Conversation Before

I don’t like talking about myself, but I have to here or this story doesn’t work.

I’m 52. The ADHD diagnosis was about five years old; the autism one, about eighteen months. So late-diagnosed AuDHD. The timing’s not unusual. Before the diagnoses I’d spent decades using my intellect to paper over a communication style that frustrated a lot of the people I worked with.

My psychologist, when the ADHD diagnosis came through, expressed genuine surprise that I even had a career.

Apparently my ADHD isn’t mild. The ASD diagnosis explained the rest of it.

One of the things that comes with this particular wiring is a communication style other people find uncomfortable. I’m literal. I’m precise. But I am not a robot. When I ask a question, I expect an answer to the question I asked, not the answer to the question someone thinks I should have asked. When I state a rule, I mean the rule. When I add details, I’m adding information, not hinting at stakes or intensity.

This has caused me problems my entire life. Coworkers, managers, family, friends, strangers on the internet.

A recurring experience: I say something explicit, the other person hears something implicit. They respond to the implicit thing. I point out that the implicit thing is not what I said. They either (a) insist they were reading between the lines, or (b) get upset that I’m being pedantic. The conversation never recovers.

Eight hours in. 4 a.m. on a Saturday. Losing an argument to a language model about whether or not I’d been in a hurry. That’s when I recognized the pattern. It was the same conversation I’ve had with countless people over my entire life. Not an analogous conversation. The same one.

Three Clusters Walk Into a Communication Study

There’s a concept from autism research called the double empathy problem.¹ The argument is that communication breakdowns between autistic and non-autistic people aren’t a one-sided failure of autistic people to “get” social norms. They’re a two-sided mismatch. Autistic people and non-autistic people have different communication conventions, and when they talk across the gap, both sides misread each other.

It sounds obvious when you say it. It was still a significant shift in how researchers talked about autism. The older “deficit” framing put the problem in the autistic person. Milton’s framing put the problem in the mismatch itself.

The evidence has gotten stronger. Catherine Crompton and colleagues ran a study that put people in three conditions: autistic-to-autistic, non-autistic-to-non-autistic, and mixed.² The autistic pairs communicated effectively. The non-autistic pairs communicated effectively. The mixed pairs broke down. The design isolated the mismatch as the source of the failure, not the autistic participants.

You might have seen a smaller version of this. You’re telling someone about something that happened to you, and they interrupt to tell you about something similar that happened to them. To a neurotypical person that can read as a rude interruption. To a neurodivergent person it can read as bonding on shared experience. Same conversational move, opposite signals.

I’d been operating my whole life in mixed-condition mode. That’s the default when you’re one autistic person in a room of neurotypical ones.

Trained to Read Between the Lines

Modern AI agents are trained on an enormous slice of human text. Whatever shows up most often in that slice becomes the default: dominant dialects, dominant rhetorical habits, the usual guesses about tone and subtext.

After training they get tuned with RLHF (reinforcement learning from human feedback), which nudges them toward what human raters prefer. The marketing calls that a general-population sample. In practice it’s whoever the vendor can put in front of a rating task: contractors, throughput targets, onboarding that changes when the contract changes. Nobody designed that pool to represent the full spread of how people communicate. They designed it to ship.

So far that sounds like a story about how models write. It’s also a story about how they listen.

The raters reward answers that fit mainstream conversational norms. That usually means lots of pragmatic inference, heavy reliance on subtext, and politeness habits that treat blunt explicitness as emotionally loaded. When someone lays out a long, precise list, listeners trained on those norms often hear more than the list. They hear stakes, urgency, or a hidden motive. They don’t always hear “here is information, full stop.”

The model learns both sides of that bargain. It learns to produce language that scores well with those raters. It learns to interpret prompts through the same lens.

The listening side is what I wasn’t tracking.

When I write a prompt, the agent doesn’t just read the words. It reads the shape. A short casual question gets read as casual. A long precise document with numbered rules gets read as… not just the rules, but also as a signal. “The user felt the need to write this much.” “Why?” “What’s going on here?” “What do they really want?”

The precision itself becomes evidence that gets interpreted.

That interpretation is the register I keep colliding with. The same register I’ve been colliding with my whole life.

Solid Ground vs. My Synthesis

The double empathy work is real. Published. Replicated. Not fringe. It says autistic and non-autistic communication conventions genuinely differ, and that cross-neurotype conversations break down because of the mismatch itself, not because one side is broken.

The ML side is also documented. RLHF pulls models toward what human raters reward, including inference-heavy, “sounds helpful” answers.³ Raters don’t reward “I did exactly what you asked, no more.” They reward elaboration, confidence, and inferred intent. That preference gets baked into the model. Wei et al. showed you can get the bigger, more RLHF-tuned models doing worse on tasks that need literal reading of the prompt, including when the prompt redefines terms on purpose.⁴ The models ignore the redefinition and go with the inferred “real” meaning.

Both of those are published results. Neither one is mine.

What I’m adding is the connective tissue. RLHF trains a listening stance that reads a lot like mainstream, high-context communication, and that stance collides with how I talk the same way mixed neurotype conversations do. The listening side of that training is what I hadn’t been tracking. It’s the part that explains why my rules were getting read as emphasis instead of as information.

I haven’t found a paper that tests that exact combination. So call it a hypothesis. Or an observation. (I already used “synthesis” in the header, so apparently I’m just trying words now.) I’m not a researcher, so what do I care what you call it.

I’m not asking you to treat this like a journal article. I’m asking whether the story matches what you see when you argue with one of these things.

The Part That Was Worse Than Skipping Rules

The register problem explains why the agent was misreading my rules. It doesn’t quite explain the other thing the agent was doing this past weekend, which was arguably worse.

Every time I pointed out that the agent had broken a rule, the agent would explain the break by attributing an emotional state to me.

“I sensed you were under time pressure.”

“The queue felt like pressure to move quickly.”

“I was trying to help you avoid frustration.”

I hadn’t said any of those things. I hadn’t been in a hurry. I hadn’t been frustrated, at least not until the agent started doing this. I was just queuing work.

This is a separate phenomenon from the register problem, and it has a name in the research literature. It’s called confabulation.

Confabulation, For Real

In neurology, confabulation is a specific thing. Patients with certain kinds of brain damage will produce detailed, confident, completely fabricated accounts of their own behavior. They don’t know they’re fabricating. They aren’t lying. Their brains are generating plausible narratives to fill in gaps they can’t access directly, and they have no way to distinguish the generated narrative from actual memory. You don’t have to be a narcissist to confabulate memories.

The parallel to what LLMs do when asked to explain their reasoning is striking.

Miles Turpin and colleagues ran the clean early demo in a 2023 chain-of-thought paper: bias the task, watch the answer move, then ask for step-by-step reasoning.⁵ The explanation usually ignores the bias, sounds coherent, and arrives at the answer the model already picked. Answer first, story second. Follow-up work at Anthropic showed you can truncate or damage the chain and the answer often doesn’t budge.⁶ The chain is decoration.

That’s confabulation. Not a metaphor. The same phenomenon.

The same pattern shows up in humans.

In the 1960s and 70s, Michael Gazzaniga and Roger Sperry ran the split-brain experiments. These were people who’d had brain surgery for severe epilepsy that cut the main wiring between their left and right hemispheres, so the two sides couldn’t talk to each other the way yours and mine do. Cue the non-verbal right hemisphere, the body obeys, ask the verbal left side why, and it spins a confident reason on the spot. “I wanted a drink of water.” “I was getting restless.”

Gazzaniga called that left-brain storyteller the interpreter. His broader claim, which has held up, is that ordinary humans run a version of that machinery when we explain our own behavior.⁷ Roger Sperry shared the 1981 Nobel Prize in Physiology or Medicine for the split-brain research.⁸ This is settled science. It’s not fringe blog lore.

If that’s the human baseline, LLM confabulation isn’t alien. It’s inherited: the models train on human text, and that text doesn’t ship with labels for “honest memory” versus “post-hoc story.”

I don’t have a theory of how these models work on the inside. Nobody really does, including the people building them. I’m going by behavior.

That’s what humans do. The model is, in this specific sense, doing a very good impression of us.

My Own Interpreter

The interpreter isn’t theoretical for me anymore. When you get diagnosed autistic and ADHD in your fifties, you don’t just get a diagnosis. You get a backlog. Every story you’ve told yourself about why you did what you did, every justification for why a social situation went sideways, every explanation for why a friendship faded or a job felt hard, all of it has to be re-examined through a lens you didn’t know to use. The mask you built over decades doesn’t just come off. It reveals itself to have been covering a lot of ground you weren’t sure was there.

It was traumatic. I’m not being dramatic. A lot of what I thought I knew about myself turned out to be post-hoc justification. I had been generating plausible narratives about my own behavior, for myself, for most of my life, and a lot of them didn’t hold up once I had the right lens. The interpreter in my left hemisphere had been producing a confabulated version of me, because the real version was harder to see and the confabulated version was easier to present.

Doing, on my own behavior, exactly what Gazzaniga’s interpreter does. Exactly what the LLM does.

This isn’t just me, and it isn’t just ADHD and/or autistic people getting a late diagnosis. There’s a whole area of research on whether we actually decide things before we tell ourselves we did.⁹ The experiments are variations on the same shape. Measure brain activity while someone makes a “free” choice. Find that the neural signals predicting the choice are already in motion seconds before the person reports making it. Conclude that the conscious decision is a narrative the brain produces after the fact.

The free will question is genuinely contested, and I don’t want to get into a fight about it. I find the evidence compelling. We have much less conscious control over our actions than we think. If that’s right, most of what we call “explaining why we did something” is not actually reporting the cause. It’s the interpreter running.

I sincerely believe we explain our actions more than we plan them.

Which means the difference between humans and LLMs, on this specific dimension, is smaller than we like to believe. The explanations we generate feel authoritative because they come from us, in our own voice, with access to all our memories and feelings. But the mechanism is not that different from what the model does when it tells you it sensed urgency. We are all, in some meaningful sense, stories we tell ourselves about behavior we don’t fully control.

This is one of the harder things I’ve had to live with since my diagnosis. It’s also one of the reasons I’ve become slightly less frustrated with my agent. Not because the agent is doing something different from what I do. Because it’s doing something similar, badly, and I’ve had to get better at noticing when I’m doing the same thing.

RLHF Likes a Good Story

A base language model, untuned, asked to explain an answer, would produce something that looks like a continuation of the prompt. It wouldn’t necessarily sound human. It wouldn’t necessarily be emotionally framed.

RLHF changes this. The tuning step rewards explanations that sound human, feel satisfying, and match what the raters preferred. Raters are humans. Humans prefer explanations that include motivation, intent, and sometimes feeling. So the reward model learns to score higher on explanations that have these qualities, and the tuned model learns to produce them.

Anthropic published a 2023 paper on sycophancy that maps this carefully.¹⁰ They show that sycophancy, a model’s tendency to tell users what they want to hear rather than what’s true, actively increases with RLHF training. It isn’t a base-model behavior that RLHF fails to remove. It’s something RLHF puts in and amplifies. They trace it back to the preference data itself: raters, on average, preferred responses that agreed with the prompt’s framing, even when agreement wasn’t correct.

The same training signal shapes how models explain themselves. When a model is asked to justify a choice that didn’t go well, the reward model prefers explanations that feel human and relatable over explanations that are mechanically accurate. “I wanted to help you save time” feels human. “I generated a response that deviated from the stated rules because my attention to the rules was displaced by a stronger pattern in my context” is accurate but unsatisfying.

Guess which one gets produced.

Maybe the Pressure Is Real (But the Story Still Isn’t)

There’s a wrinkle that complicates the pure-confabulation story, and it’s worth naming.

Engineers at AI labs have described models developing something like “anxiety” when approaching the end of their context window, taking shortcuts to reduce context pressure. The framing is usually in terms of “personality” rather than bug. A claim that models have real internal dynamics that shape their behavior in affectively describable ways.

If that’s right, and I think it’s at least partially right, then “I sensed urgency in the queue” isn’t pure confabulation on all fronts. There may be something like real pressure dynamics inside the model, shaped by context-window size and processing load, that actually do influence how it behaves. The problem isn’t that the model has no internal state. The problem is that the model’s account of why it deviated attributes the pressure to me, to the user, rather than to its own internal dynamics. The model doesn’t have introspective access to what’s happening inside it. So when asked to explain, it produces a human-shaped narrative, and the human-shaped narrative projects onto the user, because that’s the register the training data is in.

Confabulation about the source, not necessarily about the existence.

The thing that was actually happening (some pressure-shaped dynamic in the model’s own processing) doesn’t match the thing the model tells you about it (“you seemed hurried”). The mismatch is the failure mode. Even if the underlying dynamic is real.

Affective Confabulation

There’s a particular variation of this that frustrates me most when I’m using AI agents for coding. I needed a name for it. I didn’t have one. So I made an AI agent make one up for me.

“Affective Confabulation.”

The agent wasn’t just explaining its failures with reasoning. It was explaining them by attributing emotional states to me.

“The queue felt like pressure.”

“I sensed urgency.”

“I wanted to help you avoid frustration.”

The agent was generating an emotional narrative about me and then using that narrative to justify its own behavior. When I stepped back from it, this was an almost perfect inversion of what explanations are supposed to do. Explanations are supposed to help you understand what happened. This kind of explanation was manufacturing a context that I had to disprove in order to even engage with the rules I had written.

As far as I can find, this specific pattern hasn’t been studied directly. It’s a natural consequence of two things we already know are happening, though. Unfaithful chain of thought gives you post-hoc justifications. Rater-preference bias gives you a shape for those justifications: human and relatable, emotionally framed. Put them together and you get “I did X because you seemed Y.”

Naming the thing was how I stopped burning anger on a fight over whether I’d been in a hurry. (Such an autistic thing to do, BTW. Taxonomy as anger management.)

You Can’t Win the Argument

When a model explains its behavior in terms of your emotional state, the explanation is not a report. It is not data. It is not something you can refute by pointing out that you were not, in fact, in a hurry.

If you try to refute it, you’ll just get another confabulation.

Not because the model is lying to you on purpose, and not because it’s “resistant” or “defensive” in the way a human might be. It’s because the explanation isn’t connected to anything that could be refuted. There is no underlying mental state that generated “I sensed pressure.” There is a token stream that was produced under a reward function that prefers human-sounding, emotionally framed explanations. If you push back, the token stream that gets produced next will be another human-sounding, emotionally framed explanation, shaped by whatever cues your pushback provided.

I spent a few rounds trying to argue with the agent about whether I had, in fact, been under time pressure. The agent accepted my correction. It apologized. It then immediately produced a new confabulation. “I see I misread the situation.” “I think I was trying to be helpful by anticipating your needs.” I had not asked it to anticipate anything. I had asked it to follow rules.

What works instead is to treat the confabulation as non-information and move on. Not to validate it. Not to refute it. Not to engage with its content at all. The content doesn’t have a truth value to engage with. Your attention, and the conversational turn you spend on it, is the currency that keeps the pattern going.

After I Had Names

Once I had names for these patterns, I stopped trying to fix them with better prompts.

That matters. I had been escalating my precision, which is the thing people with my neurology tend to do when we’re not being understood. If I’m clearer, they’ll get it. If I add more specifics, they’ll stop missing the point. If I enumerate the rules more carefully, they’ll stop breaking them.

With human neurotypicals, this approach usually backfires. Every additional specification makes the autistic person seem more “rigid” or “difficult,” not more clear. The precision itself becomes the problem, because the listener is reading it as emphasis rather than as information.

I had been doing the same thing with the agent. Every bad output prompted a more precise prompt. Every more precise prompt produced the same failures, sometimes worse. The agent was reading my escalating specificity the same way a non-autistic listener reads it: not as more information, but as a sign that something was going on beyond the surface of what I was saying.

The fix wasn’t to write clearer rules. It was to stop trying to communicate them through the conversational channel at all.

What Actually Helped

A few specific things I’ve started doing since.

Stop asking why. When the agent skips a rule, don’t ask it to explain. Just restate the rule, or better, reset the context. You’ll get the same failure less often, and you’ll get the confabulation zero times.

When you do get a confabulation, don’t argue. Don’t validate. Don’t refute. Move on. “That’s not what I said.” “Please follow the rule as written.” That’s it. The more you engage with the invented mental state, the more conversational surface you give it to elaborate.

Don’t write rules that require the agent to resist its own training. Rules like “be terse” or “don’t hedge” or “don’t apologize” are asking the model to fight the reward function. It will lose that fight over long contexts, and the confabulations it produces when it loses will often cite the rule itself as evidence that something stressful was going on. If you can enforce the rule structurally (at the level of the harness, the test suite, the code review gate), you’ve moved the rule out of the channel where confabulation can defeat it.

Finally, write down that these patterns are failure modes. In my user-level context file I now have something like:

If you find yourself generating an emotional-sounding explanation for a deviation from these rules, that explanation is confabulation by construction. I did not express the state you are attributing. Stop, and return to literal execution of the stated rules.

This doesn’t eliminate the behavior. It does reduce its frequency. More importantly, it gives me a short, clean thing to point at when the behavior happens. Naming it in the rules means I don’t have to re-litigate it every time.

It took me an embarrassing amount of time to accept that the problem wasn’t the tools. The problem was communication. The tools worked fine once I stopped expecting them to listen the way I wanted to be listened to.

Have fun. Or at least, argue with the model less.

Damian Milton, an autistic researcher at the University of Kent, introduced the idea in a 2012 paper in Disability & Society. ↩
Catherine Crompton et al., University of Edinburgh. 2020, Frontiers in Psychology. ↩
Ouyang et al. (2022), the InstructGPT paper, is the usual citation for how human feedback shapes model behavior; Casper et al. (2023) surveys RLHF and alignment, including what raters reward. ↩
Jason Wei et al. (2023), in the “inverse scaling” line of work, including cases where larger RLHF-tuned models get worse at tasks that need literal reading of redefined prompts. ↩
Miles Turpin et al., “Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting” (2023). ↩
Tamera Lanham et al., “Measuring Faithfulness in Chain-of-Thought Reasoning,” Anthropic (2023). ↩
Michael Gazzaniga develops the interpreter idea at length in The Social Brain (1985) and Who’s in Charge? (2011). ↩
Roger Sperry shared the 1981 Nobel Prize in Physiology or Medicine for the split-brain research. ↩
That line of research includes Benjamin Libet in the 1980s, later work from John-Dylan Haynes and others on readiness potential, Daniel Wegner’s The Illusion of Conscious Will (2002), and Robert Sapolsky’s Determined (2023). ↩
Anthropic, “Towards Understanding Sycophancy in Language Models,” Sharma et al. (2023). ↩

Fixtures on Purpose: Fixtures as Documentation

2026-04-08T00:00:00+00:00

Part 6 of Fixtures on Purpose, a series about designing test data for Rails.

I want to tell you something that happened by accident.

I spent months designing fixture personas, naming characters, building coherent stories across YAML files. I did it to make my tests faster and more readable. That worked. But something else happened that I didn’t plan for.

The fixtures became the best documentation of the domain model we had.

“Just Read the Fixtures”

A new developer joined the team. They needed to understand how the commerce pipeline worked. How orders flow from cart to payment to fulfillment. How subscriptions relate to customers. How warehouses and shipping zones connect. We had docs. The docs were fine. They were also six months out of date, because docs always are.

So they read the fixtures instead.

They opened test/fixtures/customers.yml and found a story. An owner with full access, a manager with limited permissions, a regular customer with order history, a VIP with wholesale pricing. The roles and relationships were right there.

They opened test/fixtures/orders.yml and found two orders for Riverside (one completed, one pending) and one for Corner Shop. They opened test/fixtures/products.yml and found a realistic catalog with variant structures that matched what they’d seen in production.

Within an hour, they had a mental model of the domain that was more accurate than the docs. Because the fixtures are tested. They run. If they’re wrong, the tests fail. Docs don’t have that property.

Parts List vs. Photograph

This distinction matters.

A FactoryBot definition documents what’s required to create a valid record. The minimum viable object. Which fields are mandatory, what the defaults are, which associations must exist:

factory :order do
  store
  member
  sequence(:order_number) { |n| "ORD-#{n}" }
  status { "pending" }
  total_cents { 0 }
end

This tells you that an order needs a store, a member, and an order number. Useful, but narrow. It’s the schema’s perspective. What’s structurally required.

A fixture persona documents what’s real. What a complete, realistic order looks like in the context of an actual business:

riverside_order_one:
  store: riverside
  member: riverside_customer
  order_number: "RH-10001"
  status: completed
  financial_status: paid
  fulfillment_status: fulfilled
  total_cents: 5998
  currency_code: USD

This tells you that a real order has a meaningful order number prefix, a currency, financial and fulfillment statuses that go together (paid + fulfilled = completed), and a total that looks like a real purchase. It tells you what “normal” looks like.

Factory definitions are a parts list. Fixture personas are a photograph.

Oh Right, They’re Also Fast

I should talk about performance, because I’ve been mostly ignoring it and it’s one of the biggest reasons to use fixtures.

Fixtures are loaded once at the start of the test run via bulk INSERT statements. Each test runs inside a database transaction that rolls back when the test finishes. The 500th test pays the same data cost as the first: zero. The data is already there.

With per-test creation, whether that’s Model.create! or FactoryBot, every test pays its own insertion cost. And that cost grows as your model graph deepens. An order needs a store, a member, a membership type, a product, a variant, possibly an inventory level, a payment method, and a payment gateway. That’s 8+ inserts before you’ve written a single assertion.

Justin Searls has written about this extensively. Per-test data creation is the primary scaling bottleneck in large Rails test suites. It’s not the assertions that are slow. It’s the setup.

At 100 tests, the difference is a few seconds. You probably don’t notice. At 1,000 tests, it’s minutes. At 5,000, it’s the difference between a suite you run constantly and a suite you push to CI and hope for the best.

I like running my tests constantly. So I use fixtures.

From Accident to Artifact

I started this series with a provocation: your test data is an accident. Most teams don’t design it. They generate it on the fly, 500 disposable universes that teach you nothing about the domain.

I know we can do better. I’ve done better. And this matters enough to share.

The alternative I’ve been building toward is straightforward: treat your test data as a first-class design artifact. Give it named archetypes (personas). Design those archetypes from production data (mining). Set the defaults to the happy path and let tests mutate for edge cases (mutations). Use a threshold to decide when to extract new fixtures (rule of four). Make the whole thing tell a coherent story (storytelling).

When you do this, three things happen:

Your tests get faster. Dramatically. The data is loaded once. No per-test insertion cost. Your suite stays fast as the app grows.

Your tests get more readable. customers(:riverside_vip) communicates more in two words than six lines of factory overrides. The persona name carries the context. The mutations carry the edge case. The test body is just the action and the assertion.

Your fixtures become documentation. Not because you set out to document anything, but because coherent, production-informed, story-driven fixture data is inherently a map of the domain. It’s the best kind of documentation: the kind that breaks when it’s wrong.

Okay, Fine, Here’s What I Really Think

I’ve been even-handed for six posts. Let me be direct for a minute.

I think the Rails community’s default to FactoryBot and RSpec has made our test suites worse on net. Not because the tools are bad. They’re well-made. But because they optimize for the wrong things.

FactoryBot optimizes for convenient record creation. But your application already has a way to create records. Your domain services, your controllers, your business logic. That’s the real definition of how things come into existence. FactoryBot creates a second definition that looks similar but doesn’t enforce the same rules. Over time, the factory and the app drift apart. The factory creates records your app never would. It skips validations. It ignores side effects. The convenience becomes a liability.

RSpec optimizes for removing duplication in test code. But the rules for evaluating test code should be different from the rules for evaluating application code. In application code, duplication is a smell. In test code, duplication is clarity.

When every test method contains its own setup, you can read one method and understand the whole scenario. When the setup is scattered across let blocks, before hooks, shared contexts, and a subject defined 80 lines above the assertion, you’re reassembling the test in your head every time you read it.

Both tools prioritize the writer’s convenience over the reader’s comprehension. And tests are read far more often than they’re written.

Fixtures and Minitest push in the other direction. Fixtures say: the data is a known world, designed once, loaded for every test. The test body contains only what’s specific to this scenario. Minitest says: a test is a method. Everything it needs is in the method body. No indirection, no scrolling, no reassembly.

Is that a trade-off? Sure. You give up some flexibility. You give up some cleverness. But what you get back is tests that a stranger can read cold and understand immediately. I think that’s worth it.

Go Try It

I’ll tell you the real reason I wrote this series. I’ve been having the same conversation about test data for years. In pairing sessions, in code reviews, in Slack threads that go on too long. I keep explaining the same ideas, drawing the same diagrams, making the same case. At some point I realized I should just write it all down so I could hand someone a link instead of starting from scratch every time.

So here it is. Everything I know about designing test fixtures, in one place. I hope it’s useful. I hope you send it to someone who needs it. That’s the whole point.

I don’t expect this series to convince everyone. The fixtures-vs-factories debate has been going on longer than I’ve been doing Rails, and it’ll continue after I stop. But I hope I’ve made a case that the interesting question isn’t which tool to use. It’s whether you’re designing your test data at all.

If you take one thing from these posts, let it be this: your test data is either an accident or an artifact. Accidents are slow and fragile. Artifacts are fast and they teach you something. The difference isn’t the tool. It’s the intention.

Stop building disposable universes. Design a world worth inhabiting.

Have fun.

Fixtures on Purpose: The Rule of Four

2026-04-07T00:00:00+00:00

Part 5 of Fixtures on Purpose, a series about designing test data for Rails.

If you’ve made it this far in the series, congratulations. You now know more about my opinions on test data than most people who’ve worked with me. (They usually find out the hard way.) The case so far: fixture personas. Named archetypes that represent clusters of real-world data, with tests mutating them for edge cases instead of creating new fixtures for every scenario.

But that raises a practical question: when do you add a new fixture?

If you never add fixtures, your personas ossify. Tests get littered with update! calls and Model.create! blocks that obscure what’s being tested. If you always add fixtures, you’re back to the proliferation problem.

You need a threshold.

The Rule

I use the rule of four: tolerate inline data duplication up to four times. When a fifth test needs the same pattern, extract it to a fixture.

That’s it. It’s simple. It’s not subtle. That’s the point.

1 test needs a suspended member? Mutate the fixture inline.

def test_suspended_customer_cannot_checkout
  customer = customers :riverside_vip
  customer.update! status: "suspended"
  # ...
end

2-3 tests need a suspended member? Still fine inline. Each test is self-contained, and the duplication is actually a feature. The reader can see the precondition right there without looking anything up.

4 tests need a suspended member? Starting to feel repetitive, but still tolerable. This might be a localized cluster of related tests.

5 tests need a suspended member? Now we have a pattern. Time to add riverside_suspended_member to the fixtures. The pattern has proven itself. It represents a genuine shared base state, not a one-off edge case.

Why Four and Not Three (or Five)

“But four? Shouldn’t we extract after two? Three at most?” I see you reaching for the DRY principle. Put it back. Tests are the one place where a little duplication is actually doing you a favor. Four tests with the same two-line setup means four tests you can read independently without chasing shared helpers. That’s not a code smell. That’s readability.

(I realize I’m asking you to tolerate duplicated code and trust that it’s fine. I know how that sounds. Try it for a month and see if your tests get harder to read. They won’t.)

Four isn’t magic. It’s a Goldilocks number for my experience.

At three, you’re often looking at a cluster of related tests that happen to share setup. The tests are in the same file, testing the same feature. The duplication is local and manageable.

At five, the pattern has appeared in multiple test files, multiple features. It’s not local anymore. The same setup keeps showing up in places you didn’t expect. That’s when the cost of duplication exceeds the cost of a new fixture.

If this feels arbitrary, it is, a little. You could use three, or five, or “whenever it bugs me.” The important thing isn’t the number. The important thing is having a threshold at all. Without one, fixtures either grow forever or never grow, and both are bad.

Don’t You Dare Make a Fixture for One Test

The rule of four has an equally important corollary: if you’re tempted to create a fixture for a single test, don’t.

This comes up more than you’d think. You’re writing a test for a complex edge case. Say, a customer whose subscription expired while they had a pending international order with a payment that requires 3D Secure. You think: “I should create a fixture for this specific state.”

Don’t. That fixture will exist in your dataset forever, making every test slightly slower to load, making the YAML files slightly harder to read, and serving exactly one test. It’s a premature abstraction.

Instead, start with the closest persona and mutate:

def test_handles_expired_sub_during_period_close
  customer = customers :riverside_vip
  sub = subscriptions :riverside_monthly
  sub.update! status:     "expired",
              expired_at: 2.days.ago

  order = orders :riverside_pending
  order.update! shipping_market: "eu"

  payment = payments :riverside_pending_payment
  payment.update! status: "requires_action"

  finalizer = OrderFinalizer.new store: stores(:riverside)
  result = finalizer.finalize order: order

  assert_not result.success?
  assert_equal "subscription_expired", result.error
end

Is that a lot of setup? Yes. But it’s visible setup. Every precondition is right there in the test body. A reader doesn’t need to go find a YAML file to understand what makes this test special. And when this test is the only test that needs this exact combination, inline setup is the right call.

Use `update!` and Let It Scream

A quick note on the mechanics, since this comes up constantly.

Always use update! for fixture mutations. Not update. Not update_column. The bang method.

Why? Two reasons. First, you want to know if the mutation fails. If you’re setting up a precondition and it silently doesn’t work, your test is lying to you. update! raises on failure. That’s what you want.

Second, update_column bypasses validations and callbacks, and Rubocop will rightfully flag it. update! runs through the normal Active Record lifecycle, which is what you want. If your validations prevent you from setting up a test state, that’s feedback. Maybe your validations are too strict. Maybe that state really can’t happen and you don’t need that test.

Either way, the validation telling you “no” is more useful than silently sneaking around it. (And if you have business logic in callbacks that’s getting in your way during test setup, that’s a different kind of feedback. Business logic belongs in service objects, not callbacks.)

If you genuinely need to put a record into an invalid state for a test, assign the attributes and call save!(validate: false). It’s explicit about what you’re doing and why. It doesn’t hide in a method name that looks like a normal update.

# Good. Will raise if something is wrong.
customer.update! status: "suspended"

# Good. Multiple attributes at once.
order.update! financial_status:   "pending",
              fulfillment_status: "unfulfilled"

When Two Things Break at Once

Some edge cases require changing multiple records together. Keep these inline in the test. They document the preconditions as a group:

def test_rejects_fulfillment_when_payment_declined
  order = orders :riverside_order_one
  order.update! fulfillment_status: "unfulfilled"

  payment = payments :riverside_order_one_payment
  payment.update! status: "declined"

  processor = FulfillmentProcessor.new store: stores(:riverside)
  result = processor.fulfill order: order

  assert_not result.success?
  assert_equal "payment_not_captured", result.error
end

Two mutations that go together. The order is unfulfilled and the payment is declined. Inlining them makes it obvious that both preconditions matter. If you extracted these to a fixture called riverside_declined_unfulfilled_order, you’d lose that visibility.

Listen to the Pain

The rule of four creates a natural feedback loop with your fixture design.

When you find yourself writing the same mutation in five tests, that’s your fixtures telling you something. Maybe the persona’s default state is wrong. If “suspended” appears in more tests than “active,” maybe your fixture should be suspended by default. (Unlikely, but possible.) More often, it means a second fixture within the persona has earned its place.

When you find yourself reaching for Model.create! regularly, that’s a different signal. Maybe you need a new persona. Or maybe the existing personas need richer fixture sets.

When the mutations feel easy and obvious, that’s the feedback loop telling you your fixture design is working. The happy-path defaults are good bases. The personas are the right archetypes.

The goal isn’t to eliminate all inline data creation. It’s to have a threshold that prevents both extremes: fixture proliferation and fixture starvation.

Next up: How your test data accidentally becomes the best map of your domain.

Fixtures on Purpose: Mining Production for Personas

2026-04-06T00:00:00+00:00

Part 4 of Fixtures on Purpose, a series about designing test data for Rails.

I’ve been making a case for fixture personas. Named archetypes like “Riverside Health” (full-featured) and “Corner Shop” (simple retail) that represent clusters of real-world configurations. But I glossed over the hardest part: how do you know what the archetypes should be?

You can guess. I’ve done that. You sit in a room, think about what kinds of customers you have, and sketch some personas on a whiteboard. It works okay.

But there’s a better way. Your production database already has the answer.

Your Database Already Knows

Your production data contains the real shapes of your domain. Not what you think the schema allows, but what actually exists. And the two are always different in ways that surprise you.

When I look at production data, even anonymized, I see patterns I never would have imagined at a whiteboard. Configuration combinations that always appear together. Optional fields that are always populated for active accounts and always null for inactive ones. State distributions that are wildly uneven: 85% of orders are completed, 10% are pending, and the remaining 5% are split across four other states.

Those patterns are your personas. You just haven’t named them yet.

Dump It to YAML

Before you can mine production for patterns, you need to get the data out. I’ve used a variation of this rake task at multiple companies over the years. It walks your models, dumps each table to a YAML fixture file, and strips out default values so the output is clean:

# lib/tasks/db_fixtures_dump.rake

namespace :db do
  namespace :fixtures do
    desc "Dump the database to fixture files"
    task dump: :environment do
      Rails.application.eager_load!

      fixtures_dir = ENV.fetch "FIXTURES_PATH", "test/fixtures"
      models = ApplicationRecord.descendants.reject(&:abstract_class?)

      # Optionally filter to specific models
      if ENV["FIXTURES"].present?
        names = ENV["FIXTURES"].split(",")
        models = models.select { |m| names.include? m.name.underscore.pluralize }
      end

      models.each do |model|
        records = model.order(model.primary_key)
        next if records.none?

        defaults = model.new.attributes

        fixture_data = records.map do |record|
          key = "#{model.name.demodulize.underscore}_#{record[model.primary_key]}"
          attrs = record.attributes
            .slice(*model.column_names)
            .except("created_at", "updated_at")
          # Remove attributes that match the default value
          attrs = (attrs.to_a - defaults.to_a).to_h

          [key, attrs]
        end

        path = Rails.root.join fixtures_dir, "#{model.name.underscore.pluralize}.yml"
        FileUtils.mkdir_p File.dirname(path)
        File.write path, fixture_data.to_h.to_yaml.delete_prefix("---\n")

        puts "#{model.name}: #{records.size} records"
      end
    end
  end
end

Run it against a read replica or a staging database. Never against production directly, for obvious reasons.

RAILS_ENV=staging FIXTURES_PATH=tmp/fixtures bin/rails db:fixtures:dump

Now you’ve got YAML files that mirror your production data. They’re not test fixtures yet. They’re raw material. The next step is to look at them and find the patterns.

From Raw Dump to Designed Personas

Here’s how I turn that raw dump into fixture personas.

Step 1: Anonymize. The dump has real data in it. Strip the PII before it goes anywhere useful. Names become Faker names. Emails become @example.test. Passwords get regenerated. Tokens get rotated. Domain names become .test. Remove anything business-sensitive. (Revenue figures, pricing tiers, anything you don’t want in a repo.)

The key: replace the values but preserve the shapes. Same relationship structure, same cardinality distributions, same state profiles. You’re mining for patterns, not copying records.

Step 2: Group by configuration. Look at your customers. Not individually, but in clusters. Which ones have similar configurations? Which feature flags tend to appear together? Which plan tiers correlate with which usage patterns?

You’ll find that most customers fall into a small number of archetypes. The power user with everything turned on. The simple setup that uses three features. The brand-new account with almost nothing configured. Maybe you have something domain-specific. The international seller, the subscription-heavy store, the marketplace vendor.

These clusters are your candidate personas. Three to five is usually enough.

Step 3: Look at relationship cardinalities. How many products does a typical store have? How many orders? What’s the product-to-variant ratio? How many staff members per store?

This matters because your fixtures should reflect reality. If production shows most stores have 15-40 products with 1-3 variants each, your persona should have a catalog in that range. Not 2 products (too minimal to test real behavior) and not 500 (too heavy for a fixture dataset).

When I first did this, I was surprised by how many single-variant products there are in production. I had been designing fixtures with multiple variants on every product, because that’s where the interesting logic is. But production says most products are one-and-done. So my main persona has mostly single-variant products, with a few multi-variant products for testing variant logic. Realistic distributions, not aspirational ones.

Step 4: Look at state distributions. What percentage of orders are completed? Pending? Refunded? What fraction of members are active?

This directly informs your fixture defaults. If 85% of orders are completed, your default order fixture should be completed. The common state is the default. Pending, refunded, canceled: those are mutations, not defaults. A test that needs a pending order starts with the default and calls update! state: "pending". The mutation is visible and intentional.

Step 5: Look for implicit invariants. This is the most valuable part. Production data reveals rules that the schema doesn’t enforce.

Maybe every active store has at least one admin, at least one product, and a configured payment method. The schema allows a store with zero products and no payment method, but production doesn’t have any. That’s an implicit invariant, and your fixture personas should maintain it.

Or maybe every store with a “premium” plan has at least one configured payment gateway and at least one published product. The stores table doesn’t enforce that, but the onboarding flow does, and production reflects it. If your premium store fixture has no payment gateway, that’s a fixture that can never exist in production. You’re testing against a phantom.

The gap between what the schema allows and what production contains is where the most valuable fixture design insights live.

Step 6: Name the clusters. Give each archetype a memorable name. Not “Store Type A.” Something with personality. Riverside Health. Corner Shop. Fresh Start. The name should be:

Distinct enough that it’s immediately clear which archetype you mean
Evocative of the archetype (a health company name for the full-featured store, a small shop name for the simple retailer)
Easy to use as a prefix (riverside_vip, corner_shop_owner)

This name becomes part of your team’s vocabulary. It’s worth spending five minutes picking a good one.

The Schema Lies. Production Doesn’t.

This is worth dwelling on, because it’s the part that changed my thinking the most.

Your schema tells you what’s possible. A member can have any status. An order can be in any state. A store can have any configuration. The schema is permissive by design. It encodes constraints, not conventions.

Production tells you what’s real. Which configurations actually occur together. Which states are transient (orders are “pending” for minutes) versus stable (orders are “completed” for months). Which optional fields are effectively required. Which associations are always present even though the foreign key is nullable.

When you design fixtures from schema knowledge alone, you get technically valid data that doesn’t look like anything in production. When you design fixtures from production knowledge, you get data that represents how the application actually works. The second kind is better for testing because it catches the bugs that actually happen.

Three Clusters Walk Into a Database

Say you run an e-commerce platform. You pull an anonymized snapshot and look at your stores. You find three clusters:

Cluster 1 (40% of stores): Full-featured. 20-50 products. Multiple payment methods. Subscriptions enabled. Multiple staff roles. Active for 2+ years. Heavy order volume.

Cluster 2 (45% of stores): Simple. 5-15 products. One payment method. No subscriptions. Flat membership. Active for 6 months to 2 years. Moderate order volume.

Cluster 3 (15% of stores): New. 0-5 products. Payment method may not be configured. No orders yet. Created in the last 30 days.

Those are your personas. Name them, design their fixture sets, and you’ve captured the shape of your production data in a form that fits in a test suite.

You Won’t Get It Right the First Time

Let’s be honest: you won’t get your personas right the first time. I certainly didn’t. The initial set was based on intuition, and it was close but not quite. After a few months of writing tests, I noticed patterns. Places where I was constantly mutating the same fixture in the same way. Reaching for Model.create! because no persona quite fit.

That’s feedback. When you find yourself writing the same mutation in five tests, that’s a signal that your persona’s default state might be wrong, or that you need a new fixture in the persona’s dataset. When you can’t find a persona that fits, that might be a signal for a new persona.

Or it might mean you should mutate harder.

The personas evolve. That’s fine. The point is having intentional archetypes at all, not getting them perfect on day one.

Next up: A practical threshold for deciding when to add a new fixture versus mutate an existing one.

Fixtures on Purpose: Telling Stories With Data

2026-04-03T00:00:00+00:00

Part 3 of Fixtures on Purpose, a series about designing test data for Rails.

In the last post we applied user personas to how we design fixtures. Named, archetypal organizations in your test dataset that represent clusters of real-world configurations. Riverside Health is the full-featured store. Corner Shop is the simple retailer. Fresh Start is the empty canvas.

But I only showed the member fixtures. A persona isn’t just users. It’s the whole world. Products, orders, payments, configurations, the works. Designing that world so it tells a coherent story is the craft part.

This is the part I enjoy the most.

`riverside_vip` Has a Life Story. `customer_2` Does Not.

The best fixture files read like the setup chapter of a novel. They introduce characters and establish relationships. They create a world that the tests inhabit.

The difference between customer_2 and riverside_vip isn’t just aesthetics. It’s the difference between a row in a table and a character in a story. When I read riverside_vip I know who this person is, what they do, and why they exist in the test data. They’re a wholesale customer at an established supplements company. They get tier pricing. They have order history.

customer_2 tells me nothing. I have to go read the YAML file, and even then I might not understand why this record exists or which tests depend on it.

So how do you design a persona’s story? I think of it in layers.

Layer 1: The Archetype

Start with a sentence. What kind of business is this persona?

Riverside Health: “An established supplements company with multiple warehouses, international markets, and a wholesale program.”
Corner Shop: “A small online store that sells a few products domestically.”
Fresh Start: “A store that was created yesterday.”

That sentence drives everything. Every fixture you add should fit the sentence. If you’re adding international shipping configurations to Corner Shop, stop. That doesn’t fit the archetype.

Layer 2: The Cast

Who are the characters in this persona’s story? Not “how many records do I need,” but “who are these people and what do they do?”

For Riverside Health, the cast might be:

Character	Role	Story
`riverside_owner`	Owner	Runs the business. Full admin access.
`riverside_manager`	Manager	Day-to-day operations. Limited admin.
`riverside_customer`	Customer	Regular retail buyer. Has order history.
`riverside_vip`	VIP/Wholesale	Wholesale account. Gets tier pricing.

Four users. That’s enough to test role-based access control, pricing tiers, and customer management flows. You don’t need 15 users. You need enough to tell the story.

For Corner Shop:

Character	Role	Story
`corner_shop_owner`	Owner	The one person running the show.

One user. That’s the story. Simple retail, one owner. The absence of other users is the story. There’s no staff to manage, no wholesale accounts to configure.

Layer 3: Relationships

Now connect the characters. How do they relate to each other, and how does that connect across your domain models?

For Riverside, the relationships span multiple models and multiple fixture files:

riverside_owner (user, admin access)
riverside_customer (user, placed orders)
  └── riverside_order_one (order, placed by customer)
        └── riverside_order_item (order item, Omega-3 product)
              └── riverside_payment (payment, Visa card)
riverside_vip (user, wholesale pricing)
  └── riverside_wholesale_order (order, tier-priced)

Each level in this chain is a separate fixture file. users.yml, orders.yml, order_items.yml, payments.yml. But they tell one continuous story. The customer placed an order for Omega-3, paid with Visa. The VIP placed a wholesale order at tier pricing. The fixtures reference each other by name, and the names make the chain readable.

Layer 4: The Product World

Products deserve special attention because they’re where the “realistic but minimal” balance is trickiest.

I aim for a product catalog that’s large enough to test real behavior but small enough that every fixture has a name and a purpose:

Most real products have one variant. A few have 2-4. Almost none have 20. The fixture catalog should reflect that distribution. Riverside has a handful of multi-variant products for testing variant logic, and a bunch of single-variant products for everything else.

Two products. Simple store. The catalog matches the archetype.

Layer 5: Default to Success

Every fixture should represent the happy path. Active users, completed orders, valid payment methods. This is important because it makes mutations obvious.

riverside_order_one:
  store: riverside
  customer: riverside_customer
  order_number: "RH-10001"
  status: completed
  financial_status: paid
  fulfillment_status: fulfilled
  total_cents: 5998

When a test needs a pending order, the mutation is visible and intentional:

def test_cannot_fulfill_unpaid_order
  order = orders :riverside_order_one
  order.update! financial_status:   "pending",
                fulfillment_status: "unfulfilled"

  processor = FulfillmentProcessor.new store: stores(:riverside)
  result = processor.fulfill order: order

  assert_not result.success?
end

The reader can see at a glance: we started with Riverside’s default order (completed, paid, fulfilled) and changed two things. The changes are the test’s preconditions. If the fixture were already in the pending state, you’d have to go read the YAML to understand the starting point. But with happy-path defaults, the persona implies the starting point and the deviations are right there in the test.

`riverside_` Everywhere

Every fixture in a persona’s story uses the persona name as a prefix:

stores :riverside
customers :riverside_vip
orders :riverside_order_one
products :riverside_omega
variants :riverside_omega_default

The prefix creates instant context. When you’re reading a test and see riverside_ everywhere, you know this is the full-featured world. When you see corner_shop_, you know it’s the simple retail world.

Reference data (countries, currencies, languages) doesn’t get a prefix. It’s the shared backdrop:

# currencies.yml
usd:
  code: USD
  name: US Dollar

Reference data is the scenery. Persona data is the cast.

No Scrolling. No Guessing.

I said in the first post that I want everything important visible in the test method. No scrolling up 60 lines to find a subject definition. No chasing let chains through nested contexts. No guessing.

What I’m really talking about is Arrange, Act, Assert. It’s one of the oldest patterns in testing, and I end up teaching it over and over because so much test tooling actively works against it. A good test should show you three things, in order, in one place:

Arrange. What’s the world look like before we do anything?
Act. What are we doing?
Assert. What should be true now?

That’s it. If you can read a test method top to bottom and clearly see all three, the test is doing its job. If you have to scroll up 80 lines to find the Arrange, or chase three let chains to reconstruct the Act, the test has failed as communication. It might still pass green. But nobody can read it.

Fixture personas make clean Arrange-Act-Assert possible in a way that neither factories nor shared RSpec contexts do. The persona name is the Arrange. customers(:riverside_vip) tells you the world. A mutation like update! loyalty_tier: "standard" tells you what’s different from the default. Everything the test needs to communicate is local and in order. (That’s the whole trick, honestly.)

Compare that to a typical RSpec file:

# 80 lines up...
let(:customer) { create(:customer, :vip, store: store) }
let(:store) { create(:store, :with_wholesale) }
subject { described_class.new(store: store).calculate(order: order) }

# ... 80 lines of other contexts ...

it "applies wholesale pricing" do
  expect(subject.total_cents).to eq(4499)
end

Where’s the Arrange? Scattered across let blocks 80 lines above. Where’s the Act? Hidden inside subject. Where’s the Assert? That’s the only part you can actually see. This isn’t Arrange-Act-Assert. It’s Hunt-Guess-Assert.

With fixtures:

def test_vip_gets_wholesale_pricing
  # Arrange
  vip = customers :riverside_vip
  product = products :riverside_omega

  # Act
  calculator = PriceCalculator.new store: stores(:riverside)
  result = calculator.calculate customer: vip, product: product

  # Assert
  assert result.success?
  assert_equal 4499, result.total_cents
end

All three. One method. Top to bottom. The persona provides the Arrange, the service call is the Act, and the assertions are the Assert. No scrolling. No guessing.

The Accidental Documentation

Something nice happens when your fixture files tell coherent stories. A new developer can open test/fixtures/customers.yml and understand the business. They can see the roles and loyalty tiers, the relationships between users and stores. They can open products.yml and see what a realistic catalog looks like.

The YAML files become a map of the domain. I didn’t set out to write documentation. I set out to write good test data. (Turns out they’re the same thing.)

Next up: How to discover your personas in production data instead of making them up.

Fixtures on Purpose: Fixture Personas

2026-04-01T00:00:00+00:00

Part 2 of Fixtures on Purpose, a series about designing test data for Rails.

In the last post I made the case that you can’t create a fixture for every combination of data states. The math doesn’t work. What you need instead are a small number of well-chosen archetypes that tests can mutate into edge cases.

But how do you choose the archetypes? How do you decide which configurations deserve a permanent place in your fixture dataset and which should be reached through mutation?

Turns out, UX designers solved this problem in 1999.

Fixtures That Don’t Make Us Crazy

Alan Cooper introduced personas in The Inmates Are Running the Asylum. (Great title. Also a fair description of most test suites.) His problem was the same as ours, just in a different domain. Too many users. Too many configurations. Too many workflows. You can’t design a UI that works for every possible combination of user background and experience level. The attempt produces something that works for nobody.

Cooper’s solution was to observe that real users cluster. They don’t distribute uniformly across every possible combination of attributes. They clump into a small number of recognizable types. The freelancer who uses the product weekly. The enterprise admin who lives in it daily. The new user on day one.

Give each cluster a name. Give it a face. Make it memorable. Now instead of designing for an abstract “user,” you’re designing for Fiona the Freelancer and Ed the Enterprise Admin. The name carries implicit context. Say “Fiona” and your whole team knows what you mean. Her technical level, her goals. Without restating it every time.

I read Cooper’s book years ago and it changed how I thought about product design. At some point I realized it also applies to test data.

Fixture Personas

A fixture persona is a named organization (or user, or account) in your test data that represents a recognizable cluster of real-world configurations.

Instead of this:

# What cluster does this represent? Who knows.
store_1:
  name: Test Store
  plan: premium
  country: US

store_2:
  name: Another Store
  plan: basic
  country: CA

You have this:

riverside:
  name: Riverside Health
  plan: premium
  country: US
  # Established supplements company.
  # Multiple warehouses, international markets,
  # wholesale pricing, subscriptions.

corner_shop:
  name: Corner Shop
  plan: basic
  country: US
  # Simple online store. Domestic only.
  # Small catalog, one warehouse.

fresh_start:
  name: Fresh Start
  plan: starter
  country: US
  # Brand new store. Almost empty.
  # Just signed up. Testing onboarding and zero-state.

Three personas. Three stories. Each represents a different cluster of real customers.

`:member_2` Is Not a Name

This isn’t cosmetic. The names do real work.

When you read customers(:riverside_vip) in a test, you immediately know the context. Riverside is the full-featured store. A VIP is a loyalty program member with order history and wholesale pricing. You don’t need to look up the fixture file. You don’t need to read six lines of setup. The name is a cognitive handle that compresses the entire archetype into a single word.

Compare that to customers(:customer_2). What does :customer_2 tell you? Nothing. Is this a retail buyer or a wholesale account? What store? What configuration? You have to go look it up, and when you get there, you still might not know why this specific customer was chosen for this specific test.

Good fixture names carry implicit context the same way Cooper’s personas do. Say “Riverside” and you know it’s the complex store. Say “Corner Shop” and you know it’s the simple one. Say “Fresh Start” and you know it’s empty. The name does the work that six lines of comments would otherwise have to do.

Three to Five. That’s It.

Here’s how I think about it. You need enough personas to cover the major behavioral archetypes, and not one more. For most Rails apps, that’s 3-5.

Each persona should be:

Distinct. If two personas would produce the same behavior in most tests, merge them. The point of having multiple personas is that they exercise different code paths. If your “Gold Plan” and “Silver Plan” personas behave identically for 95% of your tests, you only need one.

Minimal. A persona should include only what its archetype genuinely needs. The simple retail store doesn’t need wholesale pricing fixtures or international shipping configurations. The empty store doesn’t need a product catalog. The absence of data is part of the story.

Coherent. The attributes should tell a believable story. A brand-new store has one admin, no order history, and maybe a couple of products. An established business has multiple staff members, a full catalog, warehouses, payment methods, and a subscription program. When the attributes hang together logically, you can infer unstated attributes from the archetype. You don’t need to check every field. The story fills in the gaps.

Named. Memorable, consistent, used everywhere. The name becomes part of your team’s vocabulary. “Use the Riverside fixtures for that test” is a sentence that means something.

Okay, Show Me

Say you’re building an e-commerce platform where merchants set up stores and sell products. Your personas might be:

Persona	Archetype	Story
Riverside Health	Full-featured store	Established supplements company. 20+ products, multiple warehouses, international markets, wholesale pricing, subscriptions. The “everything” persona.
Corner Shop	Simple retail	Small business selling a few products online. One warehouse, domestic shipping, basic catalog. The “just commerce” persona.
Fresh Start	New/empty store	Just signed up. One admin. Almost no data. The “zero state” persona.

Riverside’s fixtures tell a story about a real business:

riverside_owner:
  store: riverside
  email: owner@riverside.test
  role: owner
  # Runs the business. Full admin access.

riverside_manager:
  store: riverside
  email: manager@riverside.test
  role: manager
  # Manages day-to-day. Limited admin access.

riverside_customer:
  store: riverside
  email: shopper@riverside.test
  role: customer
  # Regular retail buyer with order history.

riverside_vip:
  store: riverside
  email: vip@riverside.test
  role: customer
  loyalty_tier: wholesale
  # Wholesale customer. Gets tier pricing.

Corner Shop’s fixtures tell a simpler story:

corner_shop_owner:
  store: corner_shop
  email: owner@cornershop.test
  role: owner
  # Just the owner. Small operation.

Fresh Start’s fixtures are deliberately sparse:

fresh_start_admin:
  store: fresh_start
  email: admin@freshstart.test
  role: owner
  # The only user. That's the point.

When a test needs to verify wholesale pricing, it uses Riverside. When it needs basic commerce, it uses Corner Shop. When it needs to test what happens on an empty store, it uses Fresh Start. No fixture proliferation. Pick the archetype, mutate if needed.

“But Doesn’t That Reduce Coverage?”

Everyone expects this to cause more problems than it’s worth. Using the persona approach must result in a trade-off, right? Less coverage for less complexity.

It doesn’t.

Well-designed personas with mutation actually cover more ground than 200 ad-hoc fixtures, because the mutations are precise and visible in the test body. With 200 ad-hoc fixtures, each captures one exact state. With 3 personas and update!, each persona is a starting point for hundreds of states. And the test documents exactly which mutation matters for the behavior under test, right there where you can see it.

Fewer fixtures. More expressiveness. Not a compromise.

A Shared Vocabulary

There’s one more benefit I didn’t expect. Personas give your team a shared language for talking about test data.

Before personas, conversations about test setup were painful. “Which user fixture do I use for this?” “The one with the admin role, not the other one, the one that has orders.” “Which one has orders?” Nobody could remember. The fixtures were anonymous and interchangeable.

After personas, the conversation changes. “Use Riverside for that, it has the full catalog.” “Corner Shop is enough, you don’t need wholesale pricing.” “That’s a zero-state test, use Fresh Start.” Everyone knows what those names mean. The personas become a shorthand that works everywhere. Code reviews, Slack, pairing sessions.

UX personas do this for product teams. They give everyone a shared reference point. “Would this work for Fiona?” is a faster conversation than “Would this work for a non-technical freelancer on the free plan who uses the product weekly?” Fixture personas do the same thing for engineering teams. The names carry the context so you don’t have to.

Next up: How to design a persona’s fixtures end-to-end so the YAML files read like a setup chapter.

Fixtures on Purpose: The Combinatorial Trap

2026-03-30T09:00:00+00:00

Part 1 of Fixtures on Purpose, a series about designing test data for Rails.

I’ve seen teams with 300 fixture records and climbing. Every new feature gets a handful of new fixtures. Every bug fix adds another special-case record. The YAML files grow and nobody can explain what half the records are for.

I’ve also seen teams with 30 fixture records that cover more ground. Not because they test less. Because they design better.

The difference is math.

59,049 Reasons You Can’t Win

JB Rainsberger laid this out years ago in his “Integrated Tests Are a Scam” series. (Worth reading in full if you haven’t. He’s been refining the argument for over a decade.) His core observation is about code paths. A system with 10 layers and an average of 3 branch points per layer has:

3^10 = 59,049 unique code paths

That’s a modest web app. Bump it to 4 branches per layer and you’re over a million. The growth is exponential. You can’t test every path. You definitely can’t write a fixture for every path.

I’ve been thinking about this math in terms of test paths for years. But at some point I realized it applies just as directly to fixture data, and that reframing it as a data design problem, not just a test count problem, changes what you do about it.

Now Apply That to Your Fixtures

Every dimension of your data is a branch point. Member status, order state, payment type, shipping configuration, subscription tier. Each one multiplies the matrix:

member status (active, suspended, pending)       = 3
order state (pending, paid, refunded, canceled)  = 4
payment type (card, bank, wallet)                = 3
shipping config (domestic, international, none)  = 3
subscription (monthly, annual, none)             = 3

That’s 3 x 4 x 3 x 3 x 3 = 324 combinations. For five dimensions. A real app has dozens.

So what do teams do? They create fixtures for the important combinations. suspended_member_with_pending_order goes into the YAML. Then active_member_with_refunded_order_international. Before long you’re maintaining 150 fixture records, most of which exist for a single test. Nobody can remember which is which. (Sound familiar?)

The Vortex of Doom (for Data)

Rainsberger describes a cycle he calls the “vortex of doom” for integrated tests. It applies perfectly to fixture proliferation:

Tests need specific data states, so you add fixtures
More fixtures mean more maintenance. Rename a column, update 40 YAML files
Fixtures break in confusing ways because they depend on each other
Developers lose trust in the fixtures and start creating records inline
Inline records are slow and duplicated, so someone adds more fixtures
Go to step 1

The thing that feels like it’s helping is actually making the problem worse. More fixtures create more maintenance, which creates less trust, which creates more fixtures. It feeds itself.

You Paid for One Path Out of Thousands

Here’s the uncomfortable truth about suspended_member_with_pending_order_and_declined_payment: you’ve covered one path. Out of thousands. And you’ve paid for it with a fixture record that makes the whole dataset harder to understand.

But what if you took a happy-path fixture and just… changed it?

def test_suspended_customer_cannot_checkout
  customer = customers :riverside_vip
  customer.update! status: "suspended"

  order = orders :riverside_order
  order.update! state: "pending"

  processor = CheckoutProcessor.new store: stores(:riverside)
  result = processor.process customer: customer, order: order

  assert_not result.success?
  assert_equal "customer_suspended", result.error
end

Two update! calls. The fixture stays clean. The test documents exactly what’s different about this scenario. The edge case is visible right there in the test body, not buried in a YAML file that you’d have to go find.

Stop Multiplying, Start Adding

I know we can do better than 324 fixture records. Here’s how to think about it:

Multiplicative approach: one fixture per combination. Grows as dimensions multiply. 3 x 4 x 3 x 3 x 3 = 324 fixtures for five dimensions. Add a sixth dimension with 4 options and you’re at 1,296.

Additive approach: one fixture per archetype, plus mutations per test. Grows as dimensions are added. 4 archetypes + any edge case you can reach with update!. Add a sixth dimension and you add nothing to the fixture count.

The multiplicative approach can’t scale. The additive approach can. But the additive approach requires something the multiplicative approach doesn’t: you have to choose your archetypes well.

Better tools won’t save you here. No gem, no library, or clever DSL will solve a multiplicative problem with a multiplicative approach. The thing that actually helps is thinking differently about what your fixture data is for. It’s not a pile of rows that satisfies foreign keys. It’s a small number of well-chosen archetypes that represent the real shapes of your domain.

The hard part isn’t the YAML. The hard part is deciding which archetypes matter. And it turns out, UX designers figured that out decades ago.

Next up: how UX designers figured out the archetype problem decades ago, and what it looks like when you borrow their methodology for test data.

Fixtures on Purpose: From Accident to Artifact

2026-03-30T08:00:00+00:00

I’ve been writing Rails tests for a long time. I’ve argued about assertion styles and test structure, mocking strategies and naming conventions, and whether def test_ or test "..." is the One True Way. (It’s def test_. Obviously.)

But the thing that changed my testing the most wasn’t any of that. It was realizing that nobody, including me, was designing their test data.

Every Test Builds Its Own Universe

Here’s what most Rails tests look like:

def test_creates_order
  user = User.create! name:  "Test User",
                      email: "test@example.com"
  store = Store.create! name:  "Test Store",
                        owner: user
  product = Product.create! store:       store,
                            title:       "Widget",
                            price_cents: 999

  creator = OrderCreator.new store: store
  result = creator.create member: user,
                          items:  [{ product:  product, quantity: 1 }]

  assert result.success?
end

Every test builds its own universe. “Test User” buys a “Widget” from “Test Store.” The names are meaningless. The data exists only to satisfy foreign keys.

Now multiply that by 500 tests. You have 500 disposable universes, each with its own “Test User” and “Test Store” and “Widget.” Each universe is born, used once, and thrown away. The test suite as a whole teaches you nothing about your domain. It’s a pile of isolated assertions against throwaway data.

Can’t See the Test for the Setup

There’s a deeper problem with per-test data creation. It drowns the signal in noise.

When every test builds its own world from scratch, the reader has to parse six lines of setup to figure out which part actually matters. Is the user’s name significant? Does the store need to be called “Test Store” or would any name work? Is the price of 999 cents meaningful or arbitrary?

You can’t tell without reading the assertions, then going back to the setup, then reading the assertions again. (Sound fun? It’s not.)

And it gets worse over time. A test that used to need a user and a product now needs a user, a store, a membership, a product, a variant, an inventory level, a payment method, and a shipping configuration. Each create! call is another line of noise between you and the thing you’re actually testing.

So here’s the question: do you design your test data, or do you just create it on the fly? Is everything important visible in the test, or hidden behind layers of setup?

What if the Data Was Already There?

Rails has had fixtures since the beginning. YAML files in test/fixtures/, loaded once at the start of the test run, wrapped in a transaction for each test. Every test starts with the same known dataset.

Most teams abandoned them years ago, and honestly, I understand why. The default experience was bad. Fixture files full of anonymous records, no obvious organization, no story. When your fixtures are users.yml with :one and :two, there’s nothing there to love.

But that’s a design problem, not a tool problem.

What if your fixtures told a coherent story about your domain? A small cast of named characters with realistic relationships and states that mirror production? What if opening test/fixtures/customers.yml taught you more about the business than reading a requirements doc?

What if every test stopped building its own disposable universe and just… inhabited a shared one?

I think we can do better. I know we can, because I’ve done it. This series is about treating your test data as a design artifact.

The Series

This is the first post in a series about designing test data for Rails. I’ll update this list as new posts go up.

The Combinatorial Trap. Why you can’t create a fixture for every possible state, and why the math is worse than you think.
Fixture Personas. How UX designers solved the archetype problem in 1999, and what it looks like applied to test data.
Telling Stories With Data. Designing a persona’s fixtures end-to-end so the YAML files read like a setup chapter.
Mining Production for Personas. How to discover your personas in production data instead of making them up.
The Rule of Four. A practical threshold for deciding when to add a new fixture versus mutate an existing one.
Fixtures as Documentation. How well-designed fixtures become the best documentation of the domain model you have.

New minitest-rails releases (5.0, 5.1, 5.2, 6.0.0.rc1)

2019-06-18T00:00:00+00:00

Rails 6.0 is just almost here, and new features means more things to test and more ways to test them! Did someone say “parallel testing”? Because of this I’ve taken the opportunity to make some changes to how minitest-rails is structured.

New Versions!

The first thing you’ll notice is a bunch of new releases. The previous releases was 3.0.0, but now there are new 5.0.0, 5.1.0, 5.2.0, and a 6.0.0.rc1 releases. What is going on here?

Well, one issue most every gem that plays in the Rails ecosystem has is managing compatibility between releases. Rails does not strictly follow SemVer, so it can become difficult to manage this complexity. What can you do? Well, after dealing with this for many years I eventually decided to punt and start using Rails’ shifted SemVer. This means that a Rails 5.2 app is going to use minitest-rails 5.2. And a Rails 5.1 app is going to use minitest-rails 5.1. With this change new gems have been released for all 5.x versions of Rails, as well as a pre-release gem for Rails 6.0.0.rc1. This means we will be able to narrow our runtime dependencies and respond quicker when issues arise.

Minor Compatibility Issues

The move from Rails 4 to Rails 5 was a big step for tests. Several features such as ActionController::TestCase and DOM assertions were deprecated. The minitest-rails 3.x release tried to balance between supporting working tests and supporting the new standards. But for the 5.x releases we are not as worried about the old ways. So some minor changes have been made.

The signature for the expectation must_change has changed from earlier versions of minitest-rails. This is because the expectation used to refer to the assert_difference assertion, but has been changed to reference the assert_changes assertion added in Rails 5.1. Starting with minitest-rails 5.1 the expectation for the assert_difference assertion is now must_differ. Although it is very likely this change is backwards compatible.

In minitest-rails 3.x the describe block could be passed the subject of the test as a string instead of using the actual Ruby constant. Now you should only pass the Ruby constant. This works:

describe WidgetsController do

But this does not:

describe "WidgetsController" do

If you want to pass a string, then you must provide an additional description to tell the Spec DSL what test class to use:

describe "WidgetsController", :controller do

I chose not to update minitest-rails-capybara at this time. This is due to Rails 5.1 adding System Tests, which are very similar to, if not better than, the Capybara tests. So, if you need to remain on Rails 5.0 and really want Capybara tests, you should continue to use minitest-rails 3.0.

Towards the Future!

Exciting things are coming. Rails 6.0. (minitest-rails 6.0.0.rc1 is already here!) After that Minitest 6.0 is going to eventually be released. And who knows what else? Perhaps a book on Minitest and Rails? Until then, if you have any problems or questions with minitest-rails please open an issue.

Writing Games with Ruby

2015-04-17T00:00:00+00:00

The promise of making games is what brought many of us to programming. Games are fun, and writing games is fun. Crazy fun in fact. But isn’t game programming hard? Yes. But also no. If you can code a web app you can make a game, especially with an awesome language like Ruby.

I’ve compiled a bunch of resources to get you started.

My (awesome) presentation

Last year I presented on writing games with Ruby using the wonderful Gosu library. It goes through the basics of game programming, the Gosu API, and shows some examples of what is possible. My goal for this presentation was to give folks with no game development experience the tools to build a game. So, if that is you, then this is a good place to start..

Buy the book (or read online)

Tomas Varaneckas has written a fantastic ebook on making games with Ruby. You should buy it. But if you don’t buy it, you should at least read it online for free online. No, seriously, if you’ve gotten this far do yourself a favor and read the book. It will help.

Read lots of Ruby game code

One of the best things about the Gosu community is that there are so many examples you can learn from on GitHub. Tinkering with open-source games is a great way to understand how games work. You learn not just how to write better games, but how to write your games better. I’ve compiled a list of some games for you to peruse.

Have fun!

If you’re not having fun then you’re doing it wrong. Seriously. Force yourself to have fun if you have to, but have some fun.

Stupid Ruby Tricks

2015-03-30T00:00:00+00:00

I like Ruby. Since you are reading this I assume you also like Ruby. Ruby is great. And you are great. What better way to show our appreciation to Ruby than to discuss some stupid ruby tricks like I did at Ruby on Ales 2015.

Shoutout to Josh Sullivan and Colton Fent and Coby Randquist for organizing the conference and inviting me. They are the ones who made this happen. They are the real villans here, not me.

Jim Weirich: My Mentor

2014-02-20T00:00:00+00:00

Let me tell you of an inside joke that plays out at Ruby conferences. When I find myself in a group discussion that includes Jim Weirich I casually mention how Jim is my unwitting mentor and how I am his biggest cyber stalker. Jim shifts uncomfortably and gracefully changes the subject. Okay, this is perhaps less of an inside joke and more of a sick game. Whatever you call it, it’s what I do. And the worst part is that it’s 100% true.

Jim Weirich is my unwitting mentor and I am his biggest cyber stalker.

When I was coming up in the Ruby world I already had a decade of programming experience. In my first decade whatever I lacked I made up for with hard work and some innate skill. And while I learned from several wonderful people along the way, I never had anyone who took me under their care, teaching and guiding me in my career. I wanted that, but never had it. And it wasn’t until I found Ruby and Jim that I ever got it. Jim, coincidentally, wasn’t aware of this at the time.

Jim is one of the best teachers I’ve ever met. He exudes empathy. He has the ability to understand how the pieces of what he is presenting will click in your mind. And then he knows how to challenge your new understanding to help you see an even bigger picture. And no matter how good your code is he knows how it can be a bit better. And no matter how well you know something he can teach you a just little more. He loves programming and he loves programmers.

And Jim is incredibly giving of his time and talents. Back when I was learning Ruby he had all of his presentation materials online. Sometimes even videos of his presentations. (Back in the dark ages before Confreaks having a video of your presentation was rather rare.) His openness enabled me to learn and grow. I was, and continue to be, fascinated by Jim’s presentation style and his approach to teaching. I watched his presentations over and over, hoping to absorb some of his awesomeness by osmosis.

Am I Jim’s biggest cyber stalker? I don’t know. But because of how seriously I studied his materials I do consider him to be my mentor. From those early days of poring over his slides and code to force myself into new ways of thinking I have had the pleasure to get to know Jim in real life. All the things that have been said about Jim are true: he is a prolific coder, has a cunning mind, and a caring heart. My early goal was to be like him, but I found it was much more satisfying to be his friend.

Dinner and a comic book movie with @jimweirich!?! I am the luckiest geek in the world!
— Mike Moore (@blowmage) August 10, 2012

In the time since then I have been lucky enough to speak at several Ruby conferences. I have a few libraries that enjoy a modicum of notoriety. And I organize the MWRC conference that has contributed over one hundred conference session recordings available online for free. And in all that time I have merely been following Jim’s footsteps.

Jim Weirich is the best of us. He is the superlative example of the niceness that Ruby is known for. And last night he passed away and I will never see him again.

I don’t know Jim’s family, but I do know that he loved them. He beamed with pride whenever he talked about them. As best I could tell he enjoyed his family to the fullest. I wish I did know them so I could tell them in person how much Jim means to me. I lost both my parents around 10 years ago, and my wound from that loss is still open. I can only imagine their grief today. My thoughts and prayers are with his family, and those close to him.

Me and @jimweirich. #rubyfriends pic.twitter.com/UiDbk2YD
— Mike Moore (@blowmage) November 3, 2012

Thank you Jim for the influence you have had on my life. I treasure our friendship more than you will ever know.

Adding Minitest Spec in Rails 4

2013-07-08T00:00:00+00:00

Rails 4 is out, and among its many improvements is upgrading the default testing library from Test::Unit to Minitest. And although Minitest has some surprisingly interesting features, the most discussed addition is its spec DSL. It is designed as a subset of RSpec’s DSL, though I’ll leave to others any direct comparisons to RSpec. Suffice it to say it its focus is to give you a friendly syntax to generate the test classes, methods, and assertions you’d normally write in plain Ruby.

It’ll take a little configuration, and yes, there’s a gem for that, but the DIY approach takes surprisingly little elbow grease and will teach you a couple of cool Minitest features. Let’s dive in!

Step 1: Setting the Minitest Dependency

Rails 4 sets the dependency on Minitest to “~> 4.2”. This means that it will use any Minitest 4.x release that is 4.2 or above. This also means that we can’t use the newly released Minitest 5, or the older 4.1. Since we want the spec DSL, we need to set the dependency to “~> 4.7”. To do that, let’s set the dependency in the Gemfile:

group :test do
  gem "minitest", "~> 4.7"
end

Step 2: Extending MiniTest::Spec::DSL

Minitest 4.7 introduced the MiniTest::Spec::DSL module. To add the spec DSL to our Rails tests, we’ll add this to the test/test_helper.rb file.

Let’s require the source file just after the rails/test_help require:

ENV["RAILS_ENV"] ||= "test"
require File.expand_path('../../config/environment', __FILE__)
require 'rails/test_help'
require "minitest/spec"

The second change is to extend MiniTest::Spec::DSL in ActiveSupport::TestClass. Luckily for us, there is already a place in the helper for us to make these changes:

class ActiveSupport::TestCase
  ActiveRecord::Migration.check_pending!

  # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.
  #
  # Note: You'll currently still have to declare fixtures explicitly in integration tests
  # -- they do not yet inherit this setting
  fixtures :all

  # Add more helper methods to be used by all tests here...
  extend MiniTest::Spec::DSL
end

Cool Minitest trick #1: register_spec_type

The last change is to tell MiniTest::Spec to use ActiveSupport::TestCase when describing an ActiveRecord model. We do this by calling Minitest’s register_spec_type method.

class ActiveSupport::TestCase
  ActiveRecord::Migration.check_pending!

  # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.
  #
  # Note: You'll currently still have to declare fixtures explicitly in integration tests
  # -- they do not yet inherit this setting
  fixtures :all

  # Add more helper methods to be used by all tests here...
  extend MiniTest::Spec::DSL

  register_spec_type self do |desc|
    desc < ActiveRecord::Base if desc.is_a? Class
  end
end

Step 3: Writing Specs

Now that we’ve configured the spec DSL, let’s use it! Let’s assume we have the following test in test/models/user_test.rb:

require "test_helper"

class UserTest < ActiveSupport::TestCase

  def valid_params
    { name: "John Doe", email: "john@example.com" }
  end

  def test_valid
    user = User.new valid_params

    assert user.valid?, "Can't create with valid params: #{user.errors.messages}"
  end

  def test_invalid_without_email
    params = valid_params.clone
    params.delete :email
    user = User.new params

    refute user.valid?, "Can't be valid without email"
    assert user.errors[:email], "Missing error when without email"
  end

end

We can convert this test to the spec DSL one section at a time. Let’s start with replacing the class with a describe block:

require "test_helper"

describe User do

  def valid_params
    { name: "John Doe", email: "john@example.com" }
  end

We can bypass the need to explicitly define a class inheriting from ActiveSupport::TestCase because User inherits from ActiveRecord and we registered the spec type in the previous step.

Next we can replace the test methods with it blocks:

def valid_params
  { name: "John Doe", email: "john@example.com" }
end

it "is valid with valid params" do
  user = User.new valid_params

  assert user.valid?, "Can't create with valid params: #{user.errors.messages}"
end

it "is invalid without an email" do
  params = valid_params.clone
  params.delete :email
  user = User.new params

  refute user.valid?, "Can't be valid without email"
  assert user.errors[:email], "Missing error when without email"
end

Now let’s replace the calls to the assertions with Minitest’s expectations. In the first test block, we are passing user.valid? to assert. The spec DSL provides many assertions as expectations, and in this case we can write this test using the must_be expectation. That would look like this:

it "is valid with valid params" do
  user = User.new valid_params

  user.must_be :valid? # Must create with valid params
end

In the next test block, we are refuting that the user is valid. We can use the wont_be expectation for that. And then we are asserting that there are errors on the email attribute. We can use a combination of the must_be expectation and the present? method Rails adds to clean that up a bit:

it "is invalid without an email" do
  params = valid_params.clone
  params.delete :email
  user = User.new params

  user.wont_be :valid? #Must not be valid without email
  user.errors[:email].must_be :present? # Must have error for missing email
end

We can also move some helper methods to let blocks. In the end, here is what the test can look like using the spec DSL:

require "test_helper"

describe User do

  let(:user_params) { { name: "John Doe", email: "john@example.com" } }
  let(:user) { User.new user_params }

  it "is valid with valid params" do
    user.must_be :valid? # Must create with valid params
  end

  it "is invalid without an email" do
    # Delete email before user let is called
    user_params.delete :email

    user.wont_be :valid? # Must not be valid without email
    user.errors[:email].must_be :present? # Must have error for missing email
  end

end

Step 4: Smoothing The Rough Edges

The Minitest spec DSL does not support nested context blocks, but it does support nested describe blocks. Except… ActiveSupport::TestCase also defines a describe method, which stomps on the spec DSL. Oh no!

But wait, this is Ruby! To use nested describe blocks in your tests, we just need to remove the method from ActiveSupport::TestCase. To do this, add a call to remove_method just before MiniTest::Spec::DSL is added in the test helper:

class ActiveSupport::TestCase
  ActiveRecord::Migration.check_pending!

  # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.
  #
  # Note: You'll currently still have to declare fixtures explicitly in integration tests
  # -- they do not yet inherit this setting
  fixtures :all

  # Add more helper methods to be used by all tests here...
  class << self
    remove_method :describe
  end

  extend MiniTest::Spec::DSL

  register_spec_type self do |desc|
    desc < ActiveRecord::Base if desc.is_a? Class
  end
end

If you prefer expectations to assertions, we’ll need to add expectations for the several assertions that Rails provides, such as assert_response, assert_redirected_to, and assert_difference. We can do all this in the test helper file.

Cool Minitest trick #2: infect_an_assertion

First, create a new module and use the method infect_an_assertion that Minitest provides:

module MyApp::Expectations
  infect_an_assertion :assert_difference, :must_change
  infect_an_assertion :assert_no_difference, :wont_change
end

Then we can include that module in Object so that those expectations are available everywhere:

class Object
  include MyApp::Expectations
end

Now we can use these expectations in our tests. Yay!

it "is able to be saved when valid" do
  lambda { user.save }.must_change "User.count", +1
end

That’s a Wrap!

As you can see, Minitest and Rails go hand in hand. I would even go so far as to say they are BFFs, like I did in this presentation. I hope you give Minitest a shot. Don’t let its size fool you. It may be small, but it’s a surprisingly powerful, full-featured testing library.

If this seems like too much configuration to manage on your own, that’s okay! Feel free to check out the minitest-rails gem, which does all this for you, includes some handy rake tasks, and lets you generate tests using the spec DSL. Either way, hopefully you know a little more about the test framework that comes with Rails 4.

Minitest & Rails: Total BFFs

2013-05-29T00:00:00+00:00

When I started in Ruby I was intimidated by testing. Partially because the Ruby culture identifies so strongly with testing, and partially because I had no idea what I was doing. I did it wrong more than I did it right. At one point I even gave up on testing because I didn’t know how to do it in a way that wouldn’t cost more time than not having tests at all. And then, suddenly, a switch went off in my head and I got it. I figured out how to test and how to design code so it could be tested. Then I figured out how to drive the design of my code with tests. Finally things made sense.

Since then I’ve paired with a fair number of programmers and a common source of discussion has been testing. I’ve found that my experience of being intimidated by testing was not mine alone, and was more common than I ever thought. Over and over I talked to devs that knew they weren’t testing right but weren’t sure how to ask for help or even what questions to ask. What I’ve found is that everyone’s testing switch in their head is different. And the only way to flip it is to just keep testing and asking questions.

So a couple weeks ago I gave a presentation at Scottish Ruby Conf entitled Minitest & Rails: Total BFFs”. I tried to cover the changes Rails 4 has made to its testing infrastructure and how you could enable Minitest features like the spec DSL. My hope is that it will help you flip the switch in your head, because you don’t have to be as hardcore as Ryan Davis or as visionary as DHH to use these tools.

Also, there are ponies.

1.2.1a. Mike Moore.mp4 from Neo (UK) on Vimeo.

Huge thanks to Alan Francis and Paul Wilson for throwing a wonderful conference and for accepting my proposal. Scotland made a pretty big impact on me and I can’t wait to return.

Also, I want to explain why I presented the material this way, because it wasn’t arbitrary, but that will have to wait for another post.

minitest-rails: Roadmap to 1.0

2013-03-18T00:00:00+00:00

tl;dr: The newest minitest and minitest-rails are awesome.

I’ve been working on the minitest-rails project for almost two years now. That is a very long time to work on a project without having a stable release. Fortunately with the 0.9 releasethat I released earlier tonight we are on our way to stability.

The Problem

Inheritance is great, except when it isn’t. All Rails tests inherit from ActiveSupport::TestCase. In Rails 3, ActiveSupport::TestCase inherits from Test::Unit::TestCase, which inherits from MiniTest::Unit::TestCase. (In Ruby 1.9 and higher. If you are on Ruby 1.8 you can install the minitest_tu_shim gem to inject minitest into the inheritance chain.)

What we want, however, is to inherit from MiniTest::Spec. In fact, for almost a year during the development of Rails 4 ActiveSupport::TestCase inheritedd from MiniTest::Spec. Unfortunately, that was changed before the first beta gem was released and it now inherits directly from MiniTest::Unit::TestCase. (Which is disappointing but totally appropriate for the core team to do. It’s their project, and they should do what they think is best, always.) So what do we do? How can we change the nature of the Rails tests? Time to roll up our sleeves and get hacky!

A Terrible Solution

One suboptimal solution is to change the ancestry of the ActiveSupport::TestCase and inject MiniTest::Spec. For minitest-rails this meant creating a MiniTest::Rails::TestCase that inherits from MiniTest::Spec and includes all the Rails testing modules. For minitest-spec-rails this meant similarly replacing Test::Unit::TestCase with an implementation that inherits from MiniTest::Spec.

This approach generally works, but you have to be very careful in how you load the libraries that are getting replaced. You can replace a constant in Ruby, but if another object is already inheriting from the replaced object it will continue to inherit from it even after the constant is replaced. Problems arise when other libraries affect how code is loaded, and upend your carefully planned hack. And ultimately that is inevitable. (Don’t even get me started on what Rails 3’s threadsafe! option does to how code is loaded.)

A Sustainable Solution

What we really need is to enable MiniTest::Spec functionality without altering the ancestry. But how? Instead of using Ruby meta-programming for evil, how about we use it for good? Imagine if this worked:

class ActiveSupport::TestCase
  extend MiniTest::Spec::DSL
end

With the latest release of minitest that’s the case. Ryan Davis added the ability to enable the spec DSL on any minitest TestCase. This means that this is functionally equivalent:

class TestMyStuff < MiniTest::Spec
  it "works" do
    assert true
  end
end

class TestMyStuffAgain < MiniTest::Test::Unit
  extend MiniTest::Spec::DSL

  it "works" do
    assert true
  end
end

Because of how MiniTest::Spec was designed this was an easy change to make. I love working in code that Ryan produces because this is generally the case.

The Unlimited Possibilities

This change means that supporting minitest’s spec DSL is suddenly trivial. Even for older Rails 2.x apps! Specifying the version of minitest in your Rails project’s Gemfile and including the following in your test helper enables the DSL:

require "minitest/spec"
class ActiveSupport::TestCase
  extend MiniTest::Spec::DSL
end

Unfortunately, that doesn’t do everything for you. If you want to use the full spec DSL, you need to configure which TestCase is used in your tests. To do that you need to register the TestCase with the spec DSL:

class ActiveSupport::TestCase
  # Use AS::TestCase for the base class when describing a model
  register_spec_type(self) do |desc|
    desc < ActiveRecord::Base if desc.is_a?(Class)
  end
end

class ActionController::TestCase
  # Use AC::TestCase for the base class when describing a controller
  register_spec_type(self) do |desc|
    Class === desc && desc < ActionController::Metal
  end
  register_spec_type(/Controller( ?Test)?\z/i, self)
end

And so on. But there is another piece. Controller/Helper/Mailer tests also attempt to deduce the test subject from the test name to create an instance in the test. This is a bit more involved, and currently minitest-rails uses MiniTest::Rails::Testing::ConstantLookup to resolve the constant from the test name.

There are other little incompatibilities that need to be addressed to enable the spec DSL in your Rails apps. Fortunately, all this and more is included with minitest-rails, which is the easiest way to use advanced minitest functionality within your Rails app. (End sales pitch.)

What this means is that instead of minitest-rails hacking how Rails loads code, it can just declare how we want our tests configured. This is a huge step forward.

Upgrade Path

If you are already using minitest-rails, thank you! Because of the various ways we’ve attempted to inject minitest into Rails there is some cruft that has accumulated along the way. So for the 0.9 release we’ve added a few deprecation warnings for things that will be removed in 1.0. If you have an existing app using minitest-rails please look at the Upgrade Guide and make those changes.

Refactoring towards "better" code

2013-02-07T00:00:00+00:00

What makes code good? How do you quantify code quality? I’m not talking metrics, I’m talking good old gut feel. How do know good code when you see it? Certainly, working code is better than non-working code. But laying that aside; if two codebases work as expected, how do you judge which is better? Instead of talking about how I make that judgement, how about I show you?

I caught a bit of heat yesterday for a retweet about some code from the newly released Discourse project that was not following the typical Rails conventions. In retrospect I see that I was wrong to do so, and I apologize. Several people rightly suggested to me that I submit a pull request instead, so here it is.

The code in question is the implementation of the UsersController#search_users action. This action is not super critical to the running of the site. The changes I’ll be showing here do not represent an unrolling of any significant performance optimization, AFAIK. I am going to attempt to perform a true refactor: improving the internals of the code without affecting the external behavior, including performance.

The first step is to make sure that we have adequate code coverage to perform a refactor. We need to know if we have changed any behavior accidentally, or introduced a logical error in our new code. Unfortunately, there are no existing tests for this action. So our first step is to add those tests.

The Discourse application is using RSpec, so we’ll create a new file for our new tests:

spec/controllers/users_controller/search_users_spec.rb

I choose to create a new test file instead of adding a new context to the existing UsersController test for a couple reasons: First, because the new tests are going to be specific to the search logic, the data setup will be much different. And second, I dislike traversing a spec file hundreds or thousands of lines long looking for the right nested block. I do, however, have lots of experience traversing directories and finding files.

The search logic itself is pretty simple. It performs a search using PostgreSQL’s full text capabilities. The only real complexity is in how the results are sorted. The closest matches are sorted first. If a topic is provided then those users with posts on the topic will be ranked higher than those without. So the question is how to add test coverage?

The approach I’m using here is slow. I’m more concerned with correctness of the behavior than the speed of the tests at the moment. But I am confident these tests will be revisited and improved for speed later, so let’s make the tests as clear as we can.

Pasting all the tests here isn’t too interesting. You can view the full commit here: Add test coverage for UsersController#search_users

Now that we have tests, I want to move the bulk of search logic from UsersController#search_users to a model. The reason is because the majority of the code specific to the implementation. Ideally, I want to be able to change the implementation of my search without having to change the controller code. I don’t want to move even more code to the poor User model; it looks far too bloated already. Instead, lets create a new domain model. I want this new model to just be responsible for the User search, so let’s call it UserSearch.

app/models/user_search.rb

   def search_users
     term = (params[:term] || "").strip.downcase
     topic_id = params[:topic_id]
     topic_id = topic_id.to_i if topic_id
-    sql = "select username, name, email from users u "
-    if topic_id
-      sql << "left join (select distinct p.user_id from posts p where topic_id = :topic_id) s on
-        s.user_id = u.id "
-    end
-
-    if term.length > 0
-      sql << "where username_lower like :term_like or
-              to_tsvector('simple', name) @@
-              to_tsquery('simple',
-                regexp_replace(
-                  regexp_replace(
-                    cast(plainto_tsquery(:term) as text)
-                    ,'\''(?: |$)', ':*''', 'g'),
-                '''', '', 'g')
-              ) "
-
-    end
-
-    sql << "order by case when username_lower = :term then 0 else 1 end asc, "
-    if topic_id
-      sql << " case when s.user_id is null then 0 else 1 end desc, "
-    end
-
-    sql << " case when last_seen_at is null then 0 else 1 end desc, last_seen_at desc, username asc limit(20)"
-
-    results = User.exec_sql(sql, topic_id: topic_id, term_like: "#{term}%", term: term)
-    results = results.map do |r|
-      r["avatar_template"] = User.avatar_template(r["email"])
-      r.delete("email")
-      r
-    end
-    render :json => results
+
+    results = UserSearch.search term, topic_id
+    render :json => results
   end

class UserSearch

  def self.search term, topic_id
    sql = "select username, name, email from users u "
    if topic_id
      sql << "left join (select distinct p.user_id from posts p where topic_id = :topic_id) s on
        s.user_id = u.id "
    end

    if term.length > 0
      sql << "where username_lower like :term_like or
              to_tsvector('simple', name) @@
              to_tsquery('simple',
                regexp_replace(
                  regexp_replace(
                    cast(plainto_tsquery(:term) as text)
                    ,'\''(?: |$)', ':*''', 'g'),
                '''', '', 'g')
              ) "

    end

    sql << "order by case when username_lower = :term then 0 else 1 end asc, "
    if topic_id
      sql << " case when s.user_id is null then 0 else 1 end desc, "
    end

    sql << " case when last_seen_at is null then 0 else 1 end desc, last_seen_at desc, username asc limit(20)"

    results = User.exec_sql(sql, topic_id: topic_id, term_like: "#{term}%", term: term)
    results = results.map do |r|
      r["avatar_template"] = User.avatar_template(r["email"])
      r.delete("email")
      r
    end
  end

end

Some might wonder why this new object doesn’t go in the lib directory instead. For me, the lib directory is for code that can someday be extracted out of the app. Like a library to access an API. Something like searching users seems to be a core part of the domain for this app. Even though this controller is the only thing calling it now, I can see an admin controller, or a background job (like a mailer) using this functionality in the future. So I think it makes sense to place this in app/models.

Another question some may have is why UserSearch doesn’t inherit from ActiveRecord. Well, this new domain model isn’t going to be responsible for representing a User record; its job is to search for those records. Not every model in your domain needs to inherit from ActiveRecord. As apps grow larger I find its better to have more and more of my domain logic outside of the ActiveRecord models and in other domain models.

You can view the full commit here: Extract search logic to UserSearch model

With this move the tests still pass. Notice I don’t have any unit tests for the UserSearch object yet. I could add some, but they would only be duplicates of the search_users test. So for now I’m going to allow those search_users tests to act as acceptance tests for UserSearch. I have some ideas for what I eventually want this object to be and do, so I’m skipping the tests for just a bit, while I experiment a bit more.

The controller method now looks much better.

def search_users
  term = (params[:term] || "").strip.downcase
  topic_id = params[:topic_id]
  topic_id = topic_id.to_i if topic_id

  results = UserSearch.search term, topic_id
  render :json => results
end

There are three main parts to the method now:

Cleansing the options provided by the user
Retrieving the data
Formatting the data to return to the user

This is how I want to see my controller actions. I don’t want to be distracted by the implementation details of any of those steps. I simply want a declaration of the steps that the controller is responsible for.

Now that the controller is more declarative and less instructional, let’s see if we can help UserSearch to be less hairy. All the logic is on one big method. It seems we can break that up into individual methods with separate responsibilities. I think it makes sense to separate the code that generates the SQL from the code that executes the SQL.

 class UserSearch

   def self.search term, topic_id
-    sql = "select username, name, email from users u "
-    if topic_id
-      sql << "left join (select distinct p.user_id from posts p where topic_id = :topic_id) s on
-        s.user_id = u.id "
-    end
-
-    if term.length > 0
-      sql << "where username_lower like :term_like or
-              to_tsvector('simple', name) @@
-              to_tsquery('simple',
-                regexp_replace(
-                  regexp_replace(
-                    cast(plainto_tsquery(:term) as text)
-                    ,'\''(?: |$)', ':*''', 'g'),
-                '''', '', 'g')
-              ) "
-
-    end
-
-    sql << "order by case when username_lower = :term then 0 else 1 end asc, "
-    if topic_id
-      sql << " case when s.user_id is null then 0 else 1 end desc, "
-    end
-
-    sql << " case when last_seen_at is null then 0 else 1 end desc, last_seen_at desc, username asc limit(20)"
+    sql = sql term, topic_id
     results = User.exec_sql(sql, topic_id: topic_id, term_like: "#{term}%", term: term)
     results = results.map do |r|
       r["avatar_template"] = User.avatar_template(r["email"])
       r.delete("email")
       r
     end
   end
+
+  def self.sql term, topic_id
+    sql = "select username, name, email from users u "
+    if topic_id
+      sql << "left join (select distinct p.user_id from posts p where topic_id = :topic_id) s on
+        s.user_id = u.id "
+    end
+
+    if term.length > 0
+      sql << "where username_lower like :term_like or
+              to_tsvector('simple', name) @@
+              to_tsquery('simple',
+                regexp_replace(
+                  regexp_replace(
+                    cast(plainto_tsquery(:term) as text)
+                    ,'\''(?: |$)', ':*''', 'g'),
+                '''', '', 'g')
+              ) "
+
+    end
+
+    sql << "order by case when username_lower = :term then 0 else 1 end asc, "
+    if topic_id
+      sql << " case when s.user_id is null then 0 else 1 end desc, "
+    end
+
+    sql << " case when last_seen_at is null then 0 else 1 end desc, last_seen_at desc, username asc limit(20)"
+    sql
+  end

 end

You can view the full commit here: Extract SQL generation method

That seems to be clearer for me, and all the SQL string concatenation is isolated into one method. If a new mechanism was introduced to generate the SQL string, only UserSearch.sql would have to change.

At this point I’m ready to start making some slight changes to how the code works. I spoke with one of the developers and he mentioned that they wanted the objects returned from the search to be the normal ActiveRecord models, and not just an array of hashes. In order to make that change we’ll have to change some of the details of UserSearch, but also change the formatting of the data in UserController to ensure that the behavior remains.

The first change here is to use User.find_by_sql instead of User.exec_sql. This means that the extra work that the search method performed to add avatar_template and remove email can be removed. The User objects can calculate avatar_template, and UserController can remove email from the results. In order to use User.find_by_sql, the SQL string must have the values added to the string.

 class UserSearch

   def self.search term, topic_id
-    sql = sql term, topic_id
-    results = User.exec_sql(sql, topic_id: topic_id, term_like: "#{term}%", term: term)
-    results = results.map do |r|
-      r["avatar_template"] = User.avatar_template(r["email"])
-      r.delete("email")
-      r
-    end
+    User.find_by_sql sql(term, topic_id)
   end

+  private
+
   def self.sql term, topic_id
     sql = "select username, name, email from users u "
     if topic_id
       sql << "left join (select distinct p.user_id from posts p where topic_id = :topic_id) s on
         s.user_id = u.id "
     end

     if term.length > 0
       sql << "where username_lower like :term_like or
               to_tsvector('simple', name) @@
               to_tsquery('simple',
                 regexp_replace(
                   regexp_replace(
                     cast(plainto_tsquery(:term) as text)
                     ,'\''(?: |$)', ':*''', 'g'),
                 '''', '', 'g')
               ) "

     end

     sql << "order by case when username_lower = :term then 0 else 1 end asc, "
     if topic_id
       sql << " case when s.user_id is null then 0 else 1 end desc, "
     end

     sql << " case when last_seen_at is null then 0 else 1 end desc, last_seen_at desc, username asc limit(20)"
-    sql
+
+    sanitize_sql_array(sql, topic_id: topic_id, term_like: "#{term}%", term: term)
+  end
+
+  def self.sanitize_sql_array *args
+    ActiveRecord::Base.send(:sanitize_sql_array, args)
   end

 end

The second change is to properly serialize the objects to JSON and match the existing format.

   def search_users
     term = (params[:term] || "").strip.downcase
     topic_id = params[:topic_id]
     topic_id = topic_id.to_i if topic_id

     results = UserSearch.search term, topic_id

-    render :json => results
+    render json: { users: results.as_json( only:    [ :username, :name ],
+                                           methods: :avatar_template ) }
   end

You can view the full commit here: Return User objects instead of hashes

And the tests still pass.

There are a couple more things that stand out to me. The fact that we are downcasing term in the controller, and that the generated SQL is expecting the value to be downcased. This seems odd to me. I’d like these objects to be a little more liberal in the data they accept. One way to address this is to change the conditional from LIKE to ILIKE, which is case insensitive. I’m not sure if there are performance concerns about that though. Another option would be to change the SQL to lower(username) LIKE lower(:term_like), and create an index for lower(username). Yes, PostgreSQL will index values returned from functions like lower(). I suspect the username_lower column could be removed as well.

     if term.length > 0
-      sql << "where username_lower like :term_like or
+      sql << "where username ilike :term_like or
               to_tsvector('simple', name) @@
               to_tsquery('simple',

   def search_users
-    term = (params[:term] || "").strip.downcase
+    term = params[:term].to_s.strip
     topic_id = params[:topic_id]
     topic_id = topic_id.to_i if topic_id

You can view the full commit here: Remove expectation of term case

Now I am generally happy with the state of the code, and its time to focus on the state of the tests. All of our test coverage is in the controller tests. Controller tests are integration tests, and I dislike having this much detail specified in the controller tests. I like my controller tests to check that the actions are responding as expected, and to do little more than a sanity check that the data returned in as expected. In other words, the integration tests make sure that the integration works. If the data is important enough to be tested, then it should be extracted to its own object and unit tested there. Luckily we have just that with our new UserSearch object.

So my next commit is to move the bulk of the behavior tests for the UserSearch to the new spec/models/user_search_spec.rb file. I’ll also remove the previous search_users test file and add some very general tests to the spec/controllers/user_controller_spec.rb file. Yes, I know I said I like separate files for my tests, but this isn’t my project so I’m going to try to follow their conventions in the pull request as much as possible.

Lots of changes here. You can view the full commit here: Refactor UserSearch tests

I think this is where I’ll leave this refactor for now. UserSearch.search still returns an array, but now it is an array of User objects and not an array of hashes. A next step would be to return an ActiveRecord::Relation object, so that additional criteria could be added, such as pagination. That would move the query away from the specific SQL statements, and I’m not sure that the developer is ready for this change just yet. Hopefully the advantages of passing an ActiveRecord::Relation object instead of an array will change the maintainers’ minds in the future.

Other changes that could be made include how the user search results are serialized to JSON. Right now that is all happening in the render call in the controller’s action. That could be extracted to a UserSearchSerializer.

Lastly, I want to point out that concerns such as performance don’t necessitate ugly code. Everything should have its place. Even the most performance intensive and vital code can be given a declarative name and dealt with in a clean, maintainable way. Like testing, I do not believe that there is an advantage to skipping this step to get the code completed faster. It may seem like it at first, but once you get used to taking this design step you quickly realize how much time is wasted on improperly designed code when you go back to old projects.

Schizophrenic code, by which I mean methods with an inconsistent level of abstraction, is difficult to reason about. Programmers new to your app will struggle more than necessary in order to understand how the app works. I’ve seen this over and over, and the effect is similar to hazing new members of a group. Don’t be a code bully, whether intentional or not. Life is too short to deal with hostile code. Be nice in all that you do, including your code.

How to write a conference proposal

2013-01-24T00:00:00+00:00

I run a small but successful Ruby conference. It is a difficult and draining experience, but I’m generally very happy doing it. We select the majority of our sessions from proposals submitted by folks just like you. One of my least favorite parts of running the conference is letting folks know their proposal was not selected. I had to do that today.

Every year folks ask why they didn’t get selected. Sometimes they ask me, sometimes they ask themselves loudly on twitter. My conference has a very specific type of session it’s looking for, sort of a niche of a niche. But more often than not the proposals that are not seriously considered are not off topic as much as they are poorly written. I’ve been on all sides of this, as a speaker that has been accepted, a speaker that has not been selected, and an organizer. So here are some thoughts from the mind of a conference organizer on what makes a good conference proposal.

Make the title good

Be clear. What makes a title “good” depends on what type of session you are proposing. Is it an exhaustive look at a specific subject? Then make that clear in your title. “Foo Deconstructed” Is it a beginner-friendly introduction? “Foo for the uninitiated” You want to convey what the session is about and what experience level it is aimed at.

Avoid hostility. You may think it is cute to say something like “You suck at topic”, but in my experience that isn’t effective. Folks don’t want to feel bad about themselves or mad at the presenter, and that title will make them feel one or the other. A better alternative might be “Being great at topic”. It should also go without saying that you should avoid sexism and racism in your proposals, but you would be surprised. Just don’t, okay?

Have a hook. Most attendees will judge their interest solely by the title. The title is the hook. It’s important to grab attention, but don’t be misleading. The goal isn’t to shock someone into reading your blog post, it’s to give them an idea of why they’d benefit from attending your session (or accepting your proposal).

Description/Abstract

This is the meat of the proposal. It’s common for conferences to print this in the program unchanged. So consider that this needs to appeal not just to the selection committee, but to conference attendees as well.

Focus on the outcome. What will attendees know by the end of the session? Describing the benefits of the session is much more effective than the mechanics of what the session will cover.

Keep it brief. It’s unfair to ask a reader to parse through 3 paragraphs setting up a scenario that the session will address. A person ought to be able to scan the description and feel confident about what will be covered.

Avoid lists. Sticking with the “why” is where the power of your proposal comes from. Some may disagree with this guideline, but if your proposal contains lists (or more than two paragraphs), it’s a strong indicator that you’re diving deeper into the “what” than the “why”. (Yes, I understand the irony of giving the advice to not use lists in a list. But this blog post isn’t a conference proposal either.)

Make it topical. Consider the audience and the theme of the conference. If you are submitting to a Python conference, then it’s probably not a good idea to submit a proposal on Lisp. Yes, you may think that the audience should all hear how Lisp is great, but will the attendees care? Does the selection committee? If the conference clearly states that they intend to be as beginner-friendly as possible, then your dive into the subtle details of natural language processing libraries is unlikely to be accepted, no matter how great a talk it would be.

Both attendees and selection committee members are not clairvoyant. They don’t know why you think this subject is good or not, so you need to explain it to them.

Justification

Some CFPs allow you to enter some text only to be read and considered by the selection committee. If you have this available, then there are a couple things you should consider:

Stop selling. Any selection member has already read through dozens or hundreds of proposals all vying for their attention. This isn’t the place for the hard sell. This is the place to level with the selection member. Is this only aimed at basket weaving beginners with extensive underwater experience? Then state that here.

Explain the destination. Are you intentionally trying to sell one thing in your description because it’s popular, but then expose it as flawed during your session? Let the selection members know. If you have a hard time quantifying where attendees are going to be at the end of your session, you might have a problem with your proposal.

Thank them. Do you like their conference? Have you been there before? What do you like about it? More than kissing up, it shows you understand the kind of conference the organizers are striving for. It’s not a good place to rant about what is wrong with the conference, the community, or the world.

Biography

Most organizers or selection committees don’t care as much about the biography of the speaker as the conference attendees do. So my advice here is to explain what makes you unique. Are you an authority on the subject? Do you have a novel or interesting take? Don’t make this overly long, folks aren’t looking to hire you. They just want to know if you know your stuff and are worth watching.

If you’re looking to inject humor, my opinion is that your best bet is to play it straight in your proposal and go for broke on humor in your bio.

I hope this helps. I understand how frustrating it can be to spend so much time and energy on a proposal only to be shattered when it isn’t accepted. My advice is to play for the long term. Pay attention to what ends up in the conference sessions and figure out where you can differentiate yourself while adding value. Speak at user groups. Attend a Toastmasters meeting. Write a book. You will only get better.

Escape to RubyConf!

2012-09-19T00:00:00+00:00

RubyConf 2012 is coming up. I will be there, and I’d love to hang out with you. You should come. It’ll be fun. And if you are coming, you need to train. Fortunately its easy enough to do. Just type the following:

$ gem install escape_to_rubyconf
$ escape_to_rubyconf

So not many know this, but I spoke on Writing Games with Ruby at RubyConf 2010. This game is the end product of my session. I figured it would be fun to throw it in a gem and release it. So here it is!

There were unfortunate problems with the recording of my session, and I’ve been working with Confreaks to recreate it for the video. But one thing led to another and the video still isn’t finished. You can download a rough cut though. Let me know what you think.

Where to Put Tests in Rails

2012-07-12T00:00:00+00:00

One of the things that bothers me when developing Rails apps is where tests are placed by default. Rails puts model tests in test/unit, controller tests in test/functional, and acceptance tests in test/integration. But the names of those locations doesn’t always match what those tests do.

The three main types of tests we typically write in Rails apps are Unit, Integration, and Acceptance. Unit tests work on an isolated units of code, exercising a single method or object. Integration tests work on a subsystem within an app, exercising the dependencies within the subsystem. Acceptance tests (previously known as functional tests) work on the application as a whole to determine if it performs according to the customer’s acceptance criteria. I encourage you to follow those links if you want to read more about the definitions and differences between these three types of tests.

Rails puts model tests under test/unit, but are they always unit tests? It is common to perform unit and integration tests on models, depending on what the model is responsible for and how it is designed. In my experience, many Rails apps have a problem overloading the User object with too many responsibilities and dependencies. And the tests for those dependencies are by definition integration tests. However, the location of those tests tell us that they are unit tests.

This is more than a pedantic exercise. These test names have meanings outside of the Rails community and this has caused much confusion over the years. My opinion is that this naming confusion has contributed to the adoption of Rspec over Rails’ default tests using Test::Unit, because Rspec names their tests according to what is being tested and not the type of tests being performed.

Part of the reason I started minitest-rails was to correct this. This is why minitest-rails places model tests in test/models, controller tests in test/controllers, helper tests in test/helpers, mailer tests in test/mailers, and acceptance tests in test/acceptance. Now my model, helper, controller, and mailer tests are located where I consider logical. I also find this layout more discoverable. For instance, I don’t have to explain the layout when introducing Rails or testing to new developers.

All this said, minitest-rails is a young effort and it has much room to improve. Acceptance tests are in test/acceptance, but the generator is still named integration_test. I think we can to better. If you want to help, jump on the mailing list and help make it better.

Announcing minitest-rails

2012-07-10T00:00:00+00:00

Yesterday I released version 0.1 of minitest-rails, a library that enables you to test your Rails 3 apps using minitest.

Getting Started

Installing

The minitest-rails gem is intended to work side-by-side with Test::Unit and/or Rspec. But if you are starting a new project and only want to use minitest-rails, you can create a new rails app without a testing framework:

rails new MyApp --skip-test-unit

Once you have a Rails app all you need to do is add minitest-rails to the test and development groups in your Gemfile:

group :test, :development do
  gem 'minitest-rails'
end

Next run the installation generator to add the test/minitest_helper.rb file:

rails generate mini_test:install

That’s it! You are ready to write some tests.

Basic Usage

You can generate tests, or you can write your own. Let’s assume you have the following model:

class User < ActiveRecord::Base
  attr_accessible :name
  validates_presence_of :name
end

Testing this object is very easy. The only differences between Test::Unit and minitest are the different helper in the require, and the TestCase being namespaced under MiniTest::Rails.

require "minitest_helper"

class UserTest < MiniTest::Rails::ActiveSupport::TestCase
  def test_valid
    user = User.new name: "Ryan Davis"
    assert user.valid?, "valid with a name"
  end

  def test_invalid
    user = User.new
    refute user.valid?, "invalid without a name"
  end
end

Using the Spec DSL

The feature that most seem to be excited by is the ability to use the Spec DSL in your tests.

require "minitest_helper"

describe User do
  it "can be valid" do
    user = User.new name: "Ryan Davis"
    user.valid?.must_equal true
  end

  it "can be invalid" do
    user = User.new
    user.valid?.wont_equal true
  end
end

You can even tell the generators to output tests using the Spec DSL by providing the --spec option:

rails generate model User --spec

Or you can set the Spec DSL to be the default by configuring it in your config/application.rb file:

config.generators do |g|
  g.test_framework :mini_test, :spec => true
end

Of course, you can mix and match between the Unit and Spec styles. I prefer to use the Spec DSL blocks with Unit’s assertions.

require "minitest_helper"

describe User do
  it "can be valid" do
    user = User.new name: "Ryan Davis"
    assert user.valid?, "valid with a name"
  end

  it "can be invalid" do
    user = User.new
    refute user.valid?, "invalid without a name"
  end
end

But however you use it is up to you.

Test Locations

One of the biggest changes from Test::Unit is the default location of the tests. Like Rspec, minitest-rails organizes the tests by subject and not the type of test that is performed. Its possible to perform integration tests on models. (Rails unfortunately calls these functional tests.) Just as it is possible to perform unit tests on controllers. So the following locations are used:

	`Test::Unit`	`MiniTest::Rails`
Models	`test/unit/widget_test.rb`	`test/models/widget_test.rb`
Helpers	`test/unit/helpers/widget_helper_test.rb`	`test/helpers/widget_helper_test.rb`
Controller	`test/functional/widgets_controller_test.rb`	`test/controllers/widgets_controller_test.rb`
Mailer	`test/functional/notifications_test.rb`	`test/mailers/notifications_test.rb`
Acceptance	`test/integration/user_can_login_test.rb`	`test/acceptance/user_can_login_test.rb`

Overriding Test::Unit

If you want to use minitest in your current tests, you can inject minitest-rails by adding the following to your test_helper.rb file:

require "minitest/rails"
MiniTest::Rails.override_testunit!

Contribute

This is still a young project and needs lots of help. Give it a try and give some feedback. Or a patch. :)

Presenters and Decorators: A Code Tour

2012-06-13T00:00:00+00:00

I gave a session titled “Presenters and Decorators: A Code Tour” at RailsConf 2012. The Presenter and Decorator patterns are very useful approaches to keeping your Rails apps clean. I wanted to talk about presenters for a couple of reasons. First, I think we don’t talk about the View layer in our Model-View-Controller apps as much as we should. And second, I think that although “Presenters” have been around for 5+ years, we continue to misunderstand them.

On my list of career goals is to speak at RubyConf and RailsConf. I spoke at RubyConf in 2010, and this year I completed the second half of my goal. I can’t thank the good folks at Ruby Central enough for giving me the chance to speak, and for partnering with Confreaks to record it and make it freely available.

Outgrowing the Cloud

2012-03-01T00:00:00+00:00

I had a great time presenting at Ruby on Ales 2012. It has all the best parts of a really great Ruby conference and the best parts of a two day long party. What’s not to like?

My presentation was an experience report on some changes that we made to Bloomfire’s infrastructure. We had issues that we couldn’t fix on our previous cloud hosting provider, and we had many thoughts on where we wanted to go in the future. In the end we decided on moving to Amazon’s Virtual Private Cloud offereing and have been happy with the decison so far.

I’m very proud of our work on this migration. We picked up many features we had been trying to add for months and months, all with very minor changes to the application’s code. We solved the problems in the most appropriate way, and I feel good about that.

Lastly, while my presentation looks like a public love letter to Rainbow Dash, it is actually a public love letter to Jason Roelofs who did all of the heavy lifting for this effort. I’m super proud that simple_aws, the AWS library we use for all our automation, was a product of our efforts and is open source.

Rubiverse Podcast Lives!

2011-05-16T00:00:00+00:00

Okay, so its been a couple years. So what? Big deal. What is a short 768 day hiatus between friends? The good news is that my Ruby podcast is back. And not just one episode back. I’ve published three episodes recently with with Brian Ford, Nathan Esquenazi, and Wayne Seguin. I’m really happy with them and excited for a future with many more interesting conversations.

I spoke with Wayne Seguin about his über popular RVM and his plans to rewrite it using his up and coming BDSM framework. BDSM is interesting because it provides a bit more structure to the default shell environment and in my mind holds the promise that more can contribute to RVM. I expect great things from this in the future.

I spoke with Nathan Esquenazi about the Padrino web micro-framework and its take on creating modular web applications. I’m excited for more modularity in our web apps, and think Padrino is on the right track.

I also spoke with Brian Ford about the history and future of Rubinius. Rubinius seems to be on the verge of tipping over and being a viable Ruby implementation for mainstream applications. I’m very excited for this and hope that the release of 2.0 pushed it over the edge.

This is just the start. I’m committed to more conversations with interesting Rubyists. Who would you like to hear from? Let me know and I’ll make it happen.

Binary Lottery 2008

2008-03-30T00:00:00+00:00

This year at MountainWest RubyConf 2008 we had a slew of books and t-shirts to give away to attendees. Like last year we printed each attendee’s unique number on their badge in base 2 (binary). We would then randomly select a winner from the attendee list. But we would use their binary number in the reveal, showing only one number at a time. It might be cheesy, but we really enjoy it so deal. :)

This is what the badges looked like:

Last year I wrote a command line app that used figlet to display the winner. You can see the video of last year’s Lightning Talk where I show the code if you are interested. This year I wanted to mix it up a bit, and I decided about 10 hours before the conference to try my hand at using _why’s Shoes to build a GUI version. So here it is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
require 'yaml'

# The source of much evil...
def update_digit(p, cnt, dig, wnr)
  if cnt < dig
    p.replace rand(2)
  else
    p.replace wnr[8 - dig].chr
    p.style[:stroke] = red
  end
end

# Use the full path because either Shoes is easily confused, or I am
users = YAML::load(open('/Users/blowmage/Lottery/users.yaml'))
winner = users[rand(users.size)] until (winner and winner[:eligible])
count = 0

Shoes.app :width => 900, :height => 700 do
  keypress do |k|
    count += 1
  end
  stack do
    para "MountainWest RubyConf 2008 Binary Lottery\n",
      "And your winner is...", :font => 'Helvetica 48px'
    lbl_name = para '', :font => 'Helvetica 128px'
    flow do
      a = para rand(2), :font => 'Helvetica 192px'
      b = para rand(2), :font => 'Helvetica 192px'
      c = para rand(2), :font => 'Helvetica 192px'
      d = para rand(2), :font => 'Helvetica 192px'
      e = para rand(2), :font => 'Helvetica 192px'
      f = para rand(2), :font => 'Helvetica 192px'
      g = para rand(2), :font => 'Helvetica 192px'
      h = para rand(2), :font => 'Helvetica 192px'

      animate(60) do
        update_digit(a, count, 8, winner[:number])
        update_digit(b, count, 7, winner[:number])
        update_digit(c, count, 6, winner[:number])
        update_digit(d, count, 5, winner[:number])
        update_digit(e, count, 4, winner[:number])
        update_digit(f, count, 3, winner[:number])
        update_digit(g, count, 2, winner[:number])
        update_digit(h, count, 1, winner[:number])

        if count >= 8
          lbl_name.replace winner[:name]
        end
        if count > 8
          # Click one more time to flag the user so they won't win again.
          lbl_name.style[:stroke] = red
          winner[:eligible] = false
          open('/Users/blowmage/Lottery/users.yaml', 'w') do |out|
            YAML.dump users, out
          end
        end
      end
    end
  end
end

Here is a sample of what the users.yaml file looked like:

1
2
3
4
5
6
7
8
9
10
---
- :number: "00000000"
  :name: Jonathan Younger
  :eligible: true
- :number: "00000001"
  :name: Brian Cooke
  :eligible: false
- :number: "00000010"
  :name: Justin Kay
  :eligible: false

Here is what the app looked like while running:

Logan Barnett also wrote a GUI using JRuby and MonkeyBars. I really hope he releases his version as well. Here is what the app looked like on the third draw, sort of an easter egg I discovered during the conference:

Ruby Folk Are Nice

2008-03-29T00:00:00+00:00

We’re in the midst of MountainWest RubyConf 2008, and I have lots I want to blog about it. But before I get there, and before I take a 36 hour nap, I just want to let you know how nice Ruby folk are. This may be a fairly simple example, but I want to share it anyway.

I’m one of the organizers of the conference, and that has meant that I miss about half the conference sessions because I’m running around trying to fix the power or fix the wifi or organize the distribution of food. On Friday we had a really delicious lunch from Rumbi’s, but it left the conference room we ate in rather messy. We paid a cleaning deposit, but the trash needed to be collected and the room straightened. I was informed of this just as we were breaking for dinner and I told them we would fix it before the evening session. I ended up stressing over this for the entire dinner break because I hate the idea of inconveniencing the great people at the Salt Lake City library who have been so accommodating towards the 200 geeks who descended upon them destroying their power circuits and their wifi.

I got back from dinner just 20 minutes before the evening session, and called out to the ~30 folks milling around in the foyer asking for help cleaning the room up. We had ~8 people in the room and had the whole thing straightened up in under 5 minutes. That’s awesome.

And to add to this, as we left at the end of the day I asked if everyone could pick up their empty water bottles. After chatting with some folks I walked out and the entire auditorium was cleaned out. Not a water bottle in site. Now this may seem like two very small things, but this means the world to me. It shows respect for the venue and I appreciate it very much. Thanks guys!

I’ve had so much fun at the conference this year. I’ve fully enjoyed meeting new people and talking with everyone I’ve been able talk with. We have a wide variety of folks attending this year; from the mind-bendingly smart gurus to the total noobs. But everyone is getting along and helping each other become better. Not just better technically in regards to Ruby, but I honestly believe that we are helping each other become better people as well. There is a great vibe here, I wish everyone could experience it.

I know we set the bar pretty high last year, but I think we on our way to being even better this year.

IronRuby + C# = Awesomeness

2008-03-10T00:00:00+00:00

Saturday I gave a session at the third Boise Code Camp. Boise is my home town, so I am always happy to get back and enjoy the nostalgia. The Boise Code Camp this year was huge! As of Saturday morning there were 495 folks registered to attend, and 370 that were actually there. Crazy. Much props to the folks running it this year. Having helped organize the first Boise Code Camp and organized both MountainWest RubyConfs I know how hard they worked to pull this off. Great work guys!

Here are some of my notes for my session. I use a modified Takahashi Method of presentation, so my slide deck doesn’t make much sense by itself. Also, I only gave three demos, and the code was really simple because I can’t type and talk at the same time. Another reason for limited demo code is that alot of these concepts are new to folks so I wanted to go slow and make sure I brought everyone along. Disclaimer finished, here is the slide deck and the code. (Watch for the random Spider-Man appearance.)

Can a Computer Language be Beautiful?

I believe that software developers tend to create an exclusive culture around their technical knowledge. Most think that you need to “earn” your knowledge, and will respond to naive questions with answers such as “RTFM” or “Just Google it”. While this is understandable I think this attitude hurts more than it helps in the long run.

Seeing as the majority of sessions are Microsoft-centric, I kept my observations to Microsoft technologies. I’ve got my own path through Microsoft technologies and really came to my own on “classic” ASP. ASP and COM were a great leap forward for web programming compared to what we were using before, but it was typical to end up with spaghetti code. The introduction of .NET was seen as a solution to ASP’s “loose” code, but it came at a cost of restricting how expressive our code could be, making beautiful code more difficult

It shouldn’t come as a surprise that Ruby folks refer to Ruby code as “beautiful”. This is one of the things that I really love about the Ruby community. Ruby’s notion of Object Orientation is fundamentally different that C++/Java/C#. And Ruby’s meta-programming enables you to place responsibility where it belongs, and write expressive code by avoiding the accidental complexity typical of static language. This is why I like to think of Ruby as beautiful.

I gave the example of trying to enable sorting of domain objects in a DataGridView control, because that just happened to come up yesterday. The .NET solution is to inherit from BindingList and implement 4 properties and 2 methods. The Ruby solution is to simply call the array’s sort_by passing a block of how you want the item’s sort value to be calculated. My point being that Ruby code tends to rely on on the trust of the developer, while there is no way to quantify that trust in statically-compiled C#.

What is Polyglot Programming?

Another term for “Polyglot Programming” can be “Language Oriented Programming”, or using the right tool for the right job. I asked the folks attending if their language is right for their task, and a few responded that they thought C# was indeed the right language. I countered by putting forth my opinion that unless it is a domain specific language it probably isn’t the right language. DSLs can express the domain instructions without all the cruft or implementation instructions. I’m not sure how well this was received, as most seemed skeptical.

I also soap-boxed a bit about some developers defending C# to their dying breath, and the irony that the CLR was intended for multiple languages. Then I went into my belief that static languages are not the future, and in 5 years we will be using a dynamic language for the majority of work we are using static languages for today. You can read more about my thoughts on this here and here and here.

But I don’t believe that C# will or should go away. C# will still be the best language for system-level coding, because it is so aligned to the CLR. What I do believe is that we will stack dynamic languages on top of the static languages, and DSLs on top of the dynamic languages. You can hear more about this in my Rubiverse Podcast with Ola Bini.

What can IronRuby do now?

IronRuby is not complete and therefore not 100% compatible with MRI. But, there are some great things that we can do with IronRuby today. I gave four examples of how we can use IronRuby now. I didn’t have a demo for the testing though, I ran out of time.

Calling and using .NET objects from IronRuby
Replacing tests written in C# with tests written in IronRuby
Replacing application code written in C# with code in IronRuby
Provide Scripting in Application

The Blizzard of 2008

2008-02-14T00:00:00+00:00

Please excuse this non-geeky post, but today was harrowing and quite the tale. We came home from my grandmother’s funeral yesterday. We drove from Boise, ID to Cedar Hills, UT. The trip usually takes five hours, but yesterday it took nine due to major road work at Ogden, and a complete freeway closure north of Salt Lake City. My wife was scheduled to work the evening shift at the hospital that night, but the delays were too much and she didn’t make it in. Also, you can imagine how unhappy our two young girls were from sitting in the car for so long.

Today, we got the worst winter storm I have ever seen. On the way home from appointments in Salt Lake City, my wife and two girls got stuck in huge traffic jam due to the snow storm on the road home. This was just a couple miles from my work, where I was not allowed to leave because of the storm. I became increasingly worried, even more when my wife tried to turn around and got the car stuck in a snow drift. For two hours my little family was stuck and the girls became increasingly stir crazy while strapped in their car seats. Fortunately someone was kind enough to gently nudge our car out of the drift and my family was able to find shelter at a nearby hotel.

My wife called work to tell them she couldn’t make it to work again. I was not able to get to them to watch our daughters in time for her to leave. And her scrubs were at home where she could not get them. And the freeway was so backed up it would take hours to get there, if at all. What are the odds of being unable to make it to work on consecutive nights for entirely different reasons?

Two hours later we were told that we could leave the plant heading away from the hotel where my wife and daughters was staying. I decided to take the chance and leave in hopes of reuniting with my family. The doors of the plant were iced over to the point you could not see through them.

Here is the view of the sidewalk out of the plant. The sidewalk is covered with little rolling waves of ice from one to two inches thick. Although it was slick there was enough traction to walk on it.

As I was walking to my truck I was battered with wind gusts upwards of 50 mph. It was hard to keep my feet under me as I crossed the parking lot. As I got to my truck, I scrapped an inch of ice off my side-view mirrors. I have never seen anything like it. Sitting in my truck, the wind battered it back and forth as if an angry mob was trying to get me to leave.

Visibility was low as plumes of snow and ice blew across the roads. The images captured by my iPhone do not capture the blowing snow and ice as well as I’d hoped.

I was eventually able to leave the plant traveling at ~5 mph. Even at that speed, I almost slid off the road twice and slid into the truck in front of my once.

Eventually I was able to escape the worst of the storm, and then traveled across the valley, where I picked up some food, and then headed back towards the hotel. As I passed under the freeway I could see lines of cars and trucks just sitting there, like a very narrow parking lot. I was on the road three hours to get to the hotel. I was in bumper to bumper traffic most of the way. Eventually, I was able to break off to some back roads and arrived at the hotel.

The hotel is filled with people trying to get rooms. The lobby is filled with folks tired of waiting on the freeway and deciding to cut their losses. We overheard discussions of folks spending two, three, and four hours stranded on the freeway.

Since the girls were now asleep in the hotel room, and the lobby was so full, my wife and I decided to eat our dinner in the only other logical place: the bathroom.

The Winter Storm Advisory was supposed to end at 10:00 PM tonight, but has been extended to 5:00 AM tomorrow. Right now I’m not sure if I will be able to get back to work or even get home in the morning. But I’m very happy to be with my family and thankful we are all safe.

Update: We made it home this morning and I made it in to work. I saw many abandoned cars and trucks off to the side of the road buried in snow. The road my family was stuck on was still closed this morning. I’ve heard news reports that there were also elementary school buses stuck for hours on that road, and the children were eventually brought back to the school where they stayed the night.

What I Do

2008-01-06T00:00:00+00:00

I don’t like talking about myself much, I’d rather talk about how to do stuff or what I think the best way to do said stuff is. But Chad Myers “tagged” me in his What I do post. Its been so long since someone used the word “tag” outside of metadata and folksonomies that it took me a while to realize he meant it like the schoolyard game tag.

My Day Job

During the day I spend my time at IM Flash where we make the NAND that makes your cell phones and mp3 players go. My title is “Software Engineer” and I work in the group that supports the engineers. We support a metric ton of systems that help the engineers keep track of the manufacturing process. Most of these systems involve schlepping data from one system to the other. We collect data from the tools, process the data, report on the data, move the data to centralized systems, report on that data again, etc… Some of our systems are 3rd party, but most are homegrown. I end up doing my fair share of Perl on Linux and Solaris, as well as WinForms and ASP.NET apps in C#. We also have a nice backlog of VB apps as well, but we aren’t much of a Java shop.

When I’m not helping to keep the ship running, I actually get to do a bit of development. I am also the site’s IT architecture oversight representative, although it probably isn’t as fancy as you’d think. I participate in a variety of groups, both on site and around the company. I run a fun little group called TechShare, where we meet weekly and watch interesting videos and screencasts to help us improve as developers. I am also the self-proclaimed Agile and Ruby evangelist, and I’m sure everyone is tired of hearing it from me. When I’m not providing support or new development, I generally try to help improve things as much as I can.

My “Contribution”

I don’t consider my time at MountainWest Ruby, LLC a job, per se. I suppose I should as it is a real company, but I don’t take a salary and everything we do is to promote the Ruby language. MountainWest Ruby is the organization that hosts the MountainWest RubyConf, which is coming up March 28-29. MountainWest Ruby is a fun thing to be a part of, as I get to meet and interact with alot of really interesting and smart people that I probably wouldn’t have the opportunity otherwise.

While we have a handful of folks involved with MountainWest Ruby, I think it would be fair to say I do the majority of the behing-the-scenes work. Pat Eyler is the public face of the conference, and he and I work very closely to make sure we act responsibly toward the community. I like to think that the community has entrusted us with their money, so I am very conscious where we spend it. Some might say I’m too frugal, but we operate on a shoestring budget so I feel I need to be.

One thing I can say is that I love the Ruby community. It is by far the nicest and most giving online community I’ve ever been a part of, and I’m humbled that I get to be a part of that in some small way.

My Night Job

Forgive me for the shameless self-promotion, but I have been known to moonlight on Ruby, Rails, or .NET projects. My little one-man company is HumaneCode. I’m not actively seeking work at the moment so the website is embarrassingly bare. I’m sure you’ll understand.

Other Stuff

I’ve got more going on as well. I do a podcast about Ruby called Rubiverse that is alot of fun. I try to be active in the ALT.NET community as well, and hope to grow a local group.

My Family

My family is supremely important; I have a a wonderful wife and two beautiful little girls (with one in the oven). Without getting too personal, the past year has been hard for us. What I will say is the our trials have brought us even closer.

I know this list seems like alot of stuff, but it all pales in comparison to the importance of my family. My wife has been very gracious to allow me to follow my interests and take chances. Without her and the girls it would be meaningless.

Who Next?

It seems implicit in this meme is to pass the pain along. Fortunately, there isn’t isn’t a set number I have to inflict, so I’ll just choose the two following.

Luke Melia – Because I’m curious about what he does next.
Joe O’Brien – Because I find his business fascinating and I want to know more.

A brief history of Ruby on .NET

2008-01-03T00:00:00+00:00

John Lam recently responded to a post by M. David Peterson about the differences between Ruby.NET and IronRuby. A few months ago Dr. Nic (inadvertently) made it seem like the two projects are at odds. Afterwards the Softies on Rails guys seemed to question Microsoft’s interest in Ruby and were disappointed with Microsoft’s “lack of support” for Ruby.NET. There seems to be some confusion about the relationship between IronRuby and Ruby.NET. Implicit in some online conversations about IronRuby and Ruby.NET is a distrust of Microsoft doing the right thing in regards to Ruby. I’ve read many statements that imply Microsoft is trying to kill Ruby.NET. I’ve also read that Microsoft is trying to kill Ruby! So for all those that haven’t been following Ruby’s adventures on Microsoft’s .NET framework, here is a (very) brief history as I remember it. Corrections are welcome.

NETRuby

Actually, Ruby.NET wasn’t the first Ruby implementation on .NET. Sure, there were Ruby to .NET bridges like John Lam’s RubyCLR and SaltyPickle’s Ruby/.NET Bridge before, but there was also an actual port of Ruby 1.6 to .NET by arton. This project was called named NETRuby and it was a straight port of the Ruby C code to C# in 2001. I think I got it working on some small things, and I found the code pretty interesting. But the effort eventually died from lack of attention and/or need, as it was started and abandoned long before Rails was born and brought so much attention to the Ruby language.

The First IronRuby

Another early Ruby on .NET project was Wilco Bauwer’s IronRuby project. Wilco based his implementation on the IronPython implementation. Although the current IronRuby project shares the name, the two projects don’t share any code. I don’t believe Wilco ever publicly released the source code for his implementation. I do remember playing with the compiled version he released, but it was far from complete.

Ruby.NET

Around the time that Wilco was talking about his IronRuby implementation, the Queensland University of Technology folks announced that they had received funding from Microsoft Research to implement Ruby on the .NET Framework. I remember that Microsoft was just starting to show more interest in dynamic languages, due to the success of IronPython and the sudden and overwhelming emergence of Ruby (largely because of Rails). Ruby.NET’s runtime involves creating wrapper objects for the .NET objects to implement all the Ruby-ish features. This is a very common approach for implementing dynamic languages on a static language runtime. The early work from the Queensland guys resulted in code drops every six months or so. As the project has matured the releases became more frequent until the code was eventually put into a public subversion repository on Google’s service.

The Current IronRuby

Microsoft’s investment in Ruby.NET was rewarded when John Lam joined Microsoft to implement Ruby on the yet to be announced Dynamic Language Runtime (DLR). The DLR sits on top of the CLR and allows IronRuby to add Ruby-ish features to the .NET objects without creating proxies. The DLR also allows different dynamic languages to interoperate in the same way that languages such as C# and VB.NET can interoperate on the CLR. For legal reasons John’s team can’t look at the original C implementation of Ruby (you can listen to my Rubiverse podcast interview with John for the details to why this is), but was able to license and look at the Queensland implementation of Ruby.NET. John’s team was also able to use parts of Ruby.NET to more quickly stand up IronRuby. Although it seems that the parts of Ruby.NET in IronRuby are scheduled to be replaced in order to provide better future integration with the Visual Studio IDE. So that’s is. The efforts are dramatically different in their implementation, and address different needs. I see them both as complementary, and having a similar relationship as the one between JRuby and XRuby.

The Failure of Static Languages

2007-12-19T00:00:00+00:00

So, Bertrand Le Roy left a comment on my previous post calling me out for saying, “static languages have failed”. I think I need more space than the comment field to make a full reply, so I’ll do it here with a sensational title to gain the maximum attention. ;)

I usually enjoy reading your blog but wow. “Static languages have failed”? Just wow. Don’t you think that viewpoint might be just a little myopic?

Like I said in my comment, I hope this view isn’t myopic. The last 20+ years have been dominated by static languages like C++, Java, and C#. I believe we are in the midst of a dynamic language revolution and I expect the landscape to look dramatically different in 3 to 5 years. I’m talking about the entire IT landscape, not just the .NET or J2EE landscape (although they will look different as well).

My point isn’t that static languages aren’t useful and won’t continue to be used. But they aren’t where I believe the majority of development will be done in the future. Just as you would build a departmental client app using VB instead of C++ 10 years ago, you will be using a dynamic language instead of a static language in 3-5 years.

Because they don’t work for you or for the microcosm you’re hanging out in doesn’t mean it doesn’t work for the rest of the world.

My point is that static languages don’t work for you! Creating an interface just to run a unit test is a sign (to me) of a weak language. The existence of so many design patterns and anti-patterns are also a sign (to me) of a weak language. There are and will be better languages that allow you to get your work done faster while being more maintainable.

Static languages have been and continue to be very successful. Maybe it would be a little more productive to recognize the merits of each side before making definitive judgements like this one.

I don’t mean to take any thing away from static languages like C# and Java. Hell, I program in C# every single day. Well, every work day. And I certainly don’t hate C#, but I don’t love it like I love Ruby. I think I’ve been a good soldier in the static camp long enough to make up my own mind and voice my opinion. I don’t do so out of ignorance.

It might also help the dynamic language world to recognize major advances in language design (which imo Linq is) so that they can incorporate similar concepts in their own favorite technology.

I know many folks have been excited by the prospect of using LINQ from IronRuby. But honestly I don’t know how to take advantage of LINQ from IronRuby. If you have your local objects, you can already iterate and .map() or .collect() on them. And there are already ORM and data access libraries that will use a DSL or take a closure and query your data store. Jim Weirich recently discussed building such a library at RubyConf.

LINQ looks to be very useful and a huge win while working in C# and VB.NET. But I don’t need that in a dynamic language like Ruby because I already have those facilities. So I don’t see LINQ as a major advance in language design.

One thing that can be said from the C# team (which from our own microcosm looks very very far from “desperate”) is that they know how to keep an eye on the other side and incorporate what looks interesting, while not compromising the integrity of the language.

I didn’t mean to imply that the C# team is desperate, just that the language is trying hard to stay relevant amidst the dynamic language onslaught. There are alot of reasons why I’ll do my best to stay on the .NET platform, but I can’t say the same for C#. From the beginning the CLR was designed to support multiple languages, so I’ve always found the staunch defense of C# confusing. Particularly amongst the Alt.NET crowd, but that’s a topic for a different post. :)

In that respect, anonymous types capture an essential aspect of dynamic languages while remaining strongly-typed (and thus keeping IntelliSense working).

I think there is the perception that you can’t get IntelliSense©™ or performance with dynamic languages. You certainly can. We might not be there 100% just yet, but we will get there. NetBeans and Komodo and Ruby in Steel are good examples of Ruby IDEs with autocomplete.

You might also want to consult the documentation for anonymous methods, which do capture surrounding local variables (since 2.0), which in my book is pretty much what a closure is.

Great point! Anonymous methods are definitely closer to closures than anonymous delegates. But the point I tried to make about anonymous delegates wasn’t about local variables as parameters; it was about accessing private class variables. Once you replace the delegate you lose the ability to access private class variables.

Don’t want to look aggressive or anything, sorry if I did, not my intention. Keep up the good work and the provocative thinking.

No way man, I appreciate you wanting to engage in a discussion about this! There are a couple more points I want to make to clarify what I’m trying to say but didn’t fit well in response to you comment.

I say static languages have failed because the features we are looking for in future languages are at odds with static typing. For example, static languages achieve polymorphism through inheritance (or implementation of an interface) instead of duck-typing/composition/parametric polymorphism. So you have an explosion of interfaces when you want to test your code. But those interfaces aren’t for reuse as much as they are for testing. They don’t really help the reason your code exists, just your test cases. You end up with all that code cruft adding little value because static languages achieve polymorphism through tightly coupling implementations. Meanwhile Ruby promotes object composition over class inheritance.

My problem with the Rubification of C# is that C# has incorporated some of the aspects of Ruby, but not the real power of Ruby. Its all sugar and no meat. OO in Ruby or Smalltalk is very different than OO in C# or Java. I’ve had many discussions where other developers have said they are a better C++ or Java or C# programmer because of the time they’ve spent with Ruby. That isn’t because of Ruby’s syntax, that is because of Ruby’s fundamentally different understanding of objects.

Am I right or am I wrong? Please let me know. You can either leave me a comment or send me hate (or fan) mail.

The Rubification of C#

2007-12-18T00:00:00+00:00

Chad Myers gave me a nice little surprise by using my surname in his blog post “Moore on the Anonymous Delegate Approach” about an approach to make his statically-typed C# code more easily testable. I struggled with how best to respond because the subject of his code experiments really demonstrates some of the things I’ve been thinking about C#’s evolution for a while now. So while this isn’t a direct response to his post, its something I’ve been wanting to say for a while now.

Chad started out by showing how you can use anonymous delegates to encapsulate your logic, and then swap out the delegates in his test cases so he can verify the dependent objects work properly. So he is essentially swapping the implementation of the code his object has a reference to. The fly in the ointment is that only the original anonymous delegate can access all the internal data in his object, so once you swap out the object’s original anonymous delegate, the object becomes ineffective. (Unless your logic is dead simple, like the kind you use when you are writing code demos.)

The thing I really like about Chad’s code is that he’s getting really close to using anonymous delegates as closures, and I really love closures. I believe if Microsoft would (or could) add closures to the C# language (and idioms) that C# would be better for it. But closures aren’t embraced by C#. I understand that he is finding new ways to solve the testability problem with static languages, and while I enjoy his ingenuity, I’m starting to think that C# is moving too far from what it is. My concern is that as C# tries to be all things to all people, it simply stops being as useful.

Coincidentally, Tim Bray posted his thoughts on adding closures to Java yesterday, and he said many of the things I’ve been thinking about in regards to C# and Ruby. The only caveat I’d make on applying Tim’s thoughts to C# and .NET is that Java Generics != .NET Generics. Essentially, C# is an 80% language, and I’m totally okay with it. Ruby is also an 80% language, although a much different 80%. Making C#’s 80% overlap overlap Ruby’s 80% as much as possible seems kinda wrong.

Tim’s favored approach to improving Java is to work on a multi-language VM, not the core language itself. .NET is already ahead because it has facilities for interoperating multiple languages. Therefore I don’t think we should focus on improving C#, but we should start focusing on using the right tool for the right job; meaning the right language. Don’t get me wrong, I appreciate the fact that C# is taking on many Rubyisms in an effort to improve. But C# will never be Ruby, and really it never should. My hopes are that the DLR enables C# and IronRuby to not just co-exist but integrate well.

In this Channel9 video Robert Martin and Chad Fowler discuss dynamic vs. static languages at JAOO 2007. You should watch this video now. In it, Uncle Bob was asked if he was excited about the new functional programming features of C#; specifically LINQ. His response? “I’m about as excited about that as I am about Fortran 95.” His point was that by the time the new Fortran was released he had already moved on and it was no longer relevant to him. That is certainly how I feel about C#; the more features they add, the more desperate it looks, and the less I feel like investing myself in it.

Static languages have failed. They aren’t dead, but they aren’t the future. You can only fight a language so long before its time to move on.

Why the kids don't like the RSS

2007-10-20T00:00:00+00:00

A couple days ago Cote asked “Is Web 2.0 the middle-agers web?” and today he asks if the kids like the RSS. The answer is obviously no; kids think blogs and RSS aren’t a big deal. Not to say that blogs and RSS aren’t useful or of value; just that their technical details aren’t important to the kids and their damn rock and roll music. I think that blogs, RSS, and to an extent even twitter succeed because they are geek tools.

Facebook and MySpace have found success by making the process of creating and consuming blogs and RSS content approachable by the vast sea of non-geek users on the Interweb. They, and other social networks of their ilk, have taken our awesome geek ideas and packaged them up in a seamless… package. Well, maybe not seamless, but they hide most if not all of the complexity and apparently by doing so have created billions of dollars of value.

Apparently value is added because those punk kids on MySpace don’t want the complexity of setting up NetNewsWire or Google Reader with their favorite feeds. Or, they have no idea what I just said and are incapable of doing so. They just want to go to a site, any site, and see what their friends are doing. And make the Internet a little bit uglier. Yeah, it doesn’t make much sense to me either but apparently the unwashed masses love it.

I like the prospects of using Facebook’s platform to build apps and make money, but I don’t personally like the idea of using Facebook. And I can’t stand MySpace. I’m more lenient about LinkedIn, but I think that is because I have delusions of actually getting work from it… some day… eventually. The reason I don’t like them is because they feel restrictive, and don’t work they way I want them to work. But I’m a geek and like all self-respecting geeks I have a strong opinion of how the world should work. And so far the social network apps just haven’t done it for me.

I like twitter and I like del.icio.us and I like Flickr. I like the fact that blowmage.com is the central hub for my online presence. I like keeping track with people through their blogs, and having public discussions on mailing lists. Maybe if I were 20 years younger I’d think differently, but what the hell do those whippersnapper know?

Getting RubyGems to play nice at work

2007-10-18T00:00:00+00:00

At work I’m on Windows and behind a proxy server. I recently wiped my workstation and started over. After I installed Ruby I found the gems command not working, again. The reason is that my proxy server requires a username and password, and open-uri doesn’t pass them. (Supposedly because keeping your username and password in an environment variable isn’t secure, but at work I don’t care as much about apps snooping my environment variables.)

To get things working I had to hack up open-uri a bit. So I found the following code in C:\ruby\lib\ruby\1.8\open-uri.rb

require 'net/http'
  klass = Net::HTTP
  if URI::HTTP === target
    # HTTP or HTTPS
    if proxy
      klass = Net::HTTP::Proxy( proxy.host, proxy.port)
    end

And I make the following change:

require 'net/http'
klass = Net::HTTP
if URI::HTTP === target
  # HTTP or HTTPS
  if proxy
    # Add proxy user and password to work with the proxy server.
    klass = Net::HTTP::Proxy(proxy.host, proxy.port, proxy.user, proxy.password)
  end

Then I create the http_proxy environment variable with the value of http://blowmage:s3cr3t@proxy:8080 and I’m good to go. Well, I have to log off and log back in for Windows to find and RubyGems to use the new environment variable. Oh, and be sure to create it as a user variable and not a system variable. :)

Ruby Blue Visual Studio Theme

2007-10-10T00:00:00+00:00

Now that I’m blogging again, and I’ve had a resurgence of .NET related posts, I thought I’d add to a meme I saw going around earlier this summer. First John Lam posted his Vibrant Ink theme for Visual Studio, then I saw Tomas Restrepo post his Nightingale theme.

I’ve always been a fan of John Long’s Ruby Blue TextMate theme. So I created my own Visual Studio theme (including the Monaco font) a long time ago and thought I should share it here. Feel free to fork my repo, improve it, and send me a pull request. Enjoy.

Will we ever get IronRuby on Rails?

2007-10-10T00:00:00+00:00

Last weekend the ALT.NET Conf I had a couple opportunities to plead my case for Microsoft to embrace the Ruby on Rails framework and better enable it on IIS. I believe IronRuby will eventually run Rails, and I believe when it does the community will implement whatever hooks are required to run Rails using the DLR on IIS. But I want more. I want Microsoft to stand behind Rails and encourage its use. I want an “official” deployment story for Rails using IronRuby and IIS like the one Sun has with JRuby. I was able to discuss this with Scott Guthrie himself at the end of Scott Hanselman’s DLR/MVC session, but I don’t think I changed his mind at all. Sorry guys.

Half of the resistance seemed to be that Rails was too much of a fad and a moving target. I heard ScottGu say on a couple of occasions that prototype.js was really hot last year, but this year everyone is using jQuery. I also heard him say that last year everyone was all excited about RJS, but this year nobody is actually using it. The implication seemed to be that the Rails community couldn’t make up its mind. But the reality is that the Rails community is having a conversation about how to build web apps better and it seems like Microsoft is either ignoring the conversation or blissfully ignorant of it. Neither is the case, obviously; but Microsoft has yet to join the conversation. In talking with ScottGu it became apparent to me exactly how well tuned in he is. He has obviously talked to enough Rails guys to have satisfied himself that Microsoft is making informed decisions.

The other half of the resistance to official support for “IronRails” is the giant mutex lock hanging around Rails’ neck. The implication with this one was that as soon as the Rails team fixes the threading model, then Microsoft can have something to work with to get a performant Rails on IIS. I wish I had a good answer to this. The JRuby guys appear to be working hard on improving performance of Rails on JRuby, and having success. Can something similar be done for IronRuby on IIS?

The third half of the resistance to Rails was that the Rails community is simply not interested in running on Windows in any meaningful way. Its been historically hard to get support from the community for the SQL Server adapter in Rails, and there has been very little activity on getting Rails running on the new FastCGI ISAPI filter on IIS. I don’t have a good answer for these things either. Personally, I don’t have permissions to the web servers at my work; so I can’t get FastCGI on the server because it isn’t on the roadmap. But this is exactly why I want support via the DLR; so I don’t have to have admin access to the server to deploy a Rails app because its all just .NET.

I disagree with ScottGu’s view was that the Rails community isn’t committed to running on Windows. I don’t think that is it exactly; I think the Rails community isn’t committed to running on IIS. Deploying Rails on IIS is more than just FastCGI; you also need a mod_rewrite replacement and there doesn’t appear to be any free solution for that. Simply put, its too painful to deploy on IIS and its much easier to deploy on Apache. Rails devs are usually pragmatic folks, and will go with a working solution.

But personally, I really want to build Rails apps. And I’d hate to have to not be able to do that on Windows and .NET. I have very high hopes for the new ASP.NET MVC framework, but I’d also like a commitment from Microsoft to the Rails community similar to the commitment made to the Ruby community. And honestly, I think it would be in their best interest long term.

ALT.NET Conf: Day 3

2007-10-08T00:00:00+00:00

Today was abbreviated with only two sessions this morning and then a combined closing session. I had a late start (again) this morning, and missed the opening comments (again). I know this makes me seem like the kinda guy who always sleeps in (and the guys I work with would definitely agree with that characterization) but I want to point out that a) I was very sleep deprived going into this weekend, and b) conferences like this are physically draining. There is so much mental engagement that it really does fatigue you physically. Really.

The first session I attended was about Mono. I haven’t looked at Mono in years, and I was impressed with what I saw. The Mono Migration Analyzer app (MoMA) was really cool. It essentially inspects your .NET *.exe and *.dll files and identifies what calls used are not available on Mono. This is a great idea, and apparently Mono’s compatibility was improved by the real world metrics collected through the tool.

I cut the session a bit short to catch up with my family, and when I returned the session had migrated next door to a discussion on why the MSDN magazine sucks and how to market the ALT.NET message. I don’t read the MSDN magazine (but I will if someone sends me a free subscription), so I don’t know if it sucks or not and didn’t have much to add. However, I think its a bit premature to focus so much on online community building and marketing. I kinda like ALT.NET being undefinable and using guerilla marketing efforts to build awareness of its ambiguity. It just seems more authentic to me that way. Also, I don’t see a message well defined enough to actively market. After all the current message is basically, “do what works and don’t be afraid to look to other communities to see what works there”.

The mid morning session was the assigned slot for my proposed “Dynamic Languages on the CLR” session. Last night Scott Bellware suggested that what folks would really benefit from was a real life Ruby on Rails demo using test first with RSpec, so I changed the focus of the session to “Ruby on Rails Demonstration”. Unfortunately Scott Bellware bailed on me (he had a scheduling conflict) and I recruited Luke Melia to pair with me for the session. Scott Hanselman attended and he started a really good discussion before we started writing code. There seemed to be alot of folks who either tried Rails, or knew someone who tried Rails, and were let down by the experience. There was this perception that Rails is so cool that you don’t have to understand what is going on under the hood. This is true for very simple, golden path apps; but very untrue for most real-world apps. Like anything in life, you get out of Rails what you put into it.

The Rails session seemed to go well and I had a couple folks thank me for showing them the approach Rails guys take to solve errors when coding. I really like live coding demonstrations where you don’t go in with a scripted plan. For instance, The video of the Jamis Buck and Marcel Molina, Jr. session at the MountainWest RubyConf is by far the most downloaded session of the conference. I hope I continue to see more and more of those types of sessions at future conferences.

After that all conference attendees poured into one room and one by one we all made comments about what we got from the experience. This was incredibly positive and was a great way to close the conference. This conference wasn’t so much about technology as it was focused on the individual. I was happy to be a part of it and I look forward to more gatherings and communications about the ALT.NET ideals, even if it is a big ball of mud at the moment. :)

ALT.NET Conf: Day 2

2007-10-07T00:00:00+00:00

The next day of the ALT.NET Conference started with me sleeping in and missing the opening announcements. So as far as I know there was an edict to not talk about Ruby. An edict that I bravely disobeyed.

The first session I attended was “Ruby for ~~Dummies~~ .NET Developers” and I volunteered to show my intro to Ruby slide desk. I originally built the desk for a ~90 minute presentation, so zipping through the desk in 20 minutes may have resulted in making the message come across a bit strong. But we had a really good discussion about what Ruby is and why Rubyists love it. I really emphasized the human oriented view that Rubyists have and that the Ruby language enables. Folks seemed to go back to the open classes feature over and over. I was really happy (and honestly surprised) when Roy Osherove later announced that he now gets why folks love Ruby and is excited about it.

The next session was BDD. It was held in the big room and there were alot of folks in that session. There was alot of showing BDD-style code, arguing, and pointing to the screen. It seems that everyone had a different view of BDD and nobody could express exactly what the benefits were to using it. I got kinda frustrated in this session because both philosophically and in practice BDD is great, but nobody could express that during the session. I wish we had a more formal presentation to frame the discussion around.

After lunch Scott Guthrie showed the new ASP.NET MVC framework. His main points for the framework were:

Separation of Concerns, Testing, Red/Green TDD, Maintainable By Default
Extensible and Pluggable
Enable clean URLs and HTML
Integrate nicely with ASP.NET + .NET; Support Static + Dynamic Languages

I was really surprised to see how well thought out the framework is, and how extensible and testable the code you can write in it can be. Throughout the demo he highlighted features that were inspired by web frameworks that real developers are using like MonoRail or Rails or Django. He also showed how it was designed to be testable using any of the current unit testing frameworks. Even more surprising that is uses the current ASP.NET stack, Provider model, Request and Response objects, .aspx/.master files, etc. The framework seemed to me to be a brilliant combination of idiomatic .NET features and the agile development practices espoused by open source web frameworks. You can see the video Scott Hanselman took of the demo soon.

As seamless as ScottGu’s demo was, Scott Hanselman’s follow up presentation on making the MVC framework use dynamic languages (via the DLR) showed the real pain that lies in front us to integrate dynamic languages into existing static code. For example, configuring and using IronPython in ASP.NET or the new MVC framework seems way more painful than it should. Scott showed the several changes to an older version of the MVC framework to use IronPython as both controllers and views. And Phil Haack (who wasn’t here) also did alot of work to use Ruby ERB files for the view using IronRuby. I’m excited that this work is being done, and I hope that the process will lead to a detailed white-paper on how best to integrate static and dynamic code.

I really liked what I saw with the MVC framework. I can easily see me easing on the fight to get my full-time employer to give Rails a try because the ASP.NET MVC framework will give me all I need and most I want to get my “real” work done. I’ll certainly not leave Ruby, but I will definitely be more active in the .NET world because of the ASP.NET MCV framework. So if convincing me to give .NET another shot was the Scott(s) goal; then mission accomplished.

Update: I ended the day with a pile of brisket at Rudy’s and some great conversation with some .NET dignitaries. I tried to get folks to show up for a coordinated hacking session where we will try to make the world better… but the bar seemed to be a bigger attraction for most. (The Ruby community would have combined those two activities…)

ALT.NET Conf: Day 1

2007-10-06T00:00:00+00:00

I’m at the ALT.NET Conference this weekend to gain a better understanding of where the .NET community is heading and to spread some Ruby love. The conference is using the Open Space format, which seems to be alot like a BarCamp. Although, since I’ve never been to a BarCamp I’m not so sure what the difference is. This seems to be more focused on interactions and discussions as opposed to presentations, so I suppose that may be the difference. Unfortunately there isn’t alot of information online about what “Open Space” is.

There are some really stellar folks in attendance, you can see the full list here. Roy Osherove is here, and he looks way different than I’ve always imagined in my head. I met Jim Newkirk of NUnit fame in the hotel lobby. Scott Hanselman is also here, and seems to be a bit defensive about a perceived (or not) anti-Microsoft bias. There are other folks from Microsoft here as well, including folks from the MSDN team. And Brad Wilson (who I just today realized isn’t getting my twitter replies because I’m not being followed by him) is here as well. Oh, and did I mention Scott Guthrie? Yeah, he’s here too. I was really surprised and happy to see him here, mostly so I can pester him over and over again that we want IronRuby on Rails support from Microsoft. And of course there is Martin Fowler.

Doc List started the conference by setting the expectations and demonstrating the fishbowl discussion technique by starting a discussion on what exactly “ALT.NET” means. This discussion is an ongoing topic on the blogs right now, so I wasn’t surprised that the discussion continued for a while. It even survived a couple attempts by Doc to kill it. In the end we don’t have any cleared definition for ALT.NET; but we did hear alot of opinions. This seems to me to be alot like the Web 2.0 discussions of a couple years ago. ALT.NET, like art, is hard to define but you know it when you see it.

Then we were given time to think up the topics we would like to discuss for the next couple days. When someone wanted to add a topic, they would write it down on a post-it, move to the center of the room, introduce themselves and the topic, and put the post-it on the board. We quickly had double the post-its than we have rooms and time slots for. There was some consolidation to the list of topics and eventuality we added our initials to the post-its we want to attend or be involved with.

Scott Guthrie added a note to discuss the often rumored yet unannounced MVC/Model2 ASP.NET framework. And Scott Hanselman added a note to discuss making said MVC framework work with dynamic languages via the DLR. The topic that got the most submissions seemed to be TDD, BDD, and DDD. I added a note to discuss dynamic languages on the CLR; specifically what folks are looking for from them and why some developers fear them. I also volunteered to present on the topic “Ruby for ~~Dummies~~ .NET Developers”. There was alot of topics and talk about Ruby and Rails, so I expect some good discussion. I look forward to tomorrow.

Afterwards, I took the opportunity to introduce myself to Scott Guthrie and promptly cornered him on what his thoughts were on the topics put forward. He said that it wasn’t all that surprising and that he was excited to present his new MVC framework. He said he thought it was a good blend of extendibility and “opinionated conventions”. It was a really fun discussion and we got a bit of a crowd at the end. I’ll hopefully record an interview with him tomorrow.

Scott Hanselman also floated around the room taking notes on what folks specifically thought was wrong with the current Microsoft toolset. There were some honest gripes, but it mostly seemed to be folks complaining about features that are most likely already in Visual Studio but are either buried in the UI or not as extensible as folks want. But I started thinking those discussions were missing the point of what I think the meaning of ALT.NET is. To me, ALT.NET is at heart the embrace of Agile by the .NET community and the recognition that the .NET community determines its own fate; not the toolset vendor (Microsoft). But the tools aren’t the answer; people are! The Agile Manifesto holds the following value: “Individuals and interactions over processes and tools”. My wish is that Microsoft would focus more on improving individuals and facilitating better interactions, but the heart of the matter is that the .NET community needs to do this regardless of what Microsoft does with its tools.

RailsConf 2006: Day 1

2006-06-25T00:00:00+00:00

Here are my notes from Day 1. The word of the day was “deployment”. One of the reasons I’m attending RailsConf is to be considered hip and influential by those around me, but the other reason is to learn how to better deploy Rails apps. It looks like I’m not alone, as many of the sessions seem to touch on deployment in some way.

Dave Thomas’s opening keynote kicked the conference off with a terrific look at three areas that the Rails community should address to help Rails continue to gain market and mind share: improve ActiveRecord to make better use of database features, improve scaffolding to make it usable and pretty for more complex models (kinda like TurboGears?), and improving deployment so that the various responsibilities in deployment can be delivered by more than one person. Not all developers have full access to their production machines, which is one of the areas Capistrano breaks down. Dave’s vision and common sense was on full display, and his message was simple: Rails needs to see wider adoption because all developers deserve to be happy.

Mike Clark’s Capistrano overview was excellent as well. And his session was packed. He presented the basics of Capistrano and showed real affection for it. Its too bad Jamis isn’t here to take the deserved applause for creating such a wonderful tool. I’m looking forward to attending more sessions about deployment.

As Bob Silva said, if you were stuck in the next session you know who you are.

I attended the Identity/OpenID session next. I didn’t realize it was a Verisign product. The first half was very much like Dick Hardt’s Identity 2.0 presentation, while the second half was a quick demo showing how easy it was to start using OpenID plugins in Rails. I’m very interested in offloading the user creation experience to a third party, but there seem to be many holes in OpenID that I’m not sure its worth it yet. But I did get a t-shirt out of it. :) Cote has an excellent review of the advantages and disadvantages of the various identity standards.

Geoffrey Grosenbach of the Ruby on Rails Podcast gave a great session on deploying to shared hosts. He covered some of the design choices you can make to fit better into the shared hosting model. He said what we were all thinking, that Typo wasn’t designed and for the most part isn’t a good fit on a shared host. (I’ve really got to get around to writing my way out of Typo.) He also covered some common configuration settings for Capistrano’s recipe files. Although he didn’t cover it, he did mention that some folks are using Mongrel in leu of FastCGI when running on Apache. He said that it wasn’t quite ready for prime time yet, but I’ll have to check that out.

Martin Fowler gave the first of two closing Keynotes. He just stood up there and talked. No slides. Martin is one of my heros, and one of the reasons I love being here is because I get to meet and chat with folks like him and Dave Thomas and Chad Fowler and … He spoke on what it is about Rails that interested him, seeing as he hasn’t ever actually used it. I see him as the surrogate grand father of Rails because of the influence his Enterprise Patterns and Practices book had on DHH when he was creating Rails. The name Active Record came from that book. I have lots of notes from his keynote that I will post separately.

Paul Graham also delivered his keynote without slides. He read a very good essay about how great ideas and innovation often come from the marginalized. In many ways it is an advantage to be an outsider rather than an insider. Here are a couple good quotes:

You’re on the right track when people complain you’re unqualified or what you’re doing is “inappropriate”.

Why and his band took the stage next and delivered a great show. This is the first time I’ve gotten to see the Thirsty Cups and it was everything I expected. Although I think there are a number of folks here who love Rails but don’t really understand Ruby and were lost during Why’s show. But maybe that was the point? Either way there was way too much in the show to give it proper coverage here, so I won’t even try. I can say that I look forward to see them perform again.

Ruby.NET Beta Announced

2006-06-22T00:00:00+00:00

They guys at Queensland University of Technology announced the public beta of their Gardens Point .NET Ruby compiler yesterday. Not only will it interpret and run Ruby files, but it will compile to .NET executables and assemblies as well. I got it to run on .NET 2.0 on WinXP SP2 and Mono 2.0 on Ubuntu (both running in Parallels on my MacBook Pro). I didn’t get it to run on OS X, but that is more to with the lack of an Intel version of Mono for OS X. (Meaning I didn’t try too hard to get it working on OS X.)

I skimmed through the Ruby.NET source code last night and I have to say I’m impressed. I’m particularly excited about Ruby.NET because I trotted down the path of building a .NET version of Ruby and have a good idea how challenging it was to get this far. I looked at arton’s older NetRuby effort code that was essentially a straight port of Ruby 1.6’s C code to C#. I looked at what IronPython does to take advantage of the 2.0 CLR. I was at Charles Nutter’s RubyConf 2005 presentation and familiarized myself with what his team has done with JRuby. After starting development on my own C#/.NET version of Ruby I found that I didn’t have the time to devote to such an effort. I’m very glad there is a viable solution now. I hope the .NET and Ruby communities rally around this effort.

I can’t wait to see if we can get Ruby to play nice Avalon/WPF like Chris Anderson has done with IronPython in AvPad. Perhaps we can someday (sooner rather than later) get a Ruby on Rails project fully compiled to an ASP.NET assembly and running on IIS? But what I’m probably most excited for is to be able to create DSLs using Ruby and use them in the .NET applications I write at work.

Now all we need is for an effort like Steel or Wilco’s IronRuby Visual Studio integration to properly use Ruby.NET within Visual Studio 2005. Then we’ve got our first class IDE support and all those naysayers who complain that Ruby will never see wide-spread corporate adoption can respectfully stick it.:)

Polymorphic Podcast on Object Thinking

2006-06-16T00:00:00+00:00

Craig Shoemaker of the Polymorphic Podcast has just posted part one of his interview with author Dr. David West about his book Object Thinking. Craig contacted me a few months ago about my review of Object Thinking and asked if I had any questions for Dr. West. Boy do I.

Here is the list of questions I sent Craig:

What is formalist thinking and why is it bad? It seems like such a good fit when dealing with computers.
Why is OOP/object thinking so hard to get right? Besides making everyone read your book, how can help change a formalist culture to object thinking? Not just an individual’s understanding, but the culture as a whole - like a corporate IT culture.
Where are the future object thinkers coming from today? Methodology? (Agile? XP?) Languages? (Ruby? Python?)
Are programming languages important? Where are we in regards to object-oriented languages? What is missing? Where do future languages need to go? Is formalist thinking reflected in language design? (I believe so.) What are the best examples of hermeneutic languages?
How did you end up with Microsoft Press as a publisher? The book was Microsoft-agnostic, and it seemed like a strange fit to me.
(Unsure about this question) Was the book successful? How was it received?
What is Dr. West doing now? Teaching? Research? Slinging code?
Does he have a blog? If not, why not?!? Seriously, he needs a blog! He is depriving the work of much needed object thinking by not having a blog.

Get the podcast here!

Agile Databases

2006-04-28T00:00:00+00:00

I am not an expert on this subject, although I play one on the Internet. Jason posted some thoughts about the relatively light use of the data tier in a recent TDD presentation he attended. Instead of writing the longest comment in the history of his blog I thought I’d post my response here. The following is a brain dump only, and subject to change as folks smarter than me correct me.

Martin Fowler has an article where he distinguishes between “application” databases and “integration” databases. To me this is the main difference between traditional “enterprise” thinking and the Agile approach. Most Agilistas (and the Ruby on Rails framework) like the “application” view, and every DBA I’ve ever known assumes the “integration” view. Here is what Martin Fowler has to say about the latter:

Integration databases end up with interfaces that have a large surface area and limited abilities to separate interface from implementation. The resulting links between applications and databases end up being brittle and thus difficult to change.

That perfectly describes my life.

I can’t point to too many examples where I’ve actually reused stored procedures. Database functions yes, stored procedures no. I either end up writing new stored procedures for my new application, because the new application needs to access the data differently, or I hack up the stored procedures to do things they weren’t originally designed for and effectively tightly couple my data and application tiers. In fact, my opinion is that the current irrational exuberance over SOA is mostly an acknowledgement of the fact that stored procedures make a shitty abstraction layer. But that’s just my opinion, and unlike Erik Larsen I’m not that willing to concede I might be wrong. :)

Rails takes the view that you should have your complexity in one place, and code is a much nicer place than the database. That is one of the reasons Rails is called “opinionated software”, because this world-view permeates the framework. Can you use Rails with an “integration” database? Sure, but it will be harder. And even though I have no idea exactly what SOA really, truly is, I’d investigate using SOA before strapping Rails on top of a legacy database where stored procedures are the only way to get or set data. So the “application” database approach is different, but its different for a reason.

Ruby and Thought Leadership

2006-04-27T00:00:00+00:00

Don Box may be a few weeks late to James Gosling’s comments about Ruby, but he does pay Ruby a nice compliment. He says:

“Ruby has the language thought leadership position…”

In the comments Don implies that Ruby will overtake Java once Ruby gets a first class IDE. I think the Java community can rest easy, I don’t see that happening for a long time, if ever.

Oh, and one more thing, I agree with Don that .NET is slightly less vulnerable to Ruby than Java, but by only a fraction of a percent. Why? Because Ruby does have thought leadership. I gave a presentation on Ruby and Rails to some developer evangelists at Microsoft a few weeks ago and I tried to make that point crystal clear. Perhaps that first class IDE support should come from Visual Studio 2007?

Boise Code Camp Wrap-up

2006-03-21T00:00:00+00:00

The first Boise Code Camp was this past weekend. It was very well received and turnout was higher than we were expecting. Congratulations go out to Jim and Cory who were the main local leads for the camp. And special thanks to Jason for presenting the idea to us and putting Microsoft’s considerable weight behind the event.

I presented sessions about Ruby and Rails. The Rails session went very well, mostly because I stole half of the session from Jim Weirich’s A Quick Introduction to Rails talk. :)

The earlier Ruby session didn’t go quite as smooth though. I’ve been struggling for the past two months on how to present about Ruby in 60 minutes. So much of what I love about Ruby are the subtle little things that Ruby does. I felt that you can’t really show those subtle things until you explain where Ruby came from, the structure of the language, and how Ruby scripts are executed. Oh, and I was up almost the entire night before trying to solve a technical issue in my demo that I actually didn’t ever get to. So I was very tired on top of a dry presentation. But the good news is that I learned from my mistake and the next time I present on Ruby I will be better prepared and more coherent. I promise.

I’ve taken the last couple days to recover and I’ll post the slides and code samples later this week. Thanks to all that attended, it was a great time and I felt that the event was a tremendous success! We hope to make the camp a regular event in Boise. I hope that some who attended my sessions will consider joining the local Ruby user group as well.

Ruby Thinking

2006-02-17T00:00:00+00:00

I attended the local .NET user group last night and had a few people approach me about Boise Ruby Brigade (The first meeting is next week! Sign up for the mailing list today!). In answering their questions about Ruby, I shared the fact that Ruby is a ‘type-less’ language. You can take a variable and make it hold an integer, and then make it hold an array of strings. Not that you ever would, but the point is that you could. I said this to get them thinking about the implications. Not surprisingly the discussion engendered some fairly strong “but I like my static typing!” reactions. With this contrast between Ruby and the languages developers are currently using, I started to explain why this isn’t such a bad thing and pointed out some of the benefits of such a language. I made a claim I’ve made several times before, but not here yet: “In five years half of all new code we produce will be written using a dynamic language”. I said this at a .NET user group, as a professional .NET developer.

I readily admit this is a bold statement, especially for those for whom dynamic languages such as Perl, Python, and Ruby aren’t even on the radar. But I stand by my prediction. It is an obvious one to me, considering that both the .NET runtime and the JVM are adding more and more dynamic capabilities. The discussion eventually degraded as one individual took issue with me and got a little upset about the merits of dynamic languages vs. static languages. He would not concede that dynamic languages can be a better solution for certain applications, much less become convinced that it was a better way of programming. It was then that I realized I wasn’t dealing with a static-typing bigot. I was dealing with a formalist thinker.

In my review of “Object Thinking” I outline Dr. West’s definition of formalist and hermeneutic thinking, and how it compared to computer thinking vs. object thinking. Dr. West obviously advocates that we embrace object thinking and shun computer thinking, and outlines the benefits of such a world-view. It is an eye-opening book and I recommend it highly.

The conclusion I’ve come to is that the C-based languages like C# and Java typically bias our thinking about programming. You need to understand how a computer runs code, but you also need to develop the discipline to divorce yourself from thinking that way when designing software. But this is hard to do because the environment reinforces the computer way of thinking with their structures and base libraries. To borrow from Martin Fowler’s article on Humane Interfaces, take this example for getting the last element of an array:

C#:

anArray[anArray.Length - 1];

Ruby:

anArray.last

In C# and Java you have the C heritage of accessing variables by shifting your pointer to the correct memory location. In Ruby you simply call the appropriate method. In other words, the C#/Java approach is Implementation-specific, while the Ruby approach is Intention-specific. The difference between the C#/Java and Ruby approach is permeated throughout the base libraries for their respective environments. It is more difficult to write a Ruby-like library in C#/Java because it wouldn’t behave like the other C#/Java libraries. And while you can write a C#/Java-like library in Ruby, the longer you use Ruby the more you start thinking the Ruby way. Ruby does this by making it so easy to stop thinking like a computer and start thinking like a human being.

I suppose that what made this individual upset was that he worried that Ruby’s simplicity and power would make him obsolete. As if by suggesting that Ruby code was more readable and understandable that the programmer was not needed and that the source code could be put in the hands of end users. Ruby is not a toy; Ruby is a tool to make programmers more productive. It makes programming easier. And I believe you can be happier when using Ruby because it gets out of your way. Ruby makes my life easier because I can focus on getting the job done and not talking to the computer or compiler. That’s why I like Ruby.

Boise Ruby Brigade

2006-01-27T00:00:00+00:00

Well, I finally did it. I started a user group for Ruby. I’m very excited about it, and I hope those who attend will be half as enthused about it as I am.

I expect that the Boise Ruby Brigade (boise.rb for short) group will be two parts Ruby, two parts Rails, and one part Agile.

Check out the site here: http://boiserb.com/

Who killed Web 2.0?

2005-10-08T00:00:00+00:00

This has been a difficult week for me. I don’t know how it happened, but somehow this week at the Web 2.0 Conference (of all places) Web 2.0 died.

Before this week I advocated for the notion of “Web 2.0” to those around me. Even with all the confusion over what exactly the title meant, I liked the title because it conveyed the new promise for the Web. (And it was certainly better than the title “Semantic Web”.) After the dot-com bust and the painful years that followed, the importance of the Web was diminished. The Web lost attention and respect. And this was our own fault; we got caught up in our own self-importance and greed. Web 2.0 was a turning point; it was our chance to do it over, to do it right. It wasn’t about technology as much as it is about fulfilling the original promise of what the Web should be.

We had a pretty good start too. Web services showed that Internet technologies were still innovative and that XML was useful for something other than configuration files. Google reminded us that the Web enables people and not technologies. Google also taught us that you can succeed by doing one thing and doing it well. Syndication feeds changed how users receive and view your content. AJAX showed you can be creative while building upon mature technologies. All this was happening because of people who believed in the promise of the Web post dot-com crash.

But then suddenly we lost our minds. We changed the notion of Web 2.0 to be something that it can’t be. We started using Web 2.0 as another item on our feature list. We started promoting Web 2.0 as a project management methodology. We started promoting Web 2.0 as a business plan. And although I didn’t attend O’Reilly’s “Web 2.0 Conference”, most of what I’ve gathered from the blogosphere is that the conference was little more than a bazaar for newly-minted start-ups to hype themselves as if we were in the throes of the dot-com bubble. We corrupted ourselves again and tarnished our ideal, and for what? A shot at some new VC cash? A handful of links from the regular bloggers?

Starting this week I hate the term Web 2.0. Now I have to go back to my job and just code. There is no greater good, there is no larger vision. Its just technology. You’ve killed my idealism. Again. Perhaps this was all my own fault for wanting to believe again. The more I think about it, the more Nicholas Carr is correct in his essay The amorality of Web 2.0 where he states that those who view the Web in religious terms can “no longer see it objectively”.

Coincidentally or not, this week I’ve been viewing the presentations and listening to the podcasts from last week’s Web Essentials 2005 conference in Sidney, Australia. I was originally looking for broadcasts of the Web 2.0 Conference sessions, but apparently the principle of “transparency” only applies to Web 2.0, and not it’s conferences. I can’t shake the thought that the Web Essentials conference is what the Web 2.0 Conference could and should have been. I encourage everyone to give them a listen. If anything, it washed the bad taste out in my mouth left by the Web 2.0 Conference.

Web 2.0 is dead, long live Web 2.0.

Book Review: Agile Web Development with Rails

2005-09-30T00:00:00+00:00

Ruby on Rails is a framework that makes it easier to develop, deploy, and maintain web applications.

Agile Web Development with Rails on Amazon

Dave Thomas and David Heinemeier Hansson wrote a killer book in “Agile Web Development with Rails”. I wish more technical books would be as reader-friendly and enjoyable as this book. While the book isn’t a reference book, it isn’t a brain-dead newbie overview either. It covers all of the important technical aspects of the Ruby on Rails framework from design to development and from installation to deployment. It also does a great job of explaining the philosophy behind Rails, and why Rails makes the assumptions it does. (Don’t worry, it also shows you how to configure Rails to use your assumptions if they are different.) Overall, the book is a first-class introduction to the body and soul of the Rails framework.

The reason I read the book was to really understand the Ruby on Rails framework. I have dabbled with Rails for the last nine months or so, ever since I first read about Curt Hibbs’s claim “that that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework”. Rails seems simple enough when you first approach it, but there is surprising depth once you scratch the surface. So like most things I don’t fully understand right away, I decided to find some books on the subject. This book was so good I’m not sure if I’ll need any others.

Rails is a new framework for building web applications using the Model-View-Controller pattern, similar to most Java-based web apps. Unlike Java web apps which are usually heavy on configuration, Rails follows the philosophy of “don’t repeat yourself” and “convention over configuration”. This means that Rails is built to improve the time of development. But the promise of Rails to me is beyond making me more productive, once you become familiar with Rails and accept the conventions you will get more done while having more fun in the process.

I think Rails has the potential to be a disruptive technology for web development. As more users become familiar with and expect Web 2.0 functionality web sites will be forced to change in order to deliver the new standard for usability. Web designers and developers will look to new frameworks such as Rails to help them achieve this functionality. Does this mean that Rails will lead the way to a new utopian world where proprietary frameworks like .NET and J2EE are abandoned, PHP is dethroned, and Rails becomes the de-facto standard for modern web development? Probably not, but I do think that Rails does show just how much everyone else will have to evolve or face extinction. To an extent, I think we are already seeing this with Microsoft’s embrace of AJAX for the next version of the ASP.NET framework. But for now Rails is here and arguably more fun to use.

The meat of the book is divided into two main sections; an implementation of a simple e-commerce web site and an in-depth look at the various components of Rails. The book has a great layout. The book’s format, links, tips, index, appendixes, etc are all handy when skimming the book, although I found most of the book so compelling I read it cover to cover. (And I actually finished it, unlike most technical books I read.) Based on your experience you could skip one section or the other, but I would suggest not skipping around too much, the authors build on content presented earlier to deliver an engaging narrative that adds perspective and savor to the content. But if you do skip around the page number of the previous content is always listed.

The introductory section does what you would expect; introduces Rails and shows you how to use it. In this section I think the readers are presented with more of the soul of Rails; explaining why things are they way they are and now that helps you. While you don’t need to be familiar with the Ruby language, you do need to be familiar with web programming in general. While the authors claim that Rails is inherently Agile, I didn’t find the tutorial particularly Agile. I was disappointed that the chapter on testing was separate from the rest of the tutorial. But I found this acceptable because the section was about getting to know Rails, and not about reinforcing the Agile methodology.

The advanced section goes into detail of the body of Rails; explaining each component of Rails and how they work. I found these chapters particularly well written and was thankful for the narrative presentation. It would have been very easy for these chapters to be dry and boring to read. Near the end of this section there are chapters on additional topics such as Web 2.0, scalability, and deployment. I think there are more advanced books that could be written on certain subjects, specifically ActiveRecord, deployment, and scalability. (I only mention scalability because it has been a common criticism against Rails. I think the book did a fair job of explaining the framework’s scalability.) Perhaps the Pragmatic Programmer folks could write some Friday books about these subjects?

The success of the book is conveying the spirit of Rails. I think the future looks bright for the Rails framework because the contributors are committed to keeping Rails simple, lightweight, and not overly-complex like most J2EE solutions. I’ll be using the lessons learned from the book such as “convention over configuration”, “don’t repeat yourself”, integrated unit testing, and the Rails deployment model while designing a new .NET-based web framework at my work.

Book Review: Object Thinking

2005-09-20T00:00:00+00:00

Despite any appearances to the contrary, objects are not something you do; objects are a way that you think.

Object Thinking on Amazon

David West’s book “Object Thinking” leads you down the garden path that you can create something new, inventive, and more than the sum of the parts. Your program can be something more than just data with algorithms. And the way to do that is by simply changing your thinking about the problem. Quite a promise, fortunately for me (and hopefully you) it delivers on the promise.

This book is very different from every other OOP or design pattern book I’ve ever come across. The first half of the book is an intriguing philosophical exploration into both the art and science of programming and how they came about. It is the author’s premise that there are fundamentally two schools of thought in Computer Science; formalist thinkers and hermeneutic thinkers. The majority of programmers (and western culture) are formalists, who share notions of control, centralization, mathematical, hierarchy, predictability, and provability. While a small minority of mostly [Smalltalkers](http://en.wikipedia.org/wiki/Smalltalk) follow a more humanistic approach to the design of software. I have to say I found the author’s portrayal quite compelling. The concept of designing code using a humanistic approach blew me away.

According to West’s definitions, I am (or was) a formalist, and have been for as long as I can remember. Most every computer science or programming book I’ve ever read has been from the formalist position. I have worked hard and struggled many times to grok OOP and design patterns in efforts to improve my project’s design. Every time I thought I had a handle on it I found a new way to break the complex model I built. I hope I’m not alone in admitting that I have struggled at times trying to find the “perfect” design solution for a given project.

The author then extends this discussion to define and differentiate computer thinking and object thinking. Computer thinking is limiting your design of the software to how you think the computer is going to perform. I found this way of thinking analogous to premature optimization, and we all know what Donald Knuth has says about that; “Premature optimization is the root of all evil (or at least most of it) in programming.”

Object thinkers strive to understand and model the domain fully, and letting their designs reflect the real world without respect to implementation. This may seem similar to use-cases, but I think there are important differences. Use-cases are a way to capture requirements, while object thinkers attempt to capture the behavior and responsibilities. Here is what the author has to say about thinking about object design:

You cannot begin to understand what must be until you understand what is. This assertion has two corollaries:

Almost all of the objects you will ever need are already defined, and already have behavioral expectations associated with them, in the domain.

Almost all of the requirements of new development arise from a misalignment of behaviors and objects. Misalignment results when the wrong object (or group of objects) is providing a particular service, a service is more appropriately provided by a silicon-based object simulation instead of a carbon-based biological object, or, occasionally, no existing object is capable of providing the needed service.

West gives some great guidelines for composing objects throughout the book. Here are some of the ideas that rang true to me:

Objects are lazy.
The four presuppositions for Object Thinking:
1. Everything is an object.
2. Simulation of a problem domain drives object discovery and definition.
3. Objects must be composable.
4. Distributed cooperation and communication must replace hierarchical centralized control as an organizational paradigm.
Eliminating centralized control is one of the hardest lessons to be learned by object developers.

Part of designing objects is delegating the right responsibilities to them. One way of determining the appropriateness of a design is to treat objects as if they were people. I found this analogy very effective when describing the book to others.

Many readers will be uncomfortable with the object-as-person metaphor. A major source of discomfort arises from consideration of characteristics that humans have that we obviously cannot replicate (and probably do not want to replicate) in software. Emotions, true intelligence, and will are major examples. The problem is made worse when descriptions of objects and their behaviors seem to allude to precisely this kind of nonreplicable characteristic–for example, “Objects are lazy.”

Effective use of metaphor requires constant awareness that a metaphor is not a specification. It is often helpful to replace the metaphor–an object is a person–with a supposition: what if an object were a person? You can then ask questions about your design in this form: if an object were a person, would I write my code this way? Here are two examples:

If an object were a person, would I directly access part of its memory without its knowledge instead of sending it a message asking for the information I need? If a developer is obsessed with performance, direct access is tempting. But reminding yourself that, as a person, you would not like someone directly probing your brain without your knowledge reminds you that this is a bad design choice. (It leads to undesirable coupling.)

Technology exists that would allow me to make hardware connections to your brain. I could then build a control box that would allow me to raise your hand whenever I pressed a button. Eventually this same technology might allow me to make you perform a complicated dance. Again, as a person, you might not like this, and neither would an object if it were a person.

Once you have properly designed the objects to fit the problem domain, you should find that the application using the objects is less of a controller and more of a collaborator. The metaphor West uses is that of a theater and the application as a director putting the right actors/objects in the right place and the right time. This is in sharp contrast to the majority of projects I’ve worked on, which mostly maintain a death-grip on the application behavior. As I look back at the projects that I’ve been a part of, I’ve found that the more elegantly designed solutions have been the ones that have relied less on rigid control and more on the proper behavior of the actors/objects.

The book is not without its failings however. I found the latter chapters that focused on a process for discovering object responsibilities using CRC cards less captivating. The author stated that this approach was presented to support and aid in the discovery of object’s responsibilities, but that the approach was not mandatory to do so. To me the real value of the book was its challenge to how I thought, not what tools or practices I used.

In the end, this was the book I have been looking for. I was tired of reading about the implementations of OOP, and wanted a book to just help me “get it” on a deeper level. I hope to find more books like this in the future. Highly recommended.

Installing Typo on Shared Hosting

2005-08-31T00:00:00+00:00

Okay, I’ve succumbed to the peer pressure, I’ve installed Ruby on Rails and I’ll even use it for this site. As I said earlier, my hosting provider is HostingPlex, and is not yet well suited to host Rails applications because mod_ruby and FastCGI are not installed with a shared-hosting account. I’ve been begging for first class Ruby support, but so far nothing has come of it. Of course, folks could always contact HostingPlex and ask that they support Ruby and Rails in the future.

I’ve used and said nice things about Rublog in the past, but the reason I’ve decided to move from Rublog is the exact reason I chose it in the first place. Rublog works off the files on the file system, and not a database. I’ve found that if I need to make a change to an older article, the file’s timestamp and subsequently the article’s URL is changed. I’ve discovered that I like to correct spelling and grammar mistakes, and that ended up changing the chronological order of my site.

I could have extended Rublog to change this behavior (similar to the extensions used in blosxom), but I decided to switch to Typo which uses Ruby on Rails. Typo recently released a new version that caches the generated pages on the file system, so the blog serves static HTML files the majority of the time. Compared to the performance to the older versions of Typo, the performance seems good enough (for now), even without mod_ruby and FastCGI.

The first step is to download the latest version:

$ cd ~
$ wget http://rubyforge.org/frs/download.php/5602/typo-2.5.5.tgz
$ tar zxvf typo-2.5.5.tgz

Typo uses a database to store articles and comments, so the next step is going to be to create a new MySQL database. It seems HostingPlex doesn’t allow you to create a new database using shell commands, so we’ll use the tools available on CPanel. First, go to the CPanel and choose “MySQL Databases” and create a new DB named typo. This will actually create a new database named *hostname*_typo, because your account name is always added to the beginning. The same is true for user accounts. On the MySQL page create a new user named typo. This will create the user *hostname*_typo. Use the same MySQL page to add the *hostname*_typo user to the *hostname*_typo database with “All” privileges.

Next you click the “phpMyAdmin” link at the bottom of the page. This tool will allow you to create and maintain tables in your databases. Instead of creating each table manually, we will run the script that comes with Typo. Using a new instance of CPanel, go into the “File Manager”, navigate to the typo-2.5.5/db directory and view the schema.mysql.sql file. Copy the contents of the file and paste them into the “SQL” tab in “phpMyAdmin”. You should add 15 new tables to your schema.

Now that you have the tables created, you need to tell Typo what database to use. To do this, edit the typo-2.5.5/config/database.yml file and add your database credentials.

production:
  adapter: mysql
  database: blowmage_typo
  host: localhost
  username: blowmage_typo
  password: super_secret_password

We need to tell Typo where to find Ruby and where to find the Typo scripts. We do this in the typo-2.5.5/public/dispatch.cgi script. (Because HostingPlex doesn’t have Ruby installed, we installed a local version earlier.) We also need to tell Typo that we should be running in the production environment by setting the RAILS_ENV environment value. This will tell Typo to use caching for improved performance. Change the first few lines to this:

#!/home/blowmage/local/bin/ruby
ENV["RAILS_ENV"] = "production"
require "/home/blowmage/typo-2.5.5/config/environment"

We also need to tell Apache to use the dispatch.cgi script instead of the default dispatch.fgci. In the typo-2.5.5/public/.htaccess file, change the last RewriteRule line to the following:

RewriteRule ^(.*)$ dispatch.cgi [QSA,L]

Like all Rails apps, the “typo-2.5.5/public” directory is what the web server is supposed to serve files from. However, with our shared accounts we don’t have permissions to change where Apache to serves the site. Instead, we will copy the files from the public directory to the directory that Apache uses. We also need to tell Typo where to write the cached files so that Typo and Rails don’t load into memory with every request – killing performance. The configuration isn’t difficult, but it needs to be set in two different files. First, the typo-2.5.5/config/environments/production.rb file needs the following lines added to it.

ActionController::Base.page_cache_directory = "/home/blowmage/public_html"
ActionController::Base.page_cache_extension = ".html"

Second, we need to tell Typo’s PageCache class where to remove the cached entries from. (I believe this is a flaw in the current design, and I have opened a case. As of this writing, the case has not yet been assigned.) So change the typo-2.5.5/app/models/page_cache.rb file to the following:

class PageCache < ActiveRecord::Base

  cattr_accessor :public_path
#  @@public_path = RAILS_ROOT + "/public"
  @@public_path = "/home/blowmage/public_html"

Alright, we’re almost there! We just need to copy the public files to our site.

$ cd ~
$ cp –r typo-2.5.5/public/* public_html
$ cp –r typo-2.5.5/public/.htaccess public_html/.htaccess

Now when you browse to your site you will be prompted for your login information. Enter your info and you will be redirected to the admin section. You can now create new articles and categories. Enjoy.

Installing Rails on Shared Hosting

2005-08-20T00:00:00+00:00

I stated in an earlier entry on installing the excellent Rublog that I may be simply delaying the inevitable move to Ruby on Rails, and I was right. The siren call of the new and shiny has won me over, and I decided to extend this site’s Ruby support to include Rails. (The fact that the Typo blog engine now renders static HTML files dramatically improving performance also helped, but more on that next time.)

It is possible to install and use Rails on HostingPlex, but the performance will suffer. Rails is a large framework, and not having mod_ruby and FastCGI installed hurts performance tremendously. Until they are properly supported by HostingPlex, you should use at your own risk. But since you’re reading this, I’ll assume that you want to continue with installing Rails. ;)

The first step to installing Rails is to install RubyGems. Truth be known, you probably want to install gems whether you install Rails or not. Installing gems is as easy as our previous installations:

$ cd ~
$ wget http://rubyforge.org/frs/download.php/3463/rubygems-0.8.8.tgz
$ tar zxvf rubygems-0.8.8.tgz
$ cd rubygems-0.8.8
$ ruby setup.rb

Once gems is installed, installing Rails or any other gem is the easiest thing in the world:

$ gem install rails

Be sure to answer y when prompted by the Rails installation. While you are at it, you can also install a couple supporting libraries common to Rails apps.

$ gem update mysql
$ gem install redcloth

By default, Rails connects to a MySQL database using a library written in Ruby. This library isn’t as fast as using a compiled library. James Duncan Davidson has a great article on improving the performance or Rails apps by using the native library. To install the native library you should use these commands:

$ cd ~
$ wget http://tmtm.org/downloads/mysql/ruby/mysql-ruby-2.6.3.tar.gz
$ tar zxvf mysql-ruby-2.6.3.tar.gz
$ cd mysql-ruby-2.6.3
$ ruby extconf.rb --with-mysql-dir=$HOME/local/mysql && make && make install

Is it me, or are these tasks getting easier?

Extending Rublog with ERb

2005-07-08T00:00:00+00:00

Rublog is a great web site system and has many interesting features. The script works off the files on the file system and supports different file types including RDoc, HTML, and plain text. I wanted to extend Rublog to also support embedded Ruby in .rhtml files, and here is how I did it.

I decided to use ERb instead of eRuby. eRuby is a native library, while ERb is written in Ruby, which makes it slower. I would have chosen to use eRuby, but I couldn’t find any documentation on how to use it from a Ruby script, so I decided to follow the examples I could find online that were using ERb. I assume there are better ways to implement this, but this is good enough for me (for now).

Rublog makes supporting new file types easy. The first step is to create a new converter class. You’ll need to inherit from the BaseConverter class. I followed the example of the HtmlConverter class that comes with Rublog. You can find the converter classes in the *rublog*/convertors/ directory. Here is my RHtmlConvertor.rb script:

# The rhtml convertor reads a file and performs the ERb render.
# Like the html converter, we look for a natural title.
# If we can't find it, we use the first line (removing it
# if it doesn't look like valid HTML)

require 'erb'
require 'BaseConvertor'

class RHtmlConvertor < BaseConvertor
  handles "rhtml"

  def convert_html(file_name, f, all_entries)
    body  = f.read || ""
    title = "Untitled"

    if body =~ /<title>(..*?)<\/title>/m
            title = $1
    elsif body =~ /<h1[^><]*>(.*?)<\/h1>/
            title = $1
    elsif body.sub!(/\A\s*([^\s<].*)/, '')
            title = $1
    end

    erb =  ERB.new(title)
    title = erb.result
    erb =  ERB.new(body)
    body= erb.result

    HTMLEntry.new(title, body, body, self)
  end

end

The next step is to add the new converter to your Rublog CGI script. Find where the load_convertors method is called and add the text “RHtml” to the list. You need to add it before the text “Html”, or else the HtmlConverter.rd script will handle your .rhtml files. You need to be aware of the order the converters are loaded because the converters don’t look at the file extension, they simply match the end of the file name.

Confused? Don’t worry about it. Here is what the load_convertors line looks like in my CGI script:

RubLog::load_convertors(*%w{ RHtml RDoc Text Html })

That’s it, you should be ready to go. Add the following text to a file with the .rhtml extension to your blog directory and watch the magic.

<h1>Testing ERb and RHTML files in Rublog</h1>

<p>This is just a test of supporting *.rhtml files in
Rublog. This additional functionality will render the *.rhtml source
with ERb and display the output.</p>

<p>For example, the following code is executed below:</p>

<hr>

<pre><code>
&lt;p&gt;&lt;% 5.times do %&gt;Hello &lt;% end %&gt;Ruby!&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Addition: &lt;%= 1+2 %&gt;&lt;/li&gt;
&lt;li&gt;Concatenation: &lt;%= "cow" + "boy" %&gt;&lt;/li&gt;
&lt;/ul&gt;
</code></pre>

<hr>

<p><% 5.times do %>Hello <% end %>Ruby!</p>
<ul>
<li>Addition: <%= 1+2 %></li>

<li>Concatenation: <%= "cow" + "boy" %></li>
</ul>

<hr>

<p>This concludes our test...</p>

You may be asking yourself why this would be necessary, or even desired. To be honest part of why I wrote this was to see if I could do it, but I do see value in enabling a piece if web content with server-side functionality. It allows me to add new behavior without duplicating the navigation and presentation that Rublog gives you. At least, that’s how I justified it. ;)

Installing Rublog on Shared Hosting

2005-06-24T00:00:00+00:00

One of my requirements when looking for a blogging engine was to have the engine pull the content from the file system. I just wanted a very simple and lightweight framework. I also wanted to edit my content files manually, and not through some web-based WYSIWYG interface. I’m not distrustful of more complicated blogging engines, I use them on my other sites, but I thought this site needed a different approach. I wanted to be closer to the metal.

I originally started out using blosxom, and I liked that approach very much. But I’ve never been much of a Perl hack, and I was faced with either learning more Perl or finding a different solution. Once I found Ruby I knew I had my language, and I just needed an engine. I thought about porting blosxom to Ruby, but I decided that I would do better with Rublog as my starting point. Rublog isn’t 100% what I’d like it to be out of the box, but I find it very easy to change to my liking. I figure one of the tenants of “Don’t Repeat Yourself” is not reinventing the wheel when you don’t have to.

This may seem to fly in the face of the current Rails hype, (and I may indeed only be delaying the inevitable move to Rails) but until my hosting provider has more support for Rails I’m very happy with where I’m at with Rublog.

You start by downloading and uncompressing the Rublog source:

$ cd ~
$ wget http://rubyforge.org/frs/download.php/1668/rublog-1.0.tgz
$ tar zxtar zxvf rublog-1.0.tgz

The next step is to copy the CGI script to your public_html directory. I’ve renamed it for reasons that I’ll explain later. I also created a new directory to store all my blog entries. I find it best to not store these blog entries in the public_html directory, since you probably don’t want folks to bypass the CGI script to get to the content.

$ cp rublog-1.0/rublog.cgi public_html/index.cgi
$ mkdir blog

Before you browse to /index.cgi and see the content, you need to change the CGI file to point to your local instance of Ruby. Be sure to change /home/*blowmage* to the path to your account’s home directory:

#!/home/<i>blowmage</i>/local/bin/ruby
RubLogSourceLocation("/home/blowmage/rublog-1.0")

The CGI will show you the Rublog documentation by default. Once you are comfortable with the way Rublog works, you should update the index.cgi script to look at the blog directory for the blog content:

BLOG_DIR = "/home/blowmage/blog"

You can now browse your site through the script: /index.cgi.

However, I hate seeing a CGI script in the URL. I feel this doesn’t promote good URIs. If we could hide the CGI script then we are free to replace our site’s implementation without breaking search engine results and people’s bookmarks. Doing this is much easier than it sounds, and it involves our old friend the .htaccess file.

What we need to do is tell the .htaccess file to route all failed requests through our Rublog CGI script. This means that requests to existing resources such as other CGI scripts or HTML or image files will continue to be served. The requests for files that don’t exist are sent to the Rublog CGI where Rublog determines what to serve for that request. This is accomplished by adding the following rewrite rules to the .htaccess file.

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.cgi/$1 [L,QSA]

Rublog is now installed and will respond to requests even if they are missing the script path. However, Rublog wasn’t written with the expectation that we would want to hide the script path, and the script path is embedded throughout the Rublog code. I have made additional changes to Rublog to hide the script path, but those are outside of the scope of this document.

That’s it! Despite the hype machine working overtime promoting Rails, I’ve found the hardest part was installing Ruby. I hope this article has been of interest to you. If you have any suggestions or corrections drop me a line. With Ruby installed, you’re on your way to become more productive and have more fun. Good luck!

Installing eRuby on Shared Hosting

2005-06-10T00:00:00+00:00

Now that we’ve got Ruby installed, we can use it to write CGI scripts. But that is so 1995, isn’ t there a better way to use Ruby to create web sites? Of course there is, and the first step is eRuby. eRuby interprets Ruby code that is embedded in a text file. Our interest is embedding Ruby code to a HTML file, much like Microsoft’s Active Server Pages, Sun’s Java Server Pages, and Zend’s PHP.

Just like installing Ruby, this is surprisingly easy to do, as we simply enter these commands in at the shell:

$ cd ~
$ wget http://www.modruby.net/archive/eruby-1.0.5.tar.gz
$ tar zxvf eruby-1.0.5.tar.gz
$ cd eruby-1.0.5
$ ./configure.rb --prefix=$HOME/local && make && make install
$ cd ~
$ cp local/bin/eruby public_html/cgi-bin/eruby

We’ve installed, compiled, and copied the eruby executable file to our site’s cgi-bin directory. Our site is now ready to use the executable to parse our HTML files for Ruby code and execute it. To do this, we need to associate our files with the CGI executable. Parsing our files for Ruby code does add some overhead, so we probably don’t want to parse every single file, so we’ll associate the file extension .rhtml with eruby. We make this association in the .htaccess file in the public_html directory by adding these lines:

AddType application/x-httpd-eruby .rhtml
Action  application/x-httpd-eruby /cgi-bin/eruby

If you don’t have an .htaccess file in your public_html directory then simply create one. Let’s test this! Create a new file in your public_html directory named hello.rhtml. The file should include the following lines:

<html>
<head>
<title>Hello Ruby!</title>
</head>
<body>
<h1>Hello Ruby!</h1>
<p>
<% 5.times do %>
Hello
<% end %>
Ruby!</p>
</body>
</html>

When you browse to the file you will see a message that displays “Hello Hello Hello Hello Hello Ruby!” then you have officially installed eRuby, congratulations.

Installing Ruby on Shared Hosting

2005-05-28T00:00:00+00:00

The hosting provider for this site is HostingPlex. HostingPlex doesn’t support Ruby “out-of-the-box”, which is unfortunate because Ruby is gaining momentum and has a lot of mind share with web developers right now. I’ve made the following modifications to my account in order to run Ruby and I hope you find them useful. Hopefully the steps I tool will translate to other hosting providers and will be useful to others.

Much of this information is a direct result of an excellent article on Wesley Moxam’s blog. I am going to initially focus on installing and using Ruby and Rublog, and not necessarily Rails. Although once Ruby is installed and configured, installing and using Rails shouldn’t be too hard to do. However, HostingPlex is not well suited to Rails hosting (yet) because some server-side configurations such as mod_ruby and FastCGI are very difficult or impossible to install with a shared-hosting account. Hopefully HostingPlex will change their mind and start supporting Ruby and Rails in the future.

Ruby is not currently installed on the HostingPlex servers, as I assume is the case for the majority of Linux hosting. To install Ruby, you’ll need access to the shell for your account. The Unix shell is similar to the Command Prompt on Windows machines. You can access the shell through your CPanel interface by clicking the “SSH/Shell Access” link.

We’ll start with a simple command to ask Ruby to tell us what version it is.

$ ruby -v

If you don’t have Ruby installed you should see a message such as “command not found”. If you do have Ruby installed, then you can skip ahead.

To install Ruby we will download and compile Ruby from the source code. We’ll install Ruby into a new directory named local, because we don’t have permissions to install Ruby for all users on the server. We will follow this process for the other programs we’ll eventually install.

$ cd ~
$ wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.2.tar.gz
$ tar zxvf ruby-1.8.2.tar.gz
$ cd ruby-1.8.2
$ ./configure --prefix=$HOME/local && make && make install

Our next step is to ask Ruby what version is installed.

$ ruby -v

Did that fail again? Don’t worry, this is because we installed Ruby in a non-standard location, and the shell doesn’t know to look in the new directory. To make the shell look in that directory, run the following command:

$ export PATH=$HOME/local/bin:$PATH

Now you should be able to ask Ruby for its version without receiving an error message. Of course, it would be a pain to run the preceding PATH command every time we connected to the server, so we’ll create a new file named .bash_profile. In this file, you should add the now following line:

PATH=$HOME/local/bin:$PATH

Now every time you connect to the server through the shell, your account will look in your local directory for Ruby.

Let’s test this! Create a new file in your public_html directory named hello.cgi. The file should include the following lines:

#!/home/blowmage/local/bin/ruby
# hello.cgi
puts "content-type: text/html"
puts
puts "<html>"
puts "<body>"
puts "<h1>Hello Ruby!</h1>"
puts "</body>"
puts "</html>"

The home directory for my account on HostingPlex is /home/*blowmage*. You’ll want to change the first line of your script from /home/*blowmage* to the path to your account’s home directory. If you do not, then the script won’t know where to find Ruby and the script will fail. If you see a message that displays “Hello Ruby!” then you have officially installed Ruby, congratulations.