Radyology

Don't Get Blocked By A Broken Build

Lets examine the behavior of a healthy 3 person development team:

<Build failure alarm sounds>
Tim: Sorry guys, that was me!
<A few minutes pass>
Tim: Build's fixed
Steve, Bob (in unison): Thanks Tim!

Now lets examine the behavior of an unhealthy 3 person development team:

Bob: I just did an update and now the build is failing. Anyone know why?
<silence>
Bob: Looks like Tim was the last to commit, does anyone know where he is?
Steve: I think he's in a meeting.
Bob: I guess I'm blocked then (heads to digg.com).

If Bob wanted to get around his block, he could fix the build himself and check in the change. Hopefully, he understands enough about what's going on to really fix it. And an email to Tim to let him know what happened would probably be a good idea as well.

Another option, rarely exercised, is to revert Tim's change to fix the build, and then email the team to let them know what happened. Really, it's nothing personal. Tim just make a simple mistake, he checked in when he wouldn't have enough time to check the build before going to his meeting. Now Bob (and the rest of the team) is stuck. If the fix isn't obvious, or will take a long time, the solution is simple: Just revert the commit.

Tim can recover his changes from source control when he gets back from his meeting and try again. If you can't (or don't) take responsibility for a broken build, and let everyone know that you're working on it, you should expect your commit could be reverted. Again, it's nothing personal...it's just the best thing for the team.

I think there's a sort of stigma associated with source control reverts. People think of it as destroying someone else's work. Sometimes this is hard, because often the thing that's breaking the build is a minor problem, and it's a mistake that we all make. But just as we've learned that refactoring isn't wasteful because it allows us to evolve our design, understand that reverting a commit isn't wasteful because it unblocks the team. And the changes don't go away...they're still in source control and easy for the original committer to recover. My suggestion is to keep this technique in your toolbox, and don't be afraid to use it. You should never be blocked due to a failing build.

MVC Isn't About Replaceable Parts

My continuing thoughts on MVC...

We separate models, views and controllers, because it decreases the cost of change. It does not, however, allow us to replace one these layers without changing the others. That's rarely practical. If it happens, that's great, but don't count on it. The same thing is true in thin clients. It's a nice idea to think that you can redesign your site simply by replacing your CSS and leaving your markup and javascript alone. Unfortunately, that's usually not the case.

We decouple our systems along these lines because over time we've found that these particular configurations create effective firewalls to halt the ripple effects of change. A harbor doesn't prevent all waves from rocking the boats, it just makes the big ones smaller. MVC and it's ilk make maintenance easier by reducing the cost of change, not creating a plug-replaceable system. Plug-replaceable systems are expensive and difficult to create, and you should only make one if you need it for a specific business reason.

By extension, if your domain causes changes to frequently occur in other parts of the system, decoupling those parts from the rest will decrease the cost. And while I'm not going to tell you to forget MVC (or Model-View-Presenter, or any other paradigm), be sure that the separations you create actually insulate changes that tend to occur on your particular project, and aren't just there because you think they should be.

Mouseless Firefox

Firefox's default keyboard shortcuts do a pretty darn good job of giving you everything you need to browse the web mouseless.

Backspace = Back
Shift + Backspace = Forward
Tab = Next Field (If you didn't know this one already...)
/ = Search Text
' = Search Links Only
F3 = Search Again

Once you've got a link selected:
  Enter = Open Link in current tab
  Ctrl/Cmd+Enter = Open Link in new tab
  Shift + Enter = Open link in new window

Spacebar = Page Down
Shift + Spacebar = Page Up
CMD + L = Jump To Location Bar (CTRL + L on Windows, I think)
Ctrl/Cmd+Tab = Switch tabs
Ctrl/Cmd+[1-9] = Select tab (1-9)

You can find the full list of firefox shortcuts here

My New MVC Metaphor: The Command Line

A useful metaphor for the MVC pattern struck me today: The command line. A command line prompt gives you all the elements of an MVC architecture.

The Models

On the command line, the model elements are the programs you execute. ls, grep, awk, cat, wget, etc... all of those wonderful tools that actually get things done.

The Controllers

The controller elements are the things you use to tie the models together. The pipes, the redirects, the ampersands. All of these things allow you to tie models together in an infinite number of different combinations to do what you want. The proportion of models to controllers in any given system (or command) is high. You want it to be mostly models with a little controller glue...but without the controllers, the models are nearly useless. The result of all of this, then, is:

The View

Standard Out. Of course, the command line only really has one native input/output format: text. But oh what a format it is.

And the last component...

There's one more component we haven't addressed in this equation, but I'll leave that as an exercise to the reader.

Kata:Ruby:Prime Factors

It took me a fair bit of refactoring after I got the last test passing (generate 10 ) to get it this tight, but I like it.

def generate(n)
  return [] if n == 1
  factor = (2..n).find {|x| n % x == 0} 
  [factor] + generate(n / factor) 
end