tl;dr: video is here. The slides are included in the video (so cool!) but you can also download the PDF version

Last October I got to go to Aloha on Rails and as you would expect from a Rails conference hosted in Hawaii it was AAAAWWWWWEEEEESSSSSOOOOOMMMMMEEEE.

I gave a talk called “Domain-Driven Rails” which I retitled on the fly to “The Evolution of Rails as viewed through a Theory of Constraints perspective” (or something thereabouts).

It starts off with a look at the different phases in Rails’ evolution, with the phases defined by the most important problem (greatest constraint) at the time. So Rails came into existence first to solve DHH’s pain point of having to write X implementation and Y mapping files every time he wanted to add a new database table. Once that was figured out we moved on to getting even more code out quickly, which came in the form of generators. Those worked for a while but upgrading became a PITA and so we used more frameworks and metaprogramming techniques to get the benefits of generated code but without the pain. We’ve got a pretty good handle on all that and now we’re running into different constraints: complexity of the model, persistence choices, etc.

Those are just a few of the points. I also pick apart a couple of code examples in which I make a case for abandoning some of the tricks you’ve taken for granted over the past year or two.

So check it out! I had a lot of fun presenting. It’s not perfect, and I’d be happy to discuss any feedback you’ve got from watching it. If you enjoy it, look for my followup presentation at RailsConf 2010 in Baltimore.

Also big thanks to Seth Ladd for running the DOPEST CONFERENCE EVAR as well as responding to my challenge to put the video up online sooner rather than later. Mahalo, dude

What the community says:

We’re having trouble with bundler

What the Rails/Bundler team says:

Rails 3 source code does not know anything about bundler

What the code says:

~:$ gem install rails --pre
ERROR:  Error installing rails:
    rails requires bundler (>= 0.9.2, runtime)

Still kinda ghetto

There are many reasons you should use long, descriptive method names. I won’t go into them all here, just use google, or read Clean Code, or something. But here’s a reason that you probably haven’t heard:

Long method names are better for mocking

It’s pretty simple. Given the following code and test:

class Discount
  def initialize(amount)
    @amount = amount
  end

  def apply(total)
    total * (100 - @amount) / 100.0
  end
end

describe Order, "compute_total" do
  ...

  it "should apply an available discount" do
    # @order.total.should == 55
    discount = stub('discount')
    @order.discount = discount
    discount.should_receive(:apply).with(55).and_return 50
    @order.final_total.should == 50
  end
end

Let’s say you decide to perform a rename method refactoring and change ‘apply’ to ‘compute.’ Now you get to pull up the terminal and type ack apply – not fun. Of course you could search for discount.apply, but there’s a good chance you’re going to miss something. Compare this with naming the method ‘apply_discount’ and the benefit is obvious.

Using long method names gives you the confidence to ack for those names, which in turn gives you confidence to refactor a mock-heavy test suite, which in turn gives you more confidence using mocks in the first place, which in turn lets you gain the benefit of mocks when appropriate instead of being scared away by the pitfalls

A while back I asked if we need a maturity model or excellence in Rails. There is a lot to be done in this area I’m sure but the first step for me is opening up a basic discussion forum. All I want is for the conference hallway chats to continue throughout the year and be open to more people. With that I’ve set up a rails.excellence mailing list on Librelist. All you need to do to sign up is send an email to rails.excellence@librelist.com and you’re on. I hate google & yahoo groups and I’m thankful that Zed has put so much work into Lamson & Librelist and made it available. There are archives but it’s still kind of rough. Signing up early is the best way to ensure that you don’t miss out on the good stuff :)

Signing Up

The way Librelist works is you just send an email to the list and you’re on, there’s no explicit subscription process. This means that if you want to join up you’re going to need to send an email! It can be whatever you want of course, but I’d be interested in seeing an intro email that includes how you’re using Rails and what challenges you face.

For reference, here’s the first email I sent to the list. It contains my general idea about the list and a few guidelines:

Hey everyone,

Pat

TextMate was the first editor I ever really got into. I had used other editors before, but it wasn’t until I read The Pragmatic Programmer that I learned I needed to be any good at using them. I happily used TextMate for a couple years until one day I decided I just couldn’t live without split panes anymore. That’s when I gave Emacs a try, and I liked it, so I’ve been using it for the past year or so.

I’ve always had a few minor gripes with emacs. My config always seems a bit finicky. And I have a tendency to mess around with code, and just run it, so I end up with a lot of unstable code running inside emacs. If I’m messing with keybindings or certain functions, I often end up with a pretty broken emacs, forcing me to restart. I love emacs’s smart indentation, but it doesn’t always get it right. Ruby method calls that span multiple lines don’t indent properly if I leave out the parens. It also doesn’t have the best support for non-standard syntax. For example, I have a coworker who is compelled to write “class <<self” instead of the more idiomatic “class << self” (don’t ask me why. I’ll change it and check in, and a later commit has it changed back. I have more important battles to fight). Emacs doesn’t seem to realize that they’re the same, and screws up the highlighting in the second case.

The indenting/highlighting I’m sure could be solved with a little bit of spelunking in ruby-mode.el. I’ve just never gotten around to it. The fact is, I don’t really want to spend any time digging around my editor’s code to figure out an issue like that. I want a powerful editor that “just works”. And to tell you the truth, I’ve never grown fond of elisp.

So all of this has made me consider taking a deeper look at vim. Frankly though, I didn’t have the time or motivation to do it. Then I went to Aloha on Rails (best conference EVER) and sat next to Tammer Saleh while he was working on his presentation. He was using MacVim and was FLYING. I honestly could not really keep up while watching him, there were just little bits of code shifting around the screen. I noticed he kept hitting escape all the time, which looked annoying, but I couldn’t get over the fact that he was moving way faster than I ever have on Emacs. Okay, I’ll give it a shot.

I’m on my first day of learning vim as I write this (yes, in vim). Here are my notes as I go along:

vim rewards me for knowing how to type

Most of the commands are done with one or two keystrokes. So far, very few require modifier keys. I didn’t realize what a boost this was. I already know how to touch-type pretty darn well, so just being able to get stuff done with a few simple characters is awesome. Using modifier keys feels natural to me (and I’m starting to think it’s because I’ve been raped by other editors all these years ;) but it’s definitely not easier.

vim rewards me for being logical

Commands can be built up through composition. In emacs, when I wanted to be able to duplicate a line, I had to write a new function for it and assign it to the keymap. In vim it’s just yyp – y to set it up to yank, y again to make it apply to the whole line, p to paste. I can easily figure out how to perform something on the next three words, lines, paragraphs, code blocks, current selection, whatever. There may be a faster way to do it sure, but if I can think of the building blocks necessary to achieve some result, I just put those blocks together and bam. I can do that with Emacs too, it just takes 20x characters.

. to repeat command

This is super sweet. Any time you run a command, you can repeat it just by pressing ‘.’ . I’m sure you can do this in emacs too, I just don’t know how :) Also, I doubt it would work the same way anyway, because vim commands are more than just a single function.

Macros

This is somewhat like repeating a command, but even more awesome. You press q[a-z] to start recording, run a bunch of commands, then q to stop recording. This saves a macro of all the commands you just did. Type @a and it will replay all those commands. Perfect for when you need to do something repetitive that’s too hard to do via regular expression search & replace.

Tabs & panes

I mentioned the reason I moved to Emacs in the first place was because I wanted split panes. It turns out that vim has them too, but on steroids. Or at least, exactly the way I wanted them. So to start, vim can have multiple tabs, just like TextMate, or Safari, or whatever. But you can create split panes within the tabs. Net result? I can have one tab for my User model, with the tab split into two panes – one for user.rb and one for user_spec.rb. SICK. The best way I’ve found to do this within emacs is to have multiple frames (= OS window) and do split panes in there. The thing is, I don’t like having multiple operating system windows open when working on a project. I like having one window per project, and navigating within that. vim gives me a better way to view my code than I originally even wanted!

tpope

I don’t actually have to know how to write vimscript. I just have to invoke the pope (so I’m told).

Editing is modal – who knew?

Let’s say you want to delete a paragraph of text. If this is the sort of thing you do frequently, you might have it bound to a key combo and know it by heart. If not, then you’re going to go to the beginning of the paragraph using the arrow keys, select all the text by using shift + arrow keys, and finally pressing delete. That is a fundamentally different way of interacting with the program than simply typing text. In short, you’re in a different mode. vim makes that mode explicit, and in doing so opens up some interesting possibilities. And of course, it also frees up the keyboard, so that the common commands become one keystroke. btw, you delete a paragraph in vim with dap. Um, sweet.

Now you may not agree with me that editing is modal. That’s fine. I don’t think it’s black and white. There are some small edges cases for me (such as immediately correcting a mistyped word), but I’m getting the hang of it and building muscle memory. For the most part though, the idea that editing is modal fits my brain & and usage pretty well.

Marks

vim lets you set marks within a document. This is nifty when you’re jumping around between three different methods in a source file. Set a mark, bounce around, and get back to your original spot with two keystrokes.

An editor for people and programmers

The main thing I like about vim so far is that it’s simple to do the things that I genuinely do all the time while editing text. Even the tutorials are more geared towards every day use it seems. I know that emacs can do everything that vim can (and more ;) but I have a tough time remembering everything that I want/need to do. Often if something is useful enough I’ll make a custom keybinding so that I can remember it easily…but then I’m away from standard keybindings which can be a pain. Plus, why aren’t some of these things “standard” to begin with (duplicating a line comes to mind). I would say that vim just ships with more sensible defaults for both basic and power editing.

Scripting in Ruby

Apparently you can write vim scripts in Ruby. According to Jamis, it works really well. I’ve only used it a little bit in modifying Jamis’s script a bit but I was surprised at how smooth the integration was. No headaches at all. Also, Ruby >>>>> elisp for my purposes.

ERB highlighting

This was something I could never get working very well in Emacs. I can’t tell you how many hours I spent fiddling with however many different modes. Just never seemed to work consistently. On my newer Mac I got the highlighting work, or at least it seemed so, but after 5 minutes of typing it would go sloooooooow. No clue what the heck happened. I’ve still been using TextMate to edit all my views because its ERB support is great. Turns out vim is good at it too. Nice.

Two weeks in – what I’ve learned

vim is sweet, but the learning curve is huge

Not a whole lot to report on this front. I’ve built up the muscle memory for some common commands that irritated me early on, and now I’m finding vim to be even nicer. What I have noticed is that because there’s so much stuff in vim, “if you don’t use it, you lose it.” Meaning that I have to periodically look up things that feel like they should be simple, because I just haven’t used them enough and committed them to memory. I’m making it a point to learn one or two new commands each day, and use the hell out of them.

Editor wars are stupid

I know TextMate better than most people I pair with that use it regularly. I’m proficient with emacs and now competent in vim. What this has done is made me truly appreciate the differences between them. I used TextMate yesterday for the first time in a long time (pairing), and was blown away by the command+t behavior. It’s nothing new to me of course, but after trying all the various copycats in emacs & vim, it’s clear that TM’s implementation is head-and-shoulders above the rest. vim and emacs both have their pluses and minuses. You can get a lot of stuff done in any editor. Arguing about which is better is a horrific waste of time.

This also means that if you respond to this saying that I’m stupid and misused/misunderstood Emacs, I’m going to delete your post and ban you from this blog forever. Not even joking. Save the petty crap for reddit.

Bottom line

I’m using vim for everything right now, which is something I couldn’t do with emacs (in particular erb files). Don’t see myself using emacs unless I’m doing lisp or haskell work (emacs has a really slick haskell-mode). But frankly those are uber thin edge cases for my usage.

About 6 months ago, Obie Fernandez proposed a “Rails Maturity Model.” Reactions mostly ranged from lukewarm to downright hostile. I didn’t give it much thought at the time it was introduced, but the discussion panel on RMM at Aloha on Rails piqued my interest. I kept wondering to myself, “What problem are we trying to solve?” I want to briefly talk about some potential answers to that question.

Certification

It seems to me like when people first heard about RMM, the first thing that jumped into their mind was certification. That’s too bad, because that’s not what Obie intended at all. The first beef many people have with certification is that it can be gamed. Having a specific certification doesn’t necessarily mean you’re a good software developer, and naturally there are many talented developers that don’t have the right certifications for whatever niche they’re in. It’s completely true, but I don’t see the relevance in the context of RMM. Chosing to hire someone or not based on a certification is pretty stupid no matter how you slice it.

Another argument that I’ve heard against certification is that it could make life harder for a bunch of programmers who have been using Ruby/Rails effectively long before certifications came on to the scene. Now what if they’re unable to find work because potential employers won’t even look at applications that lack the hot Ruby certs? Ignoring for a moment the fact that you don’t want to work at a place like that to begin with, I think the Ruby community is immune to that scenario. Openness pervades our culture and you can’t put that genie back in the bottle.

Educating Potential Clients

According to people more in the know than me, there’s a lot of software written that is so crappy that the development firms should be considered criminal. I can understand that elite firms might consider it a moral obligation to reach out to customers, if only to save the hapless clients from a tragic and expensive project that’s doomed from day 1. Does this moral obligation extend to the community as a whole? I don’t think so. Teams and individual developers might feel the same obligation, but that’s a deliberate choice. Hashrocket is special because they’ve adopted a certain set of values. The Hashrocket Way doesn’t scale to the whole community though, because not everyone shares those exact values.

As noble as it is to direct customers to the firms that can do the job at least adequately, I think this is a business responsibility rather than a community one. It’s a responsibility shared between client and provider — caveat emptor; and software shops need to market themselves in a way that distinguishes them from the unwashed masses. While the responsibility for this falls squarely on the business side, the community can help the state of affairs by serving as a trust network. If someone falls in love with Hashrocket but has a heart attack at the price tag, HR can refer them to someone who may be more suitable. Customers shopping around can also research the top firms and see what they have in common with each other. They can then use the information learned to analyze alternate firms that might perform better on other criteria: cost, location, familiarity with other technologies.

Interestingly, this line of thinking can lead to the idea of certification boards a la the medical and legal professions. I’ve considered this possibility as a way to achieve accountability in the industry, but I think it would do way more harm than good. In sectors where personal safety is an absolute necessity, there are already regulations in place, with audits ensuring that standards are met. Is our situation so dire that we’re willing to create a legal burden on small-time developers who write blog systems and bulletin boards for mom and pop shops? The competent shops, who supposedly benefit from being part of a high-quality industry, will also face the threat of malpractice suits. That alone is enough to make legal certification a terrible idea. It’s not that we want to skirt responsibility. It’s just that we get more value from asking the question, “Is there some other way to improve the software industry than a policy of ‘take this test, and get sued if you fuck up’?” Finally, throw in the fact that in recent months we’ve learned of corruption in financial and voting systems, and I think it becomes increasingly important that we as technologists pay close examination to what the government does, not the other way around.

Excellence

There are two facets to excellence, achieving it and redefining it. Newcomers to Rails face a daunting task. They typically have to deal with a funky new language, different environment, and all those friggin Mac people. Not only that but there seems to be a whole different culture going on. People debate testing frameworks, version control systems, and what the hell is this NoSQL thing?! The initial step for RMM should be to codify the important choices developers can make — the decision to use automated testing, to use version control, or stick to widespread infrastructure options. This communicates the principles and practices that we feel are supportive of effective software development, and provides a starting point for people who want to become effective.

A separate but related issue is advancing the state of the art. We can focus our efforts on improving in areas that give us a lot of bang for our buck. The question is not whether RSpec is better than Test::Unit, but rather if Test::Unit is better off for RSpec existing. Since Shoulda came on the scene, the answer is obvious. RSpec is better off for Shoulda existing as well, and vice versa. The developers who use these tools, by extension, are better off due to the vibrant ecosystem.

How do we achieve excellence?

While watching the panel, I put my hand up several times to ask a question, but took it down each time because I couldn’t figure out just how to formulate it. If RMM isn’t about screening out bad developers or educating customers, but rather about defining excellence in the Rails world, then why do we need it? Sitting there surrounded by talented, creative software minds, the path to excellence seemed obvious to me — go to a conference and spend a lot of time talking to a bunch of wicked smart people. It doesn’t matter if you’re just getting started and don’t know where to go, or if you’re a seasoned pro looking to push the boundaries of your practices. What’s needed is not some formal codification of popular practices, but simply a way to keep the high-level conversations going all the time, not just in between sessions at conferences.

I’m not sure how to do this. Personally I would love to have a small mailing list made up of the 10 to 20 people I cling to at conferences who really know what’s going on. I learn so much and come away with so many ideas after a conference, I want to have that feeling all the time. Sites like stackoverflow let you ask questions and get feedback from the community. Maybe an RMM-style site could be effective. I think the important thing is to gather the top thinkers in our community and create an extended dialogue, and make it open to the community as a whole so we can continue to get fresh ideas and cultivate up-and-coming thinkers. What’s the best way to do that?

Be is the most boring word in the English language. It so weakens communication that there’s even a funky sublanguage called E’ (“e-prime”) that removes all or almost all of its usage. Supposedly it makes for more efficient communication, but also supposedly sometimes it’s awkward, though I have heard of people fudging when it sounded better to do so.

Anyway we’re not here to talk about that. We’re here to talk about Be as applied to object-oriented programming. Specifically, that the notion of objects being a combination of state and operation results in object designs that are brittle, overcomplicated, and altogether uninteresting.

Let me tell you about a little clinic I worked on at Agile 2009 a few weeks back. We were given a set of use cases for a veterinarian’s accounts receivable. The first use case was really simple, it looked something like:

David brings Fluffy to the vet’s office for a routine visit. While there, Fluffy receives a rabies vaccination. David pays in cash, and receives a receipt listing the cost of the office visit, the rabies vaccination, and total amount.

By the way, this is the perfect kind of use case from which you can begin to write BDD examples. I had a fascinating conversation with Liz Keogh and JB Rainsberger at our BDD clinic at Agile 2009. I’d read about feature injection from Liz before, but here she pointed me to Chris Matts who has written a killer comic book to get his ideas out there.

So back to the point. I watched someone approach this with a typical OO style, writing classes for each of the domain objects that appeared in the use case. In Ruby, it looked roughly like this:

class Person
  attr_reader :name

  def initialize(name)
    @name = name
  end
end

class Pet
  attr_reader :name, :owner

  def initialize(name, owner)
    @name = name
    @owner = owner
  end
end

class OfficeVisit
  attr_reader :pet, :procedures

  def initialize(pet)
    @pet = pet
    @procedures = []
  end

  def add_procedure(procedure)
    @procedures << procedure
  end
end

class Procedure
  attr_reader :name, :cost

  def initialize(name, cost)
    @name = name
    @cost = cost
  end
end

There was also something else which actually printed the receipt, but it was using a templating/parsing engine that I was not familiar with. It was in Java and to tell you the truth I had no idea wtf was going on.

As best I can recall, the tests looked like

it "should show a receipt with all line items" do
  @owner = Person.new 'David'
  @pet = Pet.new 'Fluffy', @owner
  @office_visit = OfficeVisit.new @pet
  @office_visit.add_procedure Procedure.new('Routine checkup', 10)
  @office_visit.add_procedure Procedure.new('Rabies vaccine', 5)
  template_result = @crazy_templating_engine.sub @office_visit
  template_result.should include('Routine checkup: $10')
  template_result.should include('Rabies vaccine: $5')
  template_result.should include('Total: $15')
  template_result.should include('Paid in cash $15')
end

Entity-based domain objects

So what’s wrong with this? The domain language is reflected in code. Each class is doing one thing only. There’s no duplication. We’re good, right?

Wrong. It’s true that you can read the code and build up a mental image of the domain, but can you tell me what the domain does? Can you tell me what the app does?

I want to reexamine the justification that this is a good design.

Domain language is reflected in the code

Yes…sort of. At best it’s a naive encoding and at worst it’s lazy bordering on negligent. Without getting too much into feature injection (subject for another post), the domain language we’ve used here doesn’t express the value we get from the use case or how to achieve that value. At the very least you would expect to see a Receipt class, right? It may have been a poor choice to go with a templating engine, or it may have been a technical constraint with working in Java. Either way, the words are right for the domain, but we need to ask ourselves if whether they’re the right words for the system that we’re trying to build.

Each class is doing one thing only

Here’s where things get a little bit murky. Each class represents a separate domain concept, with no overlap between them. My question is, what are these classes doing? Doesn’t look like much to me. OfficeVisit probably calculates the total amount of the visit, or maybe that responsibility is misplaced in the receipt printer. At any rate, a class’s name should give you a good idea of what the class does, and “be a procedure” does not yield much info. I submit that in developing software, “Be” is interesting only when followed by “havior”. In part 2 we’ll look at alternatives to this entity-based naming (hint: look for Liz’s writing on anthropomorphic role-based interfaces. Corey Haines pointed out to me that it’s hard to violate the SRP when your class is named PrintsReceipt.

There’s no duplication (the code is DRY)

On the surface this appears to be true, because again there’s no overlap between what the different classes do. As it turns out, there’s duplication all over the stinkin place. This duplication occurs in a form called connascence. Jim Weirich has discussed this as part of his Grand Unified Theory of Software Design, which you should watch immediately, or at least read the slides. The particular connascence that occurs in this design is connascence of name, which is a weak form of connascence. Objects have to interact with each other over an agreed upon protocol, but that is a protocol whose chattiness and interested parties you would like to limit. Demeter “violations” are the product of unchecked connascence of name. One object knows the name of another object’s method, and a method on that object, and so on. When one object in the chain changes, it affects nearly every place in the system that uses that object. Baaaad object modeler. Wrapping these chains in delegator methods just pushes the connascence down, but admittedly encapsulates it just enough that a change in one object usually only results in a change in its immediate neighbors, who keep that change encapsulated from other potential collaborators.

So what do we do instead?

Well I’m not going to tell you just yet. In my follow-up post I will share another possible approach to tackling this problem, an approach that I think is simpler and more flexible and manages to express the domain and requirements more vividly.

For the past several months I’d been using a webby-based home brew blogging sytem. I did that so I could easily compose and edit drafts locally in emacs. webby let me build a site from the source files and rsync it to the server to publish it.

Well, for the past several months, I haven’t actually written any blog posts :) I decided that I was not interested in running a blog on my own slice, or using a system where I ever have to look at the source code. Kind of strange coming from a programmer, but I’ve got a ton of stuff that I want/need to do, and fiddling with my blog system is not one of them. I just want to write some freaking blog posts.

So I went out in search of a good hosted blogging service. Turns out they all suck. wordpress.com was pretty good but it doesn’t let you embed javascript, something I know I will want to do at times. Wordpress seems like a decent blogging platform over all though, so I signed up for shared hosting at steadcom.com and installed the Wordpress blog you see here.

None of my old posts show up in the new system – I had no interest in trying to import the data, get the links right, supporting images, etc. The good news is, all that content is still available at archive.patmaddox.com. I’ve set up automatic redirects, so if you have any links pointing to my old blog posts they should continue to work.

As far as editing locally and publishing goes, my pal David Chelimsky turned me on to MarsEdit. Exactly what I wanted, although I didn’t know it. Thanks David!