Noel Rappin Writes 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.

August 24, 2010: Um.. Hi?

RSpecNoel Rappin1 Comment
It's very easy to let this blog habit slip through your fingers. You go from, "put something up every weekday", to "nobody reads this on Friday", to "I'm tired this mornng", to "wow, I haven't posted in a week, and nobody noticed, why post today". Anyway, here's a post.

Book Status

Beta 6 came out last week. I'm now going through the RSpec chapter, which is taking longer than I thought. It's not just because of the changes between RSpec 1 and RSpec 2, though tracking down those changes has been part of it. It's also that it's been about 18 months since I wrote the Lulu version of the chapter. In that time, I've used RSpec a lot, and used it differently than I had before, so a lot of the tone and conclusions of the chapter need to change. Anyway, if I get lucky and there's a strong tailwind, the draft will be done today.


I assume that everybody reading this knows that since the last time I posted, new versions of Ruby (1.9.2 final), Bundler (1.0rc6) and Rails (3.0rc2) are all out the door. I really wish I had some time to play with Ruby 1.9.2. I think it's probably not appropriate to have the fake legacy app for my WindyCityRails tutorial (tickets still available...) be in Rails and Ruby 1.9.2. Probably not a lot of legacy Rails 3 apps yet.

Other Book Recommendations

It's been a while since I recommended random books here, so I'm gonna.

Packing for Mars, by Mary Roach.

Roach is nearly unique, she writes science books on odd corners of the world with precision and wit, kind of a cross between Malcolm Gladwell and Dave Barry.

This book is about space travel, particularly the various research on the mundane details of how the human body and mind live in the wildly unnatural environment of space. Chapters include what happens to astronauts who can't exercise, or can't bathe for weeks, or whether free-fall zero-g has long-term effects. Oh, and the engineering achievement of space toilets.

Love this book. Funny, not shy about it's subject matter, but not juvenile. As with all Roach's books, she's unfaillingly respectful toward what might otherwise seem like crazy scientific pursuits. And you'll never look at a group of astronauts the same way again.

The Fuller Memorandum, by Charles Stross

Programmers who are SF geeks who have not read Stross' Laundry books are advised to start. Now. (Hint, if you are a person who would laugh at a reference to Knuth's lost fourth book, covering computational demonology, your in the target group) It's a series where computer programs can be used to summon Lovecraftian horror monsters from the etherial depths, and the civil service that protects us. So it's a crazy mix of horror, spy novel, mundane office politics, and programming textbook.

Stross knows the coding well enough to make the book geek-convincing. Or as geek-convincing as you can get when talking about iPhone apps that act as magical wards or summon demons. So this is your typical "IT-guy needs to save the world from demons" book.

Aug 9, 2010: I Shouda Seen This Coming

RSpec, Shoulda, WindyCityRailsNoel RappinComment

Book Status

The Shoulda chapter is draft complete, after a slight restructuring to change the emphasis of the chapter, and a lot of syntax changes. My previous version of the chapter was written before Shoulda went in the direction of RSpec compatibility and so there were a lot of syntax changes that needed to be made, particularly to the way you create Shoulda extensions, which used to be much simpler.


WindyCityRails has extended the early bird pricing through August 11, because of the addition of Ryan Singer from 37signals to the schedule. Those of you who are obsessively following the schedule with an eye on how it affects me -- which, I suppose, is pretty much just me -- now see that my tutorial session no longer overlaps with Yehuda Katz, but does overlap with Ryan Singer.

My tutorial is called "Testing in a Legacy Environment", and will talk about adding TDD/BDD to an existing code base, with a focus on practical ideas and working with an actual fake legacy code base. I think it'll be a lot of fun, and I understand that tickets are still available. So register.


One of the issues that made the Shoulda chapter require some rework is that the Shoulda team has changed how they think of Shoulda. I'm paraphrasing here, but I think it's gone from "RSpec alternative for use with Test::Unit" to "Tool for single-assertion shoulda-style testing in either library. But especially in RSpec."

On the one hand, I really like having Shoulda syntax available in RSpec. It makes RSpec a lot more interesting to me, and I like the way single-assertion style looks in RSpec. That said, and also knowing that the Should team owes me nothing and absolutely needs to write the tool they want, I do think I'll miss having Shoulda as a full alternative to RSpec.

Let me back up. When I first started using Rails, I used Test::Unit because it was most similar to the tools I had been using (JUint, PyUnit, SUnit). As I got integrated into the Rails community, I became aware of RSpec, and thought it looked cool.

My first experience or two with RSpec went badly. RSpec, at that time, was very heavily into a mockist style of testing (or at least that's how it seemed to me), and for whatever reason I really struggled with making mockist testing work for me in any kind of reasonable flow.

If I remember correctly, Shoulda came out while I was in the middle of my first major Rails project as a consultant. I liked the single-assertion style immediately, and also liked the ability to get some RSpec flexibility without having to make the commitment to RSpec. Shoulda was much easier to add to an existing project.

Shoulda got popular quickly, I remember a talk at RailsConf '08 comparing all the testing tools and concluding that Shoulda's big advantage over RSpec was that it was much easier to extend. Shortly after that, as I got into a position where people would ask me questions about testing, "which framework should I use" was a popular first question.

When I started writing the Lulu book, it made perfect sense to have the book not focus on RSpec, since the non-RSpec tools at the time had very close parity to the RSpec feature set. I believed (still do) that it makes sense for a new user to start with the baseline Test::Unit features because they are simpler and because most Rails programmers know them. The fact that there was also already an RSpec book in development, I admit, was also a consideration.

A couple of interrelated things happened over time:

The Test::Unit ecosystem, including Shoulda, Jeremy McAnally's context, and other add-ons like Zebra basically stopped being worked on.

Cucumber became very popular, and integrates with RSpec better than Test::Unit, making the RSpec ecosystem stronger.

I had my first really good experience with RSpec, and I'm now much more comfortable with it than I was. There are a lot of RSpec features I didn't know about before that I love now.

As a result, or at least at the same time, I don't get asked the question about which framework to use any more.

In some ways this is too bad, some people genuinely don't like RSpec syntax, and I think that if somebody was to fork the pre-RSpec version of Shoulda and maintain it, that would still be a viable tool for some members of the community. At the same time, it's not like I'm jumping up and down to be that maintainer, so take that with a grain of salt.

Anyway, this leaves me in a weird place, with a Rails test book that covers RSpec, but isn't really about RSpec. I think that a lot of the advice and tool coverage in the book is applicable to RSpec or Test::Unit users, but I worry that Rails users who are already in the RSpec camp will assume that my book has nothing for them. (Note: I think it does. But then I would, wouldn't I?) But this isn't the only decision I made in the book that looks different a year or so later. (For example, I picked Machinist over factory_girl as factory tool to emphasize. I might have to redo that one also...)

I'm not sure what my point is by now. I like RSpec, and I like Shoulda, and I even like them together. But I also liked them apart. And what makes writing in this community both so much fun and so agonizing is that everything changes all the time.

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 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 7, 2010: Dylan Goes Electric (Probably Not True)

Alan Kay, Apple, Kent Beck, RSpec, Ruby Tracker, RubyMineNoel RappinComment

Book Status

Beta 4 should be available this week, or at the latest Monday, apparently we're working around people's vacation schedules. It will have two new chapters, and some error fixes and tweaks around the book.

Next is on to Beta 5.

In status news that shouldn't interest you much, the end of the quarter meant the end of my first Pragmatic pay period. And apparently Pragmatic pays as soon as possible, rather than waiting 30 or 90 days after the end of the pay cycle. That's pretty great, from my point of view. Again, no reason why you should care.


Envy Labs is announcing Ruby Tracker, the Ruby Dependency Manager. Basically, you give Ruby Tracker your code repository, and it analyzes your gem dependencies and notifies you when any of them are updated. Sounds interesting. I wonder if it might be most useful when first taking over a legacy project to see just how out of date it is. (Not that I would necessarily recommend updating a legacy project first thing, but it's good to see exactly what you are up against...)

A new beta of RubyMine 2.5 is now available. The big Rails feature is support for LESS CSS. Also, Mac users now have a native file directory, which is nice in that the old one was a pain in the neck, as well as a couple of other Mac-ish tweaks.

Mark Guzdial, over at the Computing Education blog links to some older articles by the one-and-only Alan Kay about the promise of spreadsheets and the like. Reading the kinds of things Kay was doing and speculating on 25 years ago or more is humbling -- the rest of the world hasn't quite caught up.

I linked to the first two parts of this yesterday, here's part 3 of Kent Beck's survey data on testing. This one is how often those surveyed run unit tests, with just over half running them on every code change.

I like this pattern -- here's Bogdan Gusiev with a custom RSpec matcher to test validation for ActiveRecord. (The code is here) The matcher lets you say things like it { should accept_values_for(:name, "Fred", "Jim") } and it {should_not accept_values_for(:name, "23", "M&Y". That's nice because it makes the test independent of the validation code being used.

Jay Fields has a post talking about what keeps Java developers from adopting Ruby or Clojure, and how they don't yet realize that the power of the languages and of command-line interactive terminals will overcome the relative lack of IDE support, which matches my experience pretty much exactly.


This article summarizes some rumor chatter going around that Apple is planning on either replacing Objective-C or offering another language as a full alternative for the creation of say, iOS applications. Just a couple of points. I suspect that this is at least something that Apple is researching -- they'd be crazy not to. Apple already supports MacRuby, so the idea that MacRuby could target iOS isn't completely insane. Still, wouldn't it be wonderful if they went back to the future and started supporting Dylan? Nothing would cement the "iPad is evolutionary Newton" theory more...

July 2, 2010: Cease and or desist

Jasmine, JavaScript, RSpecNoel Rappin1 Comment

Book Status

And now I turn my lonely eyes to the chapter on testing legacy code. I liked this chapter in the original book, and it's something I get asked about pretty consistently, so I really want to make it great.


I'm personally going to spend a lot of time with David Chelimsky's post about RSpec 2 docs. It's the best listing I've seen so far about changes between RSpec 1 and RSpec 2. In particular, the Cucumber features are outstanding -- the best example of tests as documentation I have ever seen.

Corey Haines has an article on testing JavaScript via Jasmine in this months jsmag -- not a free article, just so you know. I've heard Corey present on this topic, and he's great.

In a related story, Kristian Mandrup has a fork of the BlueRidge JavaScript/Rails test framework that makes the generators compatible with Rails 3.

Adam Wiggens describes Clockwork, a Ruby alternative to Cron.

Multiple sources report that the Lemmings game port for iOS that I reported on a few days back was immediately slapped with a cease and desist order from Sony. Ouch.

And if you haven't read the message from the CEO of Woot to his employees on the occasion of being acquired by Amazon, well, it's worth five minutes of your time.


One year ago this weekend, Gregg Pollack was nice enough to give the Lulu version of Rails Test Prescriptions a big shout-out on the official Ruby on Rails Weblog. This was part of what drove me to submit the book to Pragmatic, so this is another thank you to Gregg for the kind words and the push forward.

June 16, 2010: What Shoulda We Do?

Agile, Git, PDF, RSpec, Relevance, ShouldaNoel RappinComment

Top Story

Thoughtbot talks about their plans for Shoulda moving forward. The big takeaway is that, while the context library will be separated out for use in Test::Unit, both Shoulda style and Shoulda effort will be focused on RSpec integration.

I have some complicated thoughts about this one. I'm thrilled that Shoulda is being maintained -- it's a tool I've used a lot, and I was starting to get worried. And they should move their open source tool in any direction they want. But, of course, I can't help thinking about how this affects me, and having Shoulda be primarily a complement to, rather than an alternative to, RSpec has an interesting effect on the book I'm in the middle of writing.

It's so funny how these things change. It's been about eighteen months since I started writing what would become Rails Test Prescriptions. At the time, I was not a big fan of RSpec, largely because I didn't like the heavily mocked style that seemed to go along with it. With the emergence of Shoulda and the factory tools, Test::Unit had gained basic functional parity with RSpec. It also seemed like Shoulda/Test::Unit was really starting to gain community mindshare.

So, I wrote the book intending it to be a basically tool-agnostic guide to Rails testing, but with most of the examples in Test::Unit on the grounds that a) Test::Unit is part of the core Ruby and Rails stack, so it's always around, b) it's what the core team uses, c) I personally was using Test::Unit, and d) RSpec already had a book, so it seemed prudent for many reasons to find my own space. Those of you who bought the Lulu version will remember that it has longish chapters on Shoulda and RSpec, treating them more-or-less equally as alternative mature test frameworks.

In the interim, tools have ebbed and flowed. Cucumber came out, with very strong RSpec support (especially at first), starting a bit of a trend of new tools supporting RSpec over Test::Unit. The single-assertion style from Shoulda seemed to gain some traction among RSpec users. I started actually using RSpec more, and liking it.

At the same time, some things haven't changed. I'd still like the book to be framework agnostic to the extent possible. Test::Unit is still the Rails default, and is probably still easier for a somebody new to testing to understand. But I think I have some re-writing in my future.

Oh yeah, other links

Martin Fowler on what makes a good team room for an agile project.

Speaking of RSpec 2, here's one of what I hope will be many posts from David Chelimsky about a new RSpec feature, metadata and filtering.

Gitbox is a new Max OS X interface for Git. Currently seems less full featured than the GitX fork that I use, but it does seem like a nice start.

Relevance announces PDFKit, a new library for PDF generation, along the lines of PrinceXML. I don't see this as a replacement for Prawn at all, though. There will always be cases where direct generation makes more sense. And there will always be cases where conversion makes sense. I think doing a book with Prawn would have been challenging, for example.

Finally, here's a simple little survey of the Ruby community. I note parenthetically that RSpec has 42% of the vote for Preferred Testing Framework, with Shoulda and Test::Unit having a combined 31%.

June 1, 2010: June, she'll change her tune

Chicago Ruby, Cucumber, JRuby, Kent Beck, RSpec, iPadNoel RappinComment

iPad Note

I keep wanting to write about the iPad, but so, so many other people are writing about it that I'm not sure I have anything to add. More or less at random, I really liked the brief rant Joe Posnanski added in the middle of an otherwise-unrelated blog post, and Charles Stross' typically complete take. Right now, I just would add that I still use it more than I thought, that the form factor makes more of a difference than I expected (being able to easily walk to show the screen). Also, I'm somewhat idiosyncratically waiting for turn-based strategy games to pop up for it, along the line of Avalon Hill's old games -- the thing is perfect for them.


One last reminder of today's Chicago Ruby meeting featuring Matt Polito talking about Git, and me talking about testing.

And then

Looks like Kent Beck has gone and evolved the Agile Manifesto at the Startup Lessons Learned conference. This moves in the direction of what Beck has been calling Responsive Design.

Sarah Mei has a really nice example of outside-in BDD going back and forth between Cucumber and RSpec. Very nice overview of the process.

Ruby 1.9.2 preview 3 is out and available via RVM. Also over the weekend RSpec 2.0.0 beta 9.1 was released.

Charles Nutter has a long technical examination of performance in JRuby.

Rails Rx Standup: April 12, 2010

Agile, Apple, Git, RSpec, This American Life, Twitter, standup, testingNoel RappinComment

Top Story

For a while, it looked like the top story was going to be Apple's new developer Rule 3.3.1, described here by John Gruber. More on that in a second.

But the real top story is the news that Twitter has bought Tweetie, intending to rebrand it as Twitter for iPhone, and dropping the price to a low, low, free. Eventually, it will be the core of Twitter for iPad. Wow.

Tweetie is probably the only case where I actually prefer the iPhone experience to the desktop experience, but I'd also be very sad if Tweetie for Mac was orphaned. (Not least because I just bought the MacHeist bundle in part as a way to get the Tweetie Mac beta sooner...). Later update: Tweetie developer Loren Brichter said on the MacHeist forum that the next Tweetie/Mac beta will come out.

I actually suspect that at least some of the existing iPhone Twitter clients will be able to continue -- there's clearly room in the ecosystem for apps that have much different opinions than Tweetie. It depends on how aggressive Twitter is planning to be. Dropping Tweetie's price to free strikes me as agressive, although it may just be that the Twitter team is averse to direct ways of making money.

As for the Apple story, it's a familiar space. Apple does something -- in this case, blocking apps not originally written in C, C++, or Objective-C -- that might have a reasonable user or branding component (keeping the iPhone platform free of least-common-denominator cross-platform apps) and taking it just too far for users or developers to be comfortable with it. That's, of course, an understatement, as a lot of developers are really angry. Gruber's point about the Kindle apps is good (and was later cited by Steve Jobs), but on the whole, I think this is a bit to far for Apple, or maybe I'm just upset that that the door seems to have been slammed on MacRuby apps for iPhone ever being feasible.

Book Update

Still working on the Webrat/Capybara chapter. Describing two tools that are so similar is really challenging for me -- when there's a difference, keeping it clear which tool is under discussion.

Also I've got the probability that I'll have an article in an upcoming issue of the Pragmatic Magazine. This will probably be based on material from the book, but edited to fit the magazine article format. Probably either factory tools or mocks. Or maybe Ajax testing. Haven't decided yet.

Tab Dump

Don't think I've mentioned this yet, but here is a cool presentation of RSpec tricks. Some of these don't work in RSpec 2, though.

While we're on the presentation kick, here's a nice intro to Git from James Edward Gray.

If you've ever tried to deploy Agile in a hostile environment, then the recent This American Life episode about the General Motors/Toyota NUMMI plant will resonate for you.

And Finally

A comparison of a boatload of Ruby test frameworks, being used in Iron Ruby to test some .NET code. I admit that I was not familiar with all the frameworks used here.

RSpec and Mock Design Question

Flailing, RSpec, testingNoel Rappin2 Comments
Here's a little RSpec design question.

As I've probably mentioned in various spots, I don't naturally take to the RSpec massively-mocked style of testing. However, I'm currently on a Rails project that is using that style -- unit tests don't touch the database, functional tests don't touch the models. It seems to be working for them, they certainly seem to have stuck with it over the course of this rather complex application.

Anyway, today, my pair and I added a new before_filter to the layout of our application, where it gets called by every controller test in the system. This filter calls some user methods to put some dynamic user data on the screen.

Suddenly, we have failing tests all over the place, the vast majority of them related to mocks, mostly having to do with mocks or stubs that haven't defined the method called in the filter and therefore thrown a mock expectation exception or, less frequently, a mock that does call these methods, but has an expectation that they will only be called once.

Wading through all these things is kind of daunting, and it's not doing much to raise my general opinion of mock-heavy testing. That aside -- I'm wondering how this is supposed to work. That is, I'm curious as to how a true RSpec expert would answer the following questions:

  1. How would this issue -- adding a new method call against an existing family of mocks -- be handled in a perfectly designed and maintained RSpec test structure? What is the ideal here?

  2. Given a system in progress that, while not bad, has had a lot of different people working on it in their own style, what's the ideal way to proceed from here

Just wondering.