Noel Rappin Writes Here


Rails, Objects, Tests, and Other Useful Things

Objects, Rails, Ruby, testingNoel Rappin4 Comments

For the first time in quite a while, I’ve been able to spend time working on a brand-new Rails application that’s actually a business thing and not a side project. It’s small. Okay, it’s really small. But at least for the moment it’s mine, mine, mine. (What was that about collective code ownership? I can’t hear you…)

This seemed like a good time to reflect on the various Object-Oriented Rails discussions, including Avdi’s book, DCI in Rails, fast Rails tests, Objectify, DHH’s skepticism about the whole enterprise, and even my little contribution to the debate. And while we’re at it, we can throw in things like Steve Klabnik’s post on test design and Factory Girl

I’m not sure I have any wildly bold conclusion to make here, but a few things struck me as I went through my newest coding enterprise with all this stuff rattling around in my head.

A little background — I’ve actually done quite a bit of more formal Object-Oriented stuff, though it’s more academic than corporate enterprise. My grad research involved teaching object-oriented design, so I was pretty heavily immersed in the OO documents circa the mid-to-late 90s. So, it’s not like I woke up last May and suddenly realized that objects existed. That said, I’m as guilty as any Rails programmer at taking advantage of the framework’s ability to write big balls of mud.

Much of this discussion is effectively about how to manage complexity in an application. The thing about complexity, while you can always create complexity in your system, you can’t always remove it. At some point, your code has to do what it has to do, and that’s a minimum on how complex your system is. You can move the complexity around, and you can arguably make it easier to deal with. But… to some extent “easier to deal with” is subjective, and all these techniques have trade-offs. Smaller classes means more classes, adding structure to make dependencies flexible often increases immediate cost. Adding abstraction simplifies individual parts of the system at the cost of making it harder to reason about the system as a whole. There are some sweet spots, I think, but a lot of this is a question of picking the Kool-Aid flavor you like best.

Personally, I like to start with simple and evolve to complex. That means small methods, small classes, and limited interaction between classes. In other words, I’m willing to accept a little bit of structural overhead in order to keep each individual piece of the code simple. Then the idea is to refactor aggressively, making techniques like DCI more something I use as a tool when I see complexity then a place I start from. Premature abstraction is in the same realm as premature optimization. (In particular, I find a lot of forms of Dependency Injection really don’t fit in my head, it takes a lot for me to feel like that flavor of flexible dependencies are the solution to my problem.)

I can never remember where I saw this, but it was an early XP maxim that you should try to keep the simplicity 90% of your system that was simple so that you had the maximum resources to bear on the 10% that is really hard.

To make this style work, you need good tests and you need fast tests — TDD is a critical part of building code this way. You need to be confident that you can refactor, and you need to be able to refactor in small steps and rerun tests. That’s why, while I think I get what Gregory Moeck is saying here, I can’t agree with his conclusion. I think “more testable” is just as valid an engineering goal as “fast” or “uses minimal memory”. I think if your abstraction doesn’t allow you to test, then you have the wrong abstraction. (Though I still think the example he uses is over built…).

Fast tests are most valuable as a means to an end, with the end being understandable and easily changeable code. Fast tests help you get to that end because you can run them more often, ideally you can run them fast enough so that you don’t break focus going back and forth between tests and code, the transition is supposed to be seamless. Also, an inability to write fast tests easily often means that there’s a flaw in your design. Specifically, it means that there’s too much interaction between multiple parts of your program, such that it’s impossible to test a single part in isolation.

One of the reasons that TDD works is that the tests become kind of a universal client of your code, forcing your code to have a lot of surface area, so to speak, and not a lot of hidden depth or interactions. Again, this is valuable because code without hidden depth is easier to understand and easier to change. If writing tests becomes hard or slow, the tests are trying to tell you that your code is building up interior space where logic is hiding — you need to break the code apart to expose the logic to a unit test.

The metric that matters here is how easily you can change you code. A quick guide to this is what kinds of bugs you get. A well-built system won’t necessarily have fewer bugs, but will have shallower bugs that take less time to fix.

Isolation helps, the Single Responsibility Principle helps. Both of these are good rules of thumb in keeping the simple parts of your code simple. But it also helps to understand that “single responsibility” is also a matter of perspective. (I like the guideline in GOOS that you should be able to describe what a class does without using “and” or “or”.

Another good rule of thumb is that objects that are always used together should be split out into their own abstraction. Or, from the other direction, data that changes on different time scales should be in different abstractions.

In Rails, remember that “models” is not the same as “ActiveRecord models”. Business logic that does not depend on persistence is best kept in classes that aren’t also managing persistence. Fast tests are one side effect here, but keeping classes focused has other benefits in terms of making the code easier to understand and easier to change.

Actual minor Rails example — pulling logic related to start and end dates into a DateRange class. (Actually, in building this, I started with the code in the actual model, then refactored to a HasDateRange service module that was mixed in to the ActiveRecord model, then refactored to a DateRange class when it became clear that a single model might need multiple date ranges. The DateRange class can be reused, and that’s great, but the reuse is a side-effect of the isolation. The main effect is that it’s easier to understand where the date range logic is.

I’ve been finding myself doing similar things with Rails associations, pulling methods related to the list of associated objects into a HasThings style module, then refactoring to a ThingCollection class.

You need to be vigilant to abstractions showing up in your code. Passing arguments, especially if you are passing the same argument sets to multiple methods, often means there’s a class waiting to be born. Using a lot of If logic or case logic often means there’s a set of objects that have polymorphic behavior — especially if you are using the same logical test multiple times. Passing around nil often means you are doing something sub-optimally.

Another semi-practical Rails example: I have no problem with an ActiveRecord model having class methods that create new objects of that model as long as the methods are simple. As soon as the methods get complex, I’ve been pulling them into a factory class, where they become instance methods. (I always have the factory be a class that is instantiated rather than having it be a set of class methods or a singleton — I find the code breaks much more cleanly as regular instance methods.) At that point, you can usually break the complicated factory method into a bunch of smaller methods with semantically meaningful names. These classes wind up being very similar to a DCI context class.

Which reminds me — if you are wondering whether the Extract Method refactoring is needed in a particular case, the answer is yes. Move the code to a method with a semantically meaningful name. Somebody will be thankful for it, probably you in a month.

Some of this is genuinely subjective — I never in a million years would have generated this solution — I’d be more likely to have a Null Object for Post if this started to bother me, because event systems don’t seem like simplifications to me.

I do worry how this kind of aggressive refactoring style, or any kind of structured style, plays out in a large team or even just a team with varying degrees of skill, or even just a team where people have different styles. It’s hard to aggressively refactor when three-dozen coders are dependent on something (though, granted, if you’ve isolated well you have a better shot). And it’s hard to overstate the damage that one team member who isn’t down with the program can do to your exquisite object model. I don’t have an answer to this, and I think it’s a really complicated problem.

You don’t know the future. Speculation about reuse gains and maintenance costs are just speculation. Reuse and maintenance are the side effect of good coding practices, but trying to build them in explicitly by starting with complexity is has the same problems as any up-front design, namely that you are making the most important decisions about your system at the point when you know the least about the system. The TDD process can help you here.

May 9, 2012: The Random Link Post Returns

JavaScript, Music, RSpec, Ruby, Self PublishingNoel RappinComment

And now, the return of the semi-occasional link post. I’m going to try to do this at least once a week, but who knows.

If you are writing JavaScript, you should be looking at Justin Searls and his JavaScript testing tools. Justin posted the slides for what looks like a great talk on JavaScript testing. These slides made me happy.

In random media sales, the audio book of World War Z is on sale for a mere six bucks.

A couple of Ruby posts. Steve Klabnik argues that merely splitting code into modules doesn’t reduce complexity. Instead he argues that you need encapsulation. I think splitting code is probably better than nothing, but not a lot better.

Meanwhile, Avdi Grimm describes the Ruby idiom for type conversion which I have to admit, I never thought of as an idiom before.

In a story that I think of as a cautionary tale about pricing and value, the LA Times writes about the history of American Airlines customers who bought unlimited tickets. And then, you know, they used them, unlimitedly.

I always like to see plucky programmers trying to self-publish books about testing. So I’m glad that Aaron Sumner is LeanPubbing a book on testing Rails and RSpec. Good luck, Aaron!

Pretty much everybody who blogs or writes or tries to explain things to people should read this XKCD

Finally, a random music recommendation. I don’t recommend music much, but I do have a weakness for lyric-heavy, earnest, catchy music. Which brings me to the Lisps and their recent musical project Futurity. The musical is a Steampunky kind of thing that concerns a Civil War vet who tries to build a “Steam Brain” with the help of Ada Lovelace. It’s clever and I like it. Album Link. On a similar vein, their song Singluarity from their previous album Are We At The Movies.

July 15, 2011: Stale Links

Amazon, Ruby, RubyMine, Twitter, Uncategorized, iPadNoel Rappin2 Comments

The problem with sitting on these daily link posts is that the links go out of date. Sigh. Here are some links.


I found a couple of things about this InfoQ article about Twitter’s infrastructure odd. I was expecting it to be a bit more of a Rails hit-piece, frankly, so it was nice to see a quote like this one from Evan Weaver:

I wouldn’t say that Rails has served as poorly in any way, it’s just that we outgrew it very quickly.

Twitter has unique needs, so it’s not surprising that the Rails stack doesn’t serve them anymore, but they did get pretty far with the Rails stack.

This was interesting – first, from Charles Humble, writing the article:

You might assume that the move to the JVM was largely driven by performance and scalability concerns, but in fact the existing Twitter codebase performs well… Rather, the move to JVM is driven as much by a need for better developer productivity as it it for better performance

And this from Weaver:

As we move into a light-weight Service Oriented Architecture model, static typing becomes a genuine productivity boon.

The author concludes the article with this:

[Rails] does however come with well known costs, both in terms of performance and scalability, and perhaps also the relative maturity of the libraries and tool chain. In addition, the experience at Twitter suggests that the Ruby on Rails stack can produce some significant architectural challenges as the code base grows.

Which strikes me as an overgeneralization of what Weaver said – I’m almost willing to believe that static typing is a benefit if you are doing SOA at Twitter’s scale, but I haven’t seen the benefit on smaller projects in my experience.


As somebody who got their Amazon Affiliate account zapped when Amazon pulled the rug out from under Illinois residents, I was following with some interest the similar news out of California. (Although not quite identical, I had several months notice).

There’s been a little bit of confusion on what actually happened – a lot of people seem to think California is trying to tax affiliate revenue (I can’t find the link, but I saw someone argue that their affiliate revenue was already being taxed so shouldn’t be taxed again, which is wrong in a couple of different ways.) Slate magazine has a decent overview, which I’ll note I basically agree with on the substance of the issue.

Current law is that online transactions are only subject to sales tax if the company involved has a physical presence in the state. The California law defines “presence” to include any affiliates who get a payout – the affiliate revenue isn’t taxed as such, but the existence of an affiliate means that other Amazon transactions in California would be subject to California sales tax. Amazon responded to the law by canceling all their affiliates in California, as they did in Illinois, to avoid having to charge sales tax, and also to avoid having to calculate and manage sales tax, and also to avoid a court case that they might well lose.

Anyway, you may agree or disagree with the California law – though it doesn’t seem inherently any less silly than the various state laws that impose income taxes in visiting professional athletes. For my part, I don’t understand why the fact that Amazon has put themselves in a position where paying sales takes kills their business model should be my problem – I understand why there was an initial push not to charge sales tax on the internet, but I think the social benefit of privileging on line sales has probably passed. Even if you don’t agree with that argument, though, it’s hard for me to see how Amazon using their affiliates as pawns is the best or most responsible way for them to be advocating their case.

New additions to the workflow

I’ve got a couple of new writing workflow things to mention. There’s a new app in the Mac App Store called Marked, which is a classic “One Thing Well” deal. For $2.99, it’s basically a Markdown preview window, but has the very useful feature that it will live-update a file you are editing every time you save. So it’s basically adding MarsEdit’s preview window to any editor. It also makes it easy to copy the resulting HTML into the clipboard if you, say, want to post it to WordPress. It also lets you change the Markdown processor if you’d like. It’s nicely handy for $2.99.

On the iPad side, WriteRoom has finally been updated to a universal app. It’s effectively PlainText Pro – the same basic (pretty) layout with a couple of extra features. It’s got an easy to configure extra keyboard row, and a couple of other handy features. My main negative is that, when the app is in landscape mode it doesn’t use all the horizontal space for text, that’d be a useful option. One thing I like about it, relative to other editors is that it live-syncs with Dropbox, giving much more of a feel of directly editing the Dropbox file than the other editors that make you download the file locally and manually sync. Overall, though I like it.

I also tried out an iPad app called Daedalus, which has a very interesting UI metaphor but doesn’t really fit with the way I manage files. If you are willing to do all your notes and writing in it, though, the organization looks like it might be handy.

RubyMine 3.2

Quick mention that RubyMine 3.2 is out, with support for Rails 3.1 features like the asset pipeline and CoffeeScript. Mostly, I’m having some stability problems with it (it tends to freeze up for me), but the editor and its interaction with Rails continues to get better.

Avdi on Law of Demeter

Finally, speaking of things I thought I was going to disagree with, but wound up agreeing with almost completely (and also speaking of week-old links…), here’s Avdi Grimm on the Law of Demeter. Avdi comes down on the side of actually useful guidelines for managing chains of method calls.

Aug 30, 2010: Rails 3 has landed

Obtiva, Rails 3, RubyNoel RappinComment

Top Story

As you probably know, both Rails 3 and Bundler went final over the weekend. The Rails 3 release notes are up, as well as extensive coverage on the Rails Guides page. I'll also mention Jeremy McAnally's Rails 3 Upgrade handbookhttp, and Gregg Pollack's list of great Rails 3 documentation sources. And, just for the hell of it, here's the post I wrote back when Rails 3 was first announced. Somehow, this is not the first Google result for the phrase "Merby Overlords"

In other news

I do mean to write about Obtiva's Master Class with Alistair Cockburn, but that's going to take way more concentration than I can muster this morning. For the moment, it's enough to say that it was fun, interesting, and enlightening.

In honor, this link that Alistair tweeted over the weekend, the Half-Arsed Agile Manifesto. Anybody who doesn't recognize themselves in that a little bit has never actually tried Agile.

Link Out

By the way, I loved doing the post based on search engine entries into the site... you'll see that again, as it was relatively easy, kind of funny, and marginally useful, and that's pretty much what I aspire to.

If you're into programming abstractions and/or you want to learn about Lisp, Magnus Holm has an introduction to S-Expressions for Rubyists.

And if you are into crazy Ruby metaprogramming, Lance Pollard has a long look at instance_eval. It's nice to see a metaprogramming example that's actually motivated from a use case.

Highly prolific conference blogger Jake Scruggs was at RubyKaigi this week, here's day one of his report. Day two. Day three.

August 26, 2010: Some New Stuff

JavaScript, Ruby, WindyCityRails, Yehuda, rvmNoel RappinComment

Book Status

RSpec chapter draft handed in to edit. It's going to need a better conclusion. A lot changed in this one, relative to the Lulu version -- this is probably the chapter most affected by my own personal experience since it's original version.


Haven't done a link set in a while, this is going to be kind of random.

Still seats available for both WindyCityRails in general, and for my tutorial in specific. But the sponsor list has filled up.

Motorola bought 280 North, best known for their Cappuccino JavaScript framework, and the 280 Slides application. Apparently, Motorola plans to use them to make web apps aimed at Android devices. Should be an interesting culture clash.

I've been looking through the Rails 3 unobtrusive JavaScript stuff trying to figure out new practices. The Trevor Turk blog has a code snippet for setting up a form that submits when a checkbox is clicked. Like it. Love to see more examples like this, it really shows how clean the Rails 3 structures will be.

Ever wish the Ruby Date and DateTime classes were faster? Course you have. Here's home_run, a C implementation of the Date and DateTime classes that claims a 20 - 200 time speedup. The Readme page shows how to use the home_run classes instead of the standard ones, if you are feeling adventurous.

I love stories of tracking down obscure bugs, and Yehuda Katz has a great one about bundler, rvm, and various shell interactions. Debugging is maybe the important skill, so watch an expert's process at work.

Speaking of rvm and it's awesomeness, here's a quick guide to putting rvm, bundler, and passenger together on a Rails deploy.

Here's a little test snippet to solve the problem of how to test an abstract controller by adding a small controller in the test page and creating a route for it.

August 11, 2010: An Abundance of Options

Ruby, WindyCityRailsNoel Rappin4 Comments

Book Status

Shoulda chapter fixes made. The next decision is whether to push that as a beta by itself, or wait until the RSpec chapter is also done.


Today is the last day to get early bird pricing for WindyCityRails.

Book Status

I did not know that Ruby 1.9 had its own coverage tool. Aaron Patterson shows how to use that tool and a little code to create useful output for coverage testing.

I'm really happy to see some discussion of what good style is for Cucumber tests. Jonas Nicklas argues in favor of what I call in the book the implicit style of testing. He closes with "A step description should never contain regexen, CSS or XPath selectors, any kind of code or data structure". I think that's got it right. I was just deciding not to add a Cucumber/Factory add-on to my project and decided not too for reasons articulated pretty well by Jonas. The goal of Cucumber is not to write as few step-definitions as possible.

Dane Harrigan discusses handling Rails exceptions from Ajax calls. It involves what may be the first actual use case of an around_filter I've ever seen.

Xavier Shay argues that database constraints make it easier for new developers to understand your code. Hmm... I tend to be not a fan of database constraints. Or more accurately, I tend to be very cognizant of the development costs of adding database constraints, so I only add them when they seem necessary. It's hard to argue, though with the idea that the code and database should not actually conflict.

The Silence is Foo blog gives an almost obsessive amount of love to the splat operator. Yay! The splat operator is one of my favorite corners of Ruby (as it was one of my favorite corners of Python). Even so, I learned a couple of new splat tricks from this article.

I'll close here with a little debate on choices in Ruby and Rails. Kevin Gisi has a satirical little number on how hard it is to be a new Ruby developer and choose among the various options for everything. Peter Cooper at Rails inside offers not a rebuttal exactly, but a slightly different take on the issue. Kevin is obviously writing tongue-in-cheek, so you can't exactly get worked up about him going overboard, and I agree with Peter's take that things could be improved with better presentation. I do think that both Ruby and Rails have gotten a bit less novice friendly (as many projects do over time as complexity gets added). I don't think it's an unsolvable problem, but we can always make it easier for new people to come on board.

July 30, 2010: I Always Thought It Was An Animal Native To The Rain Forest

Bundler, Cucumber, Ruby, Time, Vim, Yehuda, unixNoel RappinComment

Book Status

Beta 5 came out on Wednesday. Currently trying to figure out how to structure the Shoulda chapter in light of the direction that project has gone in since I wrote about it for the Lulu book.

Friday Links

One significant change in Rails 3 is that, because of the way Bundler works, the code for your gems is not part of the project. And if you are using RVM, each project might have a different gemset, and different directory to find those gems. Brian Cardarella has a simple script that will open a new tab in your terminal window and take it to the gem directory for the current project. OS X only, because it uses AppleScript. I will use this.

Mike Burns from Thoughtbot gives us a just-so story for the digital age, How grep got its name. I always thought it was the sound you make when you try and figure out how to use it, "Oh Grep!"

Derek Kastner of Brighter Planet has an interesting look at how to use more advanced features of Bundler to to manage gem dependencies when building a gem, and creating the gemspec. Definitely something I would not have figured out on my own.

Matt Aimonetti, after doing a little Ruby memory quiz/rant on Twitter last night has published a longer blog post about Ruby's object allocation. This is interesting, and makes me wonder if it would be possible to build a Ruby runtime optimized for long-running processes. Still, make it work, make it right, make it clean, only then make it fast -- it's much easier to optimize clean code.

Louis Rose has a short snippet or three on using Timecop and Chronic to manage time-based Cucumber scenarios. Read through to the updates to avoid a couple of gotchas. Chronic, by the way is one of my favorite gems to use in projects, because clients often like the demo of being able to type in "next Tuesday" in a date field.

Finally, Yehuda Katz has what is maybe the first "I switched to Vim" story that makes me actually think about switching to Vim. Seems like a useful approach and set of tips.

July 21, 2010: This Code Belongs In A Museum

Apple, Rails, Ruby, iPadNoel RappinComment


Not much to tell, really. Spent some time getting RVM set up, since I think I'll need it to manage simultaneously building the Rails 2 and Rails 3. Now I have a working version of the startup appendix that uses Rails 3 and Devise. I can't speak to using Devise in practice yet, but the immediate goal of making the setup less complicated was definitely accomplished. The big question now is how much to support Rails 2 in the walk-through chapters. I'm leaning toward just having the walk-through chapters be Rails 3 with only occasional notes on how Rails 2 differs.


Apple has allowed the code for the 1984-era MacPaint and QuickDraw to be released to a museum where anybody can download and peruse. QuickDraw is all in assembler, and MacPaint is a mix of Pascal and Assembler. At a quick glance, the striking thing about the MacPaint Pascal is that it actually seems quite readable. The layout is consistent, it's commented, variable names have meaning, that kind of thing. Certainly miles ahead of any Pascal code I wrote back when I wrote Pascal code...

This is kind of a cute way to find hidden puts statements by raising exceptions. The project I'm on actually monkey patches puts to add a line to the output saying what file and what line of code the put statement is on. Surprisingly useful.

Claudio Maral has a couple of examples of cleaning up controller code by moving logic to the model.

Oh -- Droptext got updated. It's a universal iOS app for 99 cents that lets you edit files on Dropbox. This release, I think, makes the app functional. Some crash bugs were squashed, and you can now specify alternative text extensions. It's still pretty simple (I'd love to be able to change the display font, and I'd really love TextExpander integration), but it works and I'll definitely be giving it more of a spin.

The Ruby Hoedown has announced its speaker list for September 3 and 4. I've never been, but I've heard good things, and you won't find a major conference that's less costly.

July 19, 2010: Building a Legacy

RSpec, Ruby, testingNoel RappinComment

And Now A Word

The schedule for WindyCityRails 2010 just came out. WindyCityRails is Saturday, Sept, 11 at the Westin Chicago River North.

I will be running the PM tutorial session on "Testing in a Legacy Environment". I am frequently asked how to start testing on a pre-existing code base with no tests. In this session, we'll start with a made-up "legacy" code base, and discuss techniques for adding tests, and fixing bug, and adding new features in a test-driven way.

I'm excited, and I think it's going to be a fun and useful session. WindyCityRails is an extremely well done conference, and you all should check it out. There's an early bird registration price, which is good until August 1st. You can register here.

I hope to see you there.

Book Status

The legacy chapter draft heading to editor today. Next up is probably the Rails 3/Devise instructions and tutorial updates. The book is still available for purchase in beta, and for pre-order on Amazon.


Via Corey Haines, here's an interesting mini-essay on refactoring and cleanup from J. B. Rainsberger on the TDD mailing list.

I'm putting this link here so that I never have to do a Google search for HTML entity definitions ever again. (Via larkware).

Another "Why I Like Ruby" essay, this one from Rob Conery.

Alex Chaffee from Pivotal Labs has an RSpec add-on that shows you the exact location where an expected string differs from the returned value. If you have ever tried to track down string issues in a long string where the spacing turns out to be different 150 characters down the line, this will be a good thing to have around.

James Golick released two gems that help in production deployment of new features. The rollout gem helps limit a particular feature to a subset of users, even allowing for quick de-activation of a feature if needed. As a companion, the degrade gem allows you to automatically remove a feature (or trigger other behavior) when a certain number of errors are triggered.

July 15, 2010: An Apple Comment A Day

Apple, RubyNoel RappinComment

Book status

Still writing the legacy chapter. Totally coincidentally, Michael Feathers, author of Working Effectively With Legacy Code, just wrote on an issue similar to what I'm dealing with right now: The Bad Code Kata. I imagine Feathers had a similar problem when writing his book about legacy code.

An Apple Comment A Day

So Apple is apparently holding a press conference Friday about iPhone 4, although they haven't officially confirmed that it's about the antenna issue.

By the way, I keep seeing dark speculation about why early reviewers of the phone didn't see this issue. Though I do think the tech press isn't always pure, I don't think you need to invoke a conspiracy in this case. I assume that since the phone was in an NDA that it was being used in a case a large percentage of the time to hide it, which by most accounts sharply reduces the issue. Also, Mossberg's early review did mention an intermittent service drop (3rd and 4th paragraphs from the end) -- he just wasn't able to diagnose it. Which doesn't excuse Apple from finding the problem, just means we can probably rest the conspiracy talk in this case.

As for me, I still can't get over how great the screen is, but I think my expectations got raised too high on the still camera -- I'm getting more grain than I expected in places that I wouldn't have considered low light. Still, it's a big improvement. As I said, I can reproduce the antenna issue, but it hasn't yet been a practical problem for me.


Josh Owens has a short but sweet post on how to pick an open source tool when there are multiple options available.

Here is a slide show on how enumerators work in Ruby, it comes from a talk by Rein Henrichs, but is pretty easy to follow even without the speaking.

Antony Marcano has a brief historical anecdote on the history of the term Waterfall as applied to software.

July 14 2010: The Smallest Thing

Obtiva, Ruby, TeachingNoel Rappin5 Comments

Book Status

Still working on the legacy chapter. The sidebar here is that deliberately writing bad legacy code for purposes of using as examples in a book is a little challenging. It's got to be tangled enough to make the point that it's hard to clean, but small and clear enough to work in the context of a book example. My tired brain was fighting it last night.


I mentioned this recently, but I want to mention it again. I'll be teaching Obtiva's Advanced Ruby on Rails course Aug 30 - Sep 2. This is going to cover a lot of non-novice topics. We'll be building in Rails 3 and (I hope) Ruby 1.9.2, and covering security, performance, rich experience tools, deployment, and the like. It's a new course, and I'm excited to put it together. I'll most likely be quizzing early registrants to determine exactly what to cover. Follow the link and enter your information on the form.

The Smallest Thing

So I was talking yesterday, and later twittering, about the smallest issue that I might see in a potential candidate's code sample that would almost disqualify that person in my eyes.

My first answer to this for Ruby is 4-space indent. Because it's totally trivial on the one hand, but on the other goes against an extremely well-established community norm, indicating that either the person isn't engaged with the Ruby community or is really, really stubborn. Neither of these is a recommendation.

Other people suggested different things -- here are some of the most trivial:

@wxwill said "for and while loops". Yeah, that would be an issue for me as well, same reason.

@aberant: suggested STATEMENT rescue "". I might give somebody a pass if that was used reasonably once, but it would look weird in a code sample.

@johnashenfelter suggested Hungarian notation, which would probably disqualify a developer for me in almost any language that was not actually C. He also suggested CamelCase, which would also act like four-space indent for me.

@mileszs mentioned explicit return statements. I sort of agree, although I see that as less of a problem than some of the others, in part because it's easy for an explicit return to slip into code, at least for me. I find when teaching Ruby that this particular community quirk is particularly hard to justify to people coming from, say Java. To them, it feels like deliberate obscurity. Though I think once you get the hang of expression-based Ruby, it seems perfectly natural.

July 13, 2010: I Guess It Isn't A Dynabook Yet

Alan Kay, RSpec, Ruby, iPhoneNoel RappinComment


Back to link posts today. The book is still lurching forward on the legacy chapter. Thanks to those couple of you that asked questions on the forum and made it look a little less lonely over there.

Quick Review

Quick iPhone 4 impressions, but understand that I haven't actually, you know, used it yet, just took it home and set it up.

  • The screen sharpness really is notice able. It's amazing how small text can get and still be basically readable. Apple's also updated the system font and a couple of the dingbats, and it looks really nice.

  • My first FaceTime call froze five seconds in. It was cool for that five seconds, though.

  • I like the physical look of it, but haven't yet gotten over the "hey, it's glass, be careful reaction". I haven't seen the antenna issue, but then I haven't been on 3G much yet, and I'm not lefty.

  • I have to get used to the multitasking and the idea that I can sometimes switch between apps without going back to the home screen. I wonder how hard that'll take. I was also very used to my first page, and as much as I'm glad I can organize things, not used to it yet.

  • Weirdest design decision I've seen so far: iBooks for epub has really too wide margins and as far as I can tell, now way to fix.


John Petersen has a brief comparison of some .NET and Ruby code. It's interesting especially for how much he's eventually able to clean up the .NET code. That suggests to me that at least some of Ruby's power is in the community standards for clean code. (Note to self: make a list of favorite Ruby features some day)

Dave Chelimsky has two more posts on RSpec 2, this time some changes in how the generators work. Part 1 and Part 2. At this rate, I'll be able to update the RSpec chapter soon.

Envy Labs has a new screencast up about LiveReload, which lets you update JavaScript and CSS during development without updating an entire page.

Jeff Kreftmeijer has a nice example of cleaning up a test base with Timecop.

Mark Guzdial writes a little bit about the iPad as a paper replacement versus something that goes beyond paper. Be sure and scroll down for Alan Kay's comment about whether the iPad is his Dynabook (Spoiler alert: He thinks it's too consumer package software oriented and doesn't let people write code on it.) I wish that Apple had let Scratch in to iOS, that would be really cool.

July 1, 2010: Screencasts and Road Maps

Kent Beck, Passenger, Ruby, autotestNoel RappinComment
A lot fewer links today. Yesterday, by the way, the most clicked on link was the "Don't do this" like to the method_missing nil post.

Book Status

Handed another draft of the Rcov and Style/Test Quality chapters in. Expecting that to be the next beta next week, but we'll see.


Kent Beck has a screencast series on TDD from Pragmatic. I linked to the rough version of this some time back. Haven't gotten the time on this yet, but expect a fuller review later on.

BJ Clark has an essay on whether acceptance tests should be written by developers or by interaction designers. Classic XP is pretty clear that customers should be involved in this process, but that's not often feasible in reality.

Tim Bray proudly announces that he has never learned the precedence rules in any language he's used. I am in complete agreement with this -- the only reason I know the Ruby ones is from writing about them.

Ryan Davis asks about having a special refactoring mode to change Autotest behavior after failing tests pass. My first impression is that this proposal might be too fiddly, but I think there's something in the basic idea.

Two recent posts about large code bases caught my eye. Sandy Walsh, from January, and Michael Feathers, from this week.

Part 2 of the Teach Me To Code Rails 3 screencast is up.

Finally, the Phusion team has another road map article, including a Passenger light that can be used in development from the command line as you use mongrel or thin. And other deployment features, as well. Cool.

June 30, 2010: The Triumphant Return of the Monster Link Post

Cucumber, Don Norman, Rails 3, Ruby, Shoulda, Steve Martin, UXD, iPhone, rvm, writingNoel RappinComment

The end of the repair story

At the end, a very positive experience with Apple support. The repair was free, done when they said it would be done, and all told, I spent less than fifteen minutes in the store between both halves of the visit. Plus, they replaced the top part of my pre-unibody MacBook, which was worn down and discolored from my gunky hands, almost as though they didn't want an ugly Mac in the field.

Book Status

With the laptop back, I'm back to work, last night going back over the Style chapter. I think now the plan is to do a slightly smaller next beta that would get out next week, just the Coverage and Style chapters, with the next batch, probably the Legacy and redo of the startup example coming shortly on its heels.

Also, the book has somewhat quietly shown up on Amazon and, I presume, other online outlets.

Of course, the beta is still available at PragProg.


Many, many links, as I catch up on an entire week's worth.

Thoughtbot announces that factory_girl is now split into a separate Rails 3 gem, in much the same way that Cucumber and RSpec are.

Also in Thoughtbot-land, the should_change command has been deprecated from Shoulda.

Jeremy McAnnaly announces the 2010 Ruby Hoedown, after some rescheduling due to the Nashville flooding. Again, it's the low, low, price of free. I'm hoping to break my 0-for-2010 streak on conference proposals with my submission.

Everyday Rails has a good post about getting Rails 3 and RVM working together.

I haven't watched this video yet, but a little Don Norman is a good thing, right? (via Joel Spolsky)

Test Inline is a Ruby library from Eric Anderson to put tests in the Ruby source file. Eric freely admits that this is an experiment, which is good because my experience with this kind of tool (Python doctests) is that it gets messy pretty quickly.

Ever think that Lemmings would make a great iPhone game? Me too. Also, the people who have the rights to the code. Coming soon.

I love Steve Martin. He's posted the rider for his tours. A sample: "BUFFET ... Six-packs of any canned beverage for Steve to compare his abs to."

I've been waiting for this: Lifehacker posts some Handbrake presets for iPad and iPhone 4. Seem decent, but a bigger file size than what I had been doing.

Please don't do this. It's a bad idea and will make your code harder for other Ruby developers to maintain.

Two from David Chelimsky: Having a topic branch when contributing to git projects, and a change in how views are handled in controller tests in RSpec 2.

I really need to watch this presentation from RailsConf on Beautiful Markup by John Athayde.

Speaking of RailsConf, here's a retrospective from John Trupiano of the BohConf "unconference" that happened alongside.

Dan Ingalls was one of the people behind Smalltalk 80, here's an interview with him.

Over at Teach Me To Code, a screencast about setting up a Rails project and writing the first Cucumber feature.

Still in Cucumber, Michael Orr shows how you can use an instance variable to track objects in a Cucumber test. I do this a lot, myself, although I'm not completely convinced that you get a cleaner test suite at the end.

Rands has a great post about his writing process. I love that everybody does this a little differently, although calling what I do a "process" is probably a little much.

Paolo Perrota, author of Metaprogramming Ruby, has a nice note about how great the Ruby community is.

UxMyths seems like a useful site to browse.

Speaking about great writing, I loved, loved the opening of this article by Adam Keys about why he always comes back to TextMate. Also some good comments. I hadn't thought of the issue exactly this way, but it makes perfect sense.

The Time of Day gem lets you treat ActiveRecord time columns without their date information for certain kinds of comparisons.


I think I mentioned that I did a talk at Refresh Chicago last week. It was fun, but we think turnout was down due to the tornado warning over Chicago that night -- it's possible the sirens acted as a deterrent. Well, video of that is not up, but here's a video of the storm that night, featuring lightning striking three Chicago skyscrapers at the same time.

June 18, 2010: Links Ahoy

Monopoly, MySql, Ruby, rvmNoel RappinComment
I think a link post today...

Book Status

Still working on the style section, for some reason it's going grindingly slow. The plan for beta 4 is the new style chapter, probably the legacy coding chapter. Also on the slate is updating the sample app to use Devise, which had a large constituency when I floated the idea the other day.

Oh, and I haven't had the link up in a while. Buy the book here.


Jim Neath at the Purify blog has five plugins to help optimize MySql queries in your app. Cool.

Gregory Brown has an update on the Ruby Mendicant University.

This has nothing to do with Ruby. It's what is believed to be the shortest theoretically possible game of monopoly...

I feel like if I get the hang of RVM, Gemsets, and Bundler, then my life will be a lot easier. This post from Brian Cardarella seems like a good start.

And Jeremy McAnally has a short gem that lets you specify that some tests should be skipped un some environments.

June 8, 2010: iPhone, iPhone, it's off to work iPhone

Neil deGrasse Tyson, Rails, RailsConf, Ruby, iPhoneNoel RappinComment

Okay, There's a New iPhone

Don't really have a whole lot to say beyond what's already been said. It looks very slick, and if anybody can actually pull off getting people to use video chat, it's Apple. The form factor of video chat from a phone seems at first glance to be significantly better than from either a laptop or the iPad, in that it seems easier to hold the phone in a position to get a good angle. And as much as everybody is kicking around Google vs. Apple, it sure seems like the company that lost big was Flip. (Oh, and I'm not the first person to say it, but there's now flash on the iPhone... well, an LCD flash for the camera, at least.)

And a new Safari

Safari 5 was released with a lot less fanfare. Big new features include an extensions system similar to Chrome, which will fully launch later this summer. There's also a nice Reader function which is similar to the Readability bookmark. So far, I find it very pretty, a touch flakey about what sites it decides to pop up on, and downright magical at automatically following next links to stitch together a multi-page article. It also adds support for a bunch of HTML 5 features and a new JavaScript engine.


All the RailsConf keynotes are being live streamed at

Feature Flipper is a simple little gem to allow you to semantically tie certain features to certain environments, making it easy to have a specific feature live only in development until it's ready.

Oddly, this came up in conversation just yesterday. Chris Lowis points to a number of full Rails apps that are open source and can be used to learn how Rails apps are put together.

Quick snippet -- an Array#only method for when you know an array only has one element. I think I would actually use this.


Neil deGrasse Tyson, speaking off the cuff on a rant subject near and dear to my heart, namely how it's socially acceptable for otherwise lovely people to say "I'm no good at math".

June 4 2010: Okay, here's a link post

JRuby, Rails 3, Ruby, RubyMine, YehudaNoel RappinComment
Quick links post:

Gregory Brown is looking for comments and donations for a proposal for a Ruby Mendicant University, basically a rolling online Ruby course.

Charles Nutter is interviewed by InfoQ on the state of JRuby.

Yehuda Katz has a long post on various kinds of extensions in Rails 3 -- gems, plugins, generators. This one I need to look at in some detail.

The new RubyMine 2.5 beta integrates with Pivotal Tracker. Looks like you can tell RubyMine what story you are working on and it will tag your source control comments. Cool.

Book Status

Working on the style/quality chapters, integrating material from the ChicagoRuby talk. Probably not a beta next week, but maybe the week after.

May 28, 2010: Friday Friday Friday

Chicago Ruby, JQuery, Metaprogramming, Obtiva, Plugins, Rails, Rails 3, RubyNoel RappinComment
Short today, but preparing some longer, more rant-y bits for the future...

Book status

Not much forward motion for the next few days, as I have a lot of other stuff to do, including preparing for Chicago Ruby on June 1 and doing a bit of touch-up on Obtiva's 4-Day Ruby on Rails/TDD boot camp. All fun, but time consuming.

Some Links

A quick tutorial by Peter Cooper on setting up JQuery in Rails 3.

This isn't the first time I've seen something like this, but this article by Alan Skorkin on Ruby Procs and Lambdas is well done and it's worth refreshing from time to time.

We always say that Ruby methods can't have spaces in them, but technically that's a lie, as shown in Joon You's screencast.

Rails Dispatch this week is by José Valim. It's kind of rambling, but a very interesting look at plugins that mess with Rails 3 features like Responders and Generator.

May 27, 2010: Random stuff today

Chicago Ruby, Cory Doctorow, Merlin Mann, RailsRx, Ruby, Superman, TextMateNoel RappinComment
I think we're going to be even more random then usual today. Here goes:

If you downloaded the epub version of Rails Test Prescriptins beta 3, then you may have noticed that the promised Cucumber chapter isn't there. The PDF is fine, and I have no idea about the mobi version one way or another. If you were affected by this, please go back to the Prags site and grab the file again, it appears to have been fixed.

I'll be at Chicago Ruby on June 1 at 6 PM -- see link for details. Free pizza!

Matt Aimonetti claims that this tweet from Matz says that Perlisms like $/ might be removed from Ruby 2.0. Okay...

Merlin Mann weighs in with his favorite TextMate themes and a couple of cool bundles. I'm not normally a fan of light text on dark, but I give it a try every now and again.

Brief review of Cory Doctorow's For The Win: Interesting setup, Cory does a good job explaining the economics and setting up the characters. He's really trying to change the world here. Ending of the book is interesting, not completely satisfying. If I get time, a longer review coming somewhere.

My friend Mark Tyler Nobleman, author of Boys of Steel, which is an awesome kids biography of Superman's creators Jerry Siegel and Joe Shuster, announced that he has a contract for his next book about longtime Batman writer Bill Finger. Yay Mark!

May 25, 2010: Betas

Git, Podcasts, RDoc, Rails, RubyNoel Rappin1 Comment

Top Story

Beta 3 should be out today. The main change in this Beta is the inclusion of the Cucumber chapter, which has been updated both in terms of new tech, and also in terms of conclusions about how to use Cucumber.

And In Rails news...

When last we met, Rails 2.3.6 had just been released. Well, in the intervening 24 hours, we've bumped all the way to 2.3.8, with two bug fix releases, explained by Jeremy Kemper here and here. I don't know why the patch releases weren't numbered and -- they've gone that route before. Anyway, enjoy.


This seems a good time to point to Mike Gunderloy's historical list of Rails release dates. Confirming that Rails was pre 1.0 when I first saw it, was in the transition to 2.0 when I went to Pathfinder, and was in 2.0.2 when the Wrox book came out.

And then

I'm scheduled to be interviewed for the CoderPath podcast today, currently trying to confirm the time.

Here's a call for combining RDoc and RSpec. Hmm... having used Python's doctest, which is similar in goal, I'm skeptical. My sense was that the doctest things wound up being gunky enough that the file got hard to read.

Want to read Scott Chacon's Pro Git book for free on your iPad? Sure you do.

This is a couple days old, but here's Avdi Grimm with a nice little piece on Ruby's Tempfile class.

The projects for the Ruby Summer of Code were announced. Looks like a good range of useful stuff.