Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Moving Day

If you are reading this, you are looking at the old, WordPress version of this blog, and you should come visit me at http://www.noelrappin.com.

Sorry for the inconvenience, all of your bookmarks should transfer to the new site in a day or so. However, if you subscribe to this site via RSS feed at the http://railsrx.com/feed address, I’m not sure that one will transfer over, and you should change it to http://www.noelrappin.com/railsrx/rss.xml.

Thanks, and I hope you will come and visit.



Setting Up Fast No-Rails Tests

The key to fast tests is simple: don’t do slow things.

Warning: this post is a kind of long examination of a problem, namely, how to integrate fast non-Rails tests and slow Rails tests in the same test suite. This may be a problem nobody is having. But having seen a sample of how this might work, I was compelled to try and make it work in my toy app. You’ve been warned, hope you like it.

In a Rails app, “don’t do slow things” largely means “don’t load Rails”. Which means that the application logic that you are testing should be separable from Rails implementation details like, say, ActiveRecord. One way to do that is to start putting application logic in domain objects that use ActiveRecord as an implementation detail for persistence.

By one of those coincidences that aren’t really coincidences, not only does separating logic from persistence give you fast tests, it also gives you more modular, easier to maintain code.

To put that another way, in a truly test-driven process, if the tests are hard to write, that is assumed to be evidence that the code design is flawed. For years, most of the Rails testing community, myself included, have been ignoring the advice of people like Jay Fields and Michael Feathers, who told us that true unit tests don’t touch the database, and we said, “but it is so easy to write a model test in Rails that hits the database, we are sure it will be fine.” And we’ve all, myself included, been stuck with test suites that take way too long to run, wondering how we got there.

Well, if the tests get hard to write or run, we’re supposed to consider the possibility that the code is the issue. In this case, that our code is too entangled with ActiveRecord. Hence, fast tests. And better code.

Anyway, I built a toy app placing logic in domain objects for the Mountain West workshop. In building this, I wanted to try a whole bunch of domain patterns at once, fast tests, DCI, presenters, dependency injection. There are a lot of things that I have to say about messing around with some of the domain object patterns floating around, but first…

Oh. My. God. It is great to be back in a code base where the tests ran so fast that I didn’t have time to lose focus while the tests ran. It occurred to me that it is really impossible to truly do TDD if the tests don’t run fast, and that means we probably have a whole generation of Rails programmers who have never done TDD, who only know tests as the multi-minute slog they need to get through to check in their code, and don’t know how much fun fast TDD is.

Okay, at some unspecified future point, I’ll talk about some of the other patterns. Right now, I want to talk about fast tests, and some ideas about how to make them run. While the basic idea of “don’t do slow things” is not hard, there are some logistical issues about managing Rails-stack and non-Rails stack tests in the same code base that are non obvious. Or at least they weren’t obvious to me.

One issue is file logistics. Basically, in order to run tests without Rails, you just don’t load Rails. In a typical Rails/RSpec setup, that means not requiring spec_helper into the test file. However, even without spec_helper, you still need some of the same functionality.

For instance, you still need to load code into your tests. This is easy enough, where spec_helper loaded Rails and triggered the Rails auto load, you just need to explicitly require the files that you need for each spec file. If your classes are really distributing responsibility, you should only need to require the actual class under test and maybe one or two others. I also create a fast_spec_helper.rb file, which starts like this:

$: << File.expand_path("app")
require 'pry'
require 'awesome_print'

Pry and Awesome Print are there because they are useful in troubleshooting, the addition to the load path is purely a convenience when requiring my domain classes.

There is another problem, which is that your domain classes still need to reference Rails and ActiveRecord classes. This is a little messier.
I hope it’s clear why this is a problem – even if you are separating domain logic from Rails, the two layers still need to interact, even if it’s just of the load/save variety. So your non-Rails tests and the code they call may still reference ActiveRecord objects, and you need to not have your tests blow up when that happens. Ideally, you also don’t want the tests to load Rails, either, since that defeats the purpose of the fast test.

Okay, so you need a structure for fast tests that allows you to load the code you need, and reference the names of ActiveRecord objects without loading Rails itself.

Very broadly speaking, there are two strategies for structuring fast tests. You can put your domain tests in a new top-level directory – Corey Haines used spec-no-rails in his shopping cart reference application. Alternately, you can put domain tests with everything else in the spec directory, with subdirectories like spec/presenters and the like, just have those files load your fast_spec_helper. About a month ago, Corey mentioned on Twitter and GitHub that he had moved his code in this direction.

There are tradeoffs. The separate top-level approach enforces a much stricter split between Rails tests and domain tests – in particular, it makes it easier to run just the domain tests without loading Rails. On the other hand, the directory structure is non-standard, there is a whole ecosystem of testing tools that basically assumes that you have one test directory.
It’s not hard to support multiple spec directories with a few custom rake tasks, though it is a little awkward. Since your Rails objects are never loaded in the domain object test suite, though, it’s very easy to stub them out with dummy classes that are only used by the domain object tests.

As I mentioned, Corey has also shown an example with all the tests under single directory and some namespacing magic. I’m not 100% sure if I like the single top-level better. But I can explain how he got it to work.

With everything being under the same top level directory, it’s easier to run the whole suite, but harder to just run the fast tests (not very hard, just harder). Where it gets weird is when your domain objects reference Rails objects. As mentioned before, even though your domain objects shouldn’t need ActiveRecord features, they may need to reference the name of an ActiveRecord class, often just to call find or save methods. Often, “fast” tests get around this by creating a dummy class with the same name as the ActiveRecord class.

Anyway, if you are running your fast and slow tests together, you’re not really controlling the order of test runs. Specifically, you don’t know if the ActiveRecord version of your class is available when your fast test just wants the dummy version. So you need dummy versions of your ActiveRecord classes that are only available from the fast tests, while the real ActiveRecord objects are always visible from the rest of the test suite.

I think I’m not explaining this well. Let’s say I have an ActiveRecord object called Trip. I’ve taken the logic for purchasing a trip and placed it in a domain object, called PurchaseTripContext. All that’s fine, and I can test PurchaseTripContext in a domain object test without Rails right up until the point where it actually needs to reference the Trip class because it needs to create one.

The thing is, you don’t actually need the entire Trip class to test the PurchaseTripContext logic, you just need something named Trip that you can create, set some attributes on, and save. It’s kind of a fancy mock. And if you just require the existing Trip, then ActiveRecord loads Rails, which is what we are trying to avoid.

There are a few ways to solve this access problem:

If you have a separate spec_fast directory that only runs on its own, then this is easy. You can create just a dummy class called Trip – I make the dummy class a subclass of OpenStruct, which works tolerably well. class Trip < OpenStruct; end.

You could also use regular stub, but there are, I think, two reasons why I found that less helpful. First is that the stubs kind of need to be recreated for each test, whereas a dummy class basically gets declared once. Second, OpenStruct lets you hold on to a little state, which – for me – makes these tests easier to write.

Anyway, if your domain logic tests are mixed into the single spec directory, then the completely separate dummy class doesn’t work – the ActiveRecord class might already be loaded. Worse, you you can’t depend on the ActiveRecord class being there because you’d like to run your domain test standalone without running Rails. You can still create your own dummy Trip class, but it requires a little bit of Ruby module munging, more on that in a second.

If you want to get fancy, you can use some form of dependency injection to make the relationship between TripPurchaseContext and Trip dynamic, and use any old dummy class you want. One warning – it’s common when using low-ceremony dependency injection to make the injected class a parameter of the constructor with a default, as in def initialize(user, trip_class = Trip). That’s fine, but it doesn’t completely solve our testing problem because the use of Trip in the parameter list needs to be resolved at load time, so the constant Trip still needs some value.

Or, you could bite the bullet and bring the Rails stack in to test because of the dependency. For the moment, I reject this out of hand.

This isn’t an exhaustive list, there are any number of increasingly insane inheritance or metaprogramming things on the table. Or under the table.

So, if we choose a more complicated test setup with multiple directories, we get an easy way to specify these dummy classes. If we want the easier single-directory test setup, then we need to do something fancier to make the dummy classes work for the fast tests but be ignored by the Rails-specific tests.

At this point, I’m hoping this makes sense. Okay, the problem is that we want a class to basically have selective visibility. Here’s the solution I’m trying – this is based on a gist that Corey Haines posted a while back. I think I’m filling in the gaps to make this a full solution.

For this to work, we take advantage of a quirk in they way Ruby looks up class and module names. Ruby class and module names are just like any other Ruby constant. When you refer to a constant that does not have any scope information, like, say, the class name Trip, Ruby first looks in the current module, but if the current module doesn’t contain the class, then Ruby looks in the global scope. (That’s why sometimes you see a constant prefixed with ::, as in ::Trip, the :: forces a global lookup first).

That’s perfect for us, as it allows us to put a Trip class in a module and have it shadow the ActiveRecord Trip class in the global scope. There’s one catch, though – the spec, the domain class, and the dummy object all have to be part of the same local module for them all to use the same dummy class.

After some trial and error (lots of error, actually), here’s a way that I found which works with both the fast tests and the naming conventions of Rails autoload. I’m not convinced this is the best way, so I’m open to suggestions.

So, after 2000 words of prologue, here is a way to make fast tests run in the same spec directory in the same spec run as your Rails tests.

Step 1: Place all your domain-specific logic classes in sub modules.

I have sub directories app/travel/presenters, and app/travel/roles and the like, where travel is the name of the Rails application. I’m not in love with the convention of putting all the domain specific directories at a separate level, but it’s what you need to do in Rails to allow autoloaded classes to be inside a module.

So, my PurchaseTripContext class, for example, lives at app/travel/contexts/purchase_trip_context.rb, and starts out:

module Contexts
  class PurchaseTripContext
    # stuff

Step 2: Place your specs in the same module

The spec for this lives at spec/contexts/purchase_trip_context_spec.rb (yes, that’s an inconsistency in the directory structure between the spec and app directories.) The spec also goes inside the module:

module Contexts
  describe PurchaseTripContext do
    it "creates a purchase" do

Step 3: Dummy objects

The domain objects are in a module, the specs are in a module, now for the dummy classes. Basically, I just put something like this in my fast_spec_helper.rb file:

module Contexts
  class Trip < OpenStruct; end
  class User < OpenStruct; end

This solves the problem, for some definition of “solves” and “problem”. The fast tests see the dummy class, the Rails tests see the Rails class. The tests can be run all together or in any smaller combination. The cost is a little module overhead that’s only slightly off-putting in terms of finding classes. I’m willing to pay that for fast tests. One place this falls down, though, is if more than one of my sub-modules need dummy classes – each sub-module then needs its own set, which does get a little ugly. I suspect there’s a way to clean that up that I haven’t found yet.

In fact, I wonder if there’s a way to clean up the whole thing. I half expect to post this and have somebody smart come along and tell me I’m over complicating everything – wouldn’t be the first time.

Next up, I’ll talk a little bit about how some of the OO patterns for domain objects work, and how they interact with testing.


Here’s what I’ve got.

2 chapters introducing jQuery and Jasmine via a walkthrough of a simple piece of JavaScript functionality.

1 need to convert all my text from its current proprietary format to something more Markdown based.

1 genuinely silly conceit tying together the application that gets built in the book. And I mean that in the best way. It should be silly, there’s no reason not to be bold. There is even a twist ending. I think.

1 slightly dusty self-publishing tool chain that converts a directory of markdown files into HTML, with syntax colored code. It’s possible that there’s a better library for some of the features these days.

1 chapter on converting that simple piece of jQuery into various patterns of JavaScript object. I quite like this one, actually.

1 website, which is currently hosted by WordPress – at one point, I had to abandon the railsrx.com site that actually sold stuff, and WordPress was easy. I think I’ll need to upgrade that a bit.

1 Intro chapter covering JavaScript basics and the Chrome developer tools. Not sure if this is at the right level for the audience I expect.

1 Prince XML license for converting said HTML files into PDF. No idea if that’s still the best tool for the job. Or even if my license is current.

1 chapter on building a marginally complex auto complete widget in jQuery and Jasmine. I like this example.

1 copy of most of the book’s JavaScript code in CoffeeScript. Not sure when I thought this was the right idea for the book, beyond an excuse to use CoffeeScript.

1 chapter on jQuery and Ajax.

0 toolchains for generating epub and mobi files. I know I can find this.

1 case of impostor’s syndrome, not helped by rereading the harsh review of Rails Test Prescriptions on Amazon. That was dumb, why would I do that?

1 chapter on using JSON. As far as I can remember, this chapter never went to edit.

3 people who mentioned on Twitter that they’d buy a self-published book. Don’t worry, I won’t hold you to it.

1 plan for writing 2 or three chapters on Backbone.js

5 people who reviewed the last version who I feel should get free copies when this comes out. It’s not their fault.

4 viewings of Ze Frank’s “Invocation for Beginnings”

So. Ready to go. Watch this space.

A Brief Announcement About A Book

So… The JavaScript book that I had contracted to do with Pragmatic will no longer be published by them.

I need to be careful as I write about this. I don’t want to be defensive – I’m proud of the work I did, and I like the book I was working on. But I don’t want to be negative either. Everybody that I worked with at Pragmatic was generous with their time and sincere in their enthusiasm for the project. Sometimes it doesn’t work out, despite the best intentions.

I haven’t spoken about this project publicly in a while because it was so up in the air. And also because I’m not sure what to say about it without sounding whiny or mean. And also because I was afraid of jinxing things, which is obviously less of an issue now.

Since November, the book has been in review and I’ve gone through a few cycles with Pragmatic trying to get things just right. The issues had more to do with the structure and presentation of the material then of the content or writing itself. I’m not completely sure what happened, but I think it’s fair to say that the book I was writing did not match the book they wanted in some way or another.

Anyway, that’s all water under the bridge. I have full rights to the text I’ve already produced. Self-publishing is clearly an option, though the phrase “sunk costs” keeps echoing in my head. It’s hard to resist the irony of starting with a Pragmatic contract and moving to self-publishing after having done it the other way around with Rails Test Prescriptions. I’m hoping to blog more – in addition to being a time sink, not being able to write about this book was kind of getting in my head about any blogging.

Thanks for listening, and watch this space for further announcements. I was excited about this project, and while this is disappointing, I’ll be excited about it again in a few days. Thanks to the people I worked with at Pragmatic for the shot, and thanks to all the people who have been supportive of this project.

Control Your Development Environment And Never Burn Another Hamburger

Everything I know about the world of fine dining I know from watching Top Chef and from eating at Five Guys. But I do know this: chefs have the concept of mise en place (which does not mean Mice In Place), which is the idea that everything the chef is going to need to prepare the food is done ahead of time and laid out for easy access. The advantages of having a good mise en place include time savings from getting common prep done together, ease of putting together meals once the prep is done, ease of cleanup. Again, I have no idea what I’m talking about, but it seems like the quality and care that a chef puts into their mise en place has a direct and significant benefit on how well they are able to do their job.

You probably know where I’m going with this, but I’m becoming increasing convinced that one of the biggest differences between expert and novice developers is control over the environment and tools they use. I came to this the hard way – for a long time I was horrible about command lines, it was actually something that kept me away from Rails for a little bit. It’s not like I’m Mr. Showoff Bash Script guy these days, but I know what I need to know to make my life easier.

Let me put it another way. Once upon a time I read a lot of human factors kind of materials. I don’t remember where I read it, but I read once about an expert short-order cook at a burger joint. His trick was that he would continually shift the burgers to the right as he cooked them, such that by the time they got to the end of the griddle, they were done. Great trick (though admittedly you need to be a bit of an expert to pull it off). Not only did the cook know when things were done without continually checking, but it was easy to put on a burger that needed a different amount of doneness simply by starting it farther left along the griddle.

What does that mean?

The name of the game in being an expert developer is reducing cognitive load.

Try and list all the things you need to keep in your head to get through your day. Think about all the parts of that you could offload onto your environment, so that you can see them at a glance, like the short order cook, and not have to check. What are the repetitive tasks that you do that can be made easier by your environment? What can you do so that your attention and short-term memory, which are precious and limited, are focused on the important parts of your problem, and not on remembering the exact syntax of some git command.

This is not about which editor you use, but it is about picking an editor because you like it and understand how to customize it, not because all the cool kids use it. If you are going to use Vim, really learn how to use Vim – it’s not that hard. But if you use Vim, and don’t learn the Vim features that actually make it useful, then it’s not helping you, and it’s probably hurting you. Is Vim (or TextMate, or whatever) making your life easier or not? Vim drives me nuts, but I’ve seen people fly supersonically on it.

I’m getting a little cranky about seeing people’s environments – I’m not normally a big You’re Doing It Wrong kind of guy, but, well, I’m getting a little bit cranky.

If you’re doing web development, there are probably three things that you care about at any given time: your text editor, a command line, and a web browser. Every man, woman, and child developer at my fine corporation has a laptop along with a second monitor that is larger than a decent surfboard. If you can’t see at least two of those three things at all times, try and figure out how much time you spend flipping between windows that you could be seeing together. If you are running Vim in a terminal in such a way that you can never see an editor and a command line at the same time, I think you can probably do better.

If you use Git, for the love of God, please put your git branch and status in your shell prompt. RVM status, too. And it’s not hard to add autocompletion of Git branches, too. Or, go all the way to zsh, which has fantastic autocompletion. Again, reducing cognitive load – you can see your environment without checking, you can type complex things without knowing all the syntax.

Use a clipboard history tool. I use Alfred, which is generally awesome as a launcher and stuff, but it’s not the only one.

Use some tool that converts frequently used text to shorter easier to remember text. Shell aliases do this, I also use TextExpander, which has the advantage that TextExpander shortcuts are usable in SSH sessions.

The thing is, I don’t know what the most important advice is for you. You need to be aware of what you are doing, and strangely, lower your tolerance to your own pain. What do you do all the time that is harder than it needs to be? Is there a tool that makes it easier or more visible? How hard would it be to create or customize something? Are you the cook who can look at the griddle and know exactly when everything will be done, or are you the guy constantly flipping burgers to check?

iaWriter and iCloud, You Know, In The Cloud

If I don’t write about iOS editors every few months, then it’s harder for me to justify continuing to mess around with them…

The thing that’s changed my editor use in the last couple of months is iaWriter Mac and iOS adding iCloud support, even more deeply integrated than Apple’s own applications. iaWriter is the first writing program I use to move to the iCloud future (though there are some games and other programs that also sync via iCloud already).

At a technical level, the integration is fantastic. In iaWriter, iCloud shows up as a storage location, on par with internal iPad and Dropbox storage. If you are just using the iPad version then there is not much difference between iCloud and Dropbox. iCloud saves automatically, but Dropbox lets you use subfolders. (As a side note, iaWriter has improved its Dropbox sync from “show-stoppingly bad” to “works with a couple of annoyances”, the main annoyance being that it doesn’t remember your place in the Dropbox file hierarchy.)

Where the iCloud thing gets really cool is if you are running iaWriter on both iPad and Mac. On iaWriter Mac, you get a command in the file menu for iCloud, which has a sublisting of all the files iaWriter is managing in iCloud, along with commands to move the current file to or from iCloud.

When you make a change to an iCloud file (on the Mac side, an explicit save, on the iPad side an automatic local save), it is automatically sent to iCloud and pushed to the other site. No different from Dropbox, you say. True, except that the iCloud sync behaves much better if a file is simultaneously open in both apps. The changes just appear in the other app. You can put the iPad and Mac next to each other and go back and forth between the two with only a very slight pause while they sync up.

I haven’t quite gotten that level of integration from Dropbox. In particular, if a Lion-aware app has Dropbox change the file behind its back, the original Mac file continues to be displayed with a filename indicating that it is a deleted version. You then need to close the Mac file and reopen it. I’m not sure I’ve seen an iOS editor that polls Dropbox for changes, though one of the auto-sync ones (Elements, WriteRoom) might.

This may seem esoteric, but since I tend to have several blog posts on progress in open windows on my laptop, I do wind up regularly using the iPad to edit an open file. The iaWriter iCloud sync is noticeably less annoying.

It’s not all sweetness and light, especially if you are a really heavy creator of text files. There is no such thing as a folder in iCloud land, which will eventually become an organizational problem. Worse, there’s an implied lock-in to using iCloud that seems to miss the point of using text files in the first place.

When you move a file to iCloud from the Mac, it moves the file to the iCloud hidden directory, which I think is somewhere in the library directory. Although it doesn’t technically vanish from your hard drive – if you can find the file, you can open it in another application (for what it’s worth, the Alfred launcher can find the files), the clear intent is that the file is in a place not to be touched by applications other than iaWriter.

On the iPad side, the situation is worse. If a file is in iaWriter’s iCloud storage than no other iPad app can see it. (To be fair, it is relatively easy for iaWriter to move a file from iCloud to Dropbox from either device.) I don’t know if sharing files between applications will be possible when more applications support iCloud, or whether iCloud is strictly sandboxed.

And hey, for a lot of things, this limitation isn’t an issue. If you are using a tool with its own format, then it is less of an issue that other applications can’t see it. Even with something like text, if you aren’t the kind of crazy that needs to open a file in a gajillion different editors, you are probably okay. If you are using text specifically because it’s easy to move around between different programs, and you have a workflow where a file will commonly be touched by different apps, then iCloud is going to get in your way a little.

As for me, the iCloud support has made me use iaWriter more often for blogs and short notes. (Though I still use Textastic for more structured stuff on iPad.) I always liked iaWriter, but for a while it was just really bad at sync compared to other iOS editors. So, despite some quibbles about what happens in iCloud when I have dozens of files that I want to share among different apps, right now, the sync is good enough to make it valuable.

Getting Back to Smalltalk

This week I wound up trying to put together a sample “real-world” problem suitable for use in an automated web thing aimed at potential new hires. Of course, any actual “real-world” problem would be have too many extraneous details to make it suitable given the constraints of the web thing, but trying to create the illusion of real-world-ness was kind of fun.

Since this seemed like sort of a weird way to spend a day or two, I decided to make it weirder by implementing both my solution to the problem and the code to generate test data in a language I don’t use every day. Just for the heck of it, I picked Smalltalk (Specifically, Pharo), the first time I’ve written Smalltalk code in anger for… hmm. Let’s see… I wrote the intro chapter to this in about 2000, and even then it had been a couple of years since I really wrote something in Smalltalk. (For the record, my other choice was Clojure, but I seem to have some weird mental block about getting started on a Clojure project. Someday soon, though.)

Anyway, Smalltalk was interesting because the environment is so different from anything else going and because I really haven’t used it in so long, I was curious to see whether my reactions to the Smalltalk environment would be any different given how long it’s been. For example, the last time I worked in Smalltalk, SUnit and TDD wasn’t a thing.

Overall, successful experience. I was able to actually write the program. It probably took me a little longer than it would have in Ruby, just because I was a bit rusty and the Pharo UI was a little unfamiliar. But it works, and most of the code isn’t bad – it got a little ragged toward the end. Here are a few random notes about the experience:

Language Structure

Whatever the line between a “scripting” language and a “normal” language is, Smalltalk is on the “not a scripting language” side of it. Smalltalk is very much a purist language with a small, consistent syntax, and not a lot of the sugar that you get used to in the Ruby/Python/Perl neighborhoods. Method names tend to be longish, and although the environment encourages short methods, basically there’s more typing in Smalltalk than in the equivalent Ruby.

Smalltalk was created almost completely outside the C/C++/Java family of programming languages, which combined with its pure structure makes it feel somewhat alien. And I say that as somebody who likes Smalltalk and genuinely enjoyed working in the environment.

For example:
* The first element of an array is index 1, not index 0. Which, honestly, makes more sense.
* Smalltalk doesn’t have operator precedence, and is evaluated strictly left-to-right, so a mathematical expression like 2 + 3 * 4 will not give you the result you would get in, say, every other programming language ever.
* Smalltalk doesn’t use the dot-notation for method calls, instead, the dot is a statement separator. It has keyword arguments, as later borrowed by Objective-C. Strings are single quotes, double quoted strings are comments.

Then you get other things like all the boolean and loop logic being managed by the library rather than the syntax. Really, the only thing the syntax manages in Smalltalk is order of operations and a very small amount of literal syntax. There’s a rich set of collection classes, and the names and classes are just slightly off from what you are used to. Takes some immersion to get the feel.


The other really unfamiliar thing about Smalltalk is the environment and workflow. Smalltalk source isn’t normally kept in files. Instead, you run a binary image of all the code in the Smalltalk environment. If I’m remembering correctly, a Smalltalker working on multiple projects would have a separate image for each project. (There are mechanisms for teams working together, but I don’t think they are very standard, and I’m not all that familiar with them.)

The thing about Smalltalk is that you are always inside the environment. The idea, for example, that Ruby is super-flexible in what it allows you to do at run-time is a trivial point in Smalltalk. Everything is at run-time, because the phone call is coming from inside the house, so to speak. Of course you can create classes and methods at run-time. If you couldn’t, the whole system would be unworkable.

The image contains your code, the entire Smalltalk system, and the state of all the objects therein. Smalltalk typically also has a mechanisms for export/import of source, and also for internal version control. I think it’s fair to say that dealing with the workspace is at best counterintuitive when you are used to dealing with text editors and files.

Your main interface with the Smalltalk system is the code browser, which allows you to view any class and method in the system. One method at a time. Quick Quiz – what’s the Smalltalk keyword to define a method? Trick question. Smalltalk doesn’t have one. Smalltalk just knows that the things you type into the code browser are methods, and the first line of a method is its name. Code browsers are very neat, but again, using them effectively is a skill – a big step is realizing you can have more than one of them open at a time.

What’s interesting to me are the places where the Smalltalk environment is still ahead of my regular code environments, and where it’s behind. On the plus side:

  • When you save a Smalltalk method, the code browser verifies that it’s syntactically correct before allowing the save. If you are calling a method or using a variable that doesn’t exist, you have to okay it – in some circumstances, you even have the ability to create the method or variable as part of the save process.
  • The browser has easy access to all old versions of a method that you are looking at.
  • It’s very easy to see places that might call the method you are writing.
  • The browser also has some powerful refactoring functionality built in.
  • Integration is amazing, since everything is running. To give one example, the code browser knows which methods are SUnit tests, and they display in the browser with a red/yellow/green/gray indicator of their current state (error/failure/success/not run). Individual tests can be run separately easily in the browser, and since they environment is already loaded, the tests run in an eye blink.
  • On a related note, the debugger is famously awesome. From a breakpoint, you can see the state of all variables, edit values, edit code, all nice and easy.
  • You also can create workspaces, which are just blank code windows that you can execute arbitrary snippets in, like a iRb loop, but a bit more flexible.

But there are some missing pieces:

  • The code editor itself isn’t as powerful as you are used to if you’ve been using Vim or TextMate or, hell, anything. I’m a big “typing is not the bottleneck” kind of guy, but still, I would have loved some macros or snippets or something.
  • The one-method on display per code browser limitation is, well, limiting. You can have multiple code browsers open, but that takes up a lot of real estate. Tabbed browsers, split windows, that kind of thing would be kind of nice.
  • Intellectually I know that it’s really hard to lose changes in a Smalltalk image, but it still feels fragile to me not to have files readable by an external tool. UPDATE: I could have been clearer about this. Smalltalk doesn’t save changes in the image as such, instead it saves all your changes and lets you play changes back. I was trivially able to recover about 30 minutes of work after a Pharo crash, simply because all the changes were recorded and easily placed back in the image. The Smalltalk setup is effective, but feels different from the way I tend to think about their projects.

One interesting feature of the browser based editing environment is that it’s very easy to create a new method that is based on an existing method. You don’t even have to cut and paste, just browse to the existing method, change its name and save. Smalltalk will create a new method based on the new name.

This is very nice from a getting code in the system standpoint, but it seems to have the side effect of encouraging more duplication in the system than I might be otherwise comfortable with. The effect is confounded by the fact that you can only see one method at a time in the browser, making it difficult to scan for duplication.

What’s not getting across here is how smooth the workflow in the small is when you really get the rhythm going. It’s an environment that really suits a “make a small change, evaluate the change” process. In some ways, it’s not surprising that the test-first movement would have gotten serious momentum in Smalltalk, test-first is just a formalization of the way a good Smalltalk programmer interacts with the system. Plus, I’m a purist in so many ways, and even though the code takes a little getting used to, I like the way it turns out.

So, successful test. Would try again. I still want to try something with Seaside one of these days just to see what that’s like.

Things that Should Be Metaphors, Part 1

I present to you two things that sound like they should be metaphors for project issues. Except for two things:

  1. They are real
  2. I have no idea what they might be metaphors for

The Library Book Priority Conundrum

I read a lot. In general, I purchase books I’m very excited about reading, and books that I’m less sure about I check out from my local library. The problem is that I always have more books than time to read, and the library books have the nasty property that the library expects them back sooner or later.

The practical effect is that aside from a few books that are “drop everything” when they come out, I’m forever reading library books first, before the books I’ve purchased, because they will go back home, where as the books I own I get to keep.

Since I’ve already said that I’m usually more excited about the books I’ve purchased and get to keep, this is clearly not optimal. But even knowing this problem, I book I actually purchased (Ganymede by Cherie Priest) has been waiting behind a bunch of library books (That is All by John Hodgman, Kingdom of the Gods by N. K. Jemisin, among others). Okay, those books are great too. But still…

The last clementine problem

I go to the grocery store and buy a bag of clementines. Because they are yummy and easier to peel than grapefruits. Every bag has one or two clementines that are clearly a little less good than the others, so naturally I wait to eat those last. However, since as the clementines get yuckier they become less desirable than anything else in my kitchen, I don’t eat them at all. The result is that I don’t eat the last few clementines, because the pretzels are more enticing. I don’t get new clementines, because I already have clementines, and I don’t throw out the bad clementines until they are well and truly no longer food. The upshot is that I can go weeks without clementines, even though I like them.

Ten Things That Drive Me Crazy About Conference Talks, And How To Avoid Them

If I’m counting right, Ruby Midwest is my fifth conference this year, which is I guess one of the perks of having an employer that likes being involved in the community. It’s great – I like meeting all the smart people involved with Ruby, I learn things, and sometimes people ask me to sign my book. (Okay, that happened once. Still, that’s more than zero.)

At the risk of shooting myself in the foot forty-eight hours before I go give my own talk, here’s a list I compiled for a lightning talk at a recent Groupon Geekfest, entitled 10 Things That Drive Me Crazy About Conference Presentations. I offer it with love and respect. I also note that I’ve committed at least five of these, and will probably commit at least one of them on Friday when I go on at Ruby Midwest.

Here’s the big takeaway: if you are going to the trouble of delivering a live presentation, you need to think of it as a performance, and you need to offer something to the audience that they wouldn’t be able to get from watching the slides.

Coincidentally, Merlin Mann covers similar points from a different perspective on a recent Back to Work Podcast. A lot of good advice there.

Hey, I’m not perfect at this, and posting this pretty much guarantees an epic failure on Friday, but maybe this will help you.

Here’s my list:

1. Underprepared

Do I need to explain this one? Generally my marker here is if the speaker seems surprised by the content of their slides, they are probably underprepared. This isn’t just stumbling around, though. To me it also applies to things like not seeming to know why you are giving the talk, or what you want me, the viewer, to understand when you are done.

If you can’t answer the questions “Who am I aiming this talk at”, “What is the one thing those people should leave this talk thinking”, and “Why is this story going to be compelling to those people”, you are underprepared.

Being nervous is a separate, but related issue. The best fix for presentation nerves that I know of is practice.

2. Overprepared

Yes, it is possible to be overprepared for a presentation. The symptom of this is usually a word for word script that the presenter is reading from, and not paying attention to the audience. The problem, though, is that your talk is brittle, and you won’t be able to adjust to an unexpected audience or environment.

3. Hiding

Most of these conferences are in rooms that are not designed for a performance by a single speaker. Think about a comedy club. The stage is small, not very high, and it’s in the middle. The audience is close together and close to the stage. This is a good environment for a performance.

Picture a hotel ballroom. The speaker is often set up in a corner, frequently behind a podium. The audience is often ten or fifteen feet away, and there is often a lot more space than people. That’s a hard way to go.

Don’t hide behind the podium. Move around. My biggest regret of the whole conference year was not insisting on a body mike at a conference, and having to give a talk from behind a podium. Own the space. You want people focusing on you first and the slides second.

4. Not interacting

A related point. Pay attention to the audience. In a tech conference situation, you are competing with everybody’s laptop and phone, which is to say you are competing with the entire Internet. Can you be more interesting than the entire Internet? At least for a few minutes?

People will pay attention to you as a speaker if they think you are paying attention to them. “[Insert Town] audiences are the greatest audiences in the world” is a huge performing cliché. You know why? Because it works. Anything that gets people involved gives them a little investment in paying attention.

When I was in college, I’d start stand-up sets by coming out with a tape recorder holding it up and explaining that I was recording the performance for my mother, and I’d really appreciate it if the audience could give me one big laugh. Cheesy? Practically coated in cheddar. Effective? Yes.

5. “My Tool Is Great”

This is a type of talk that bugs me. I gave one like this once, and it bugged me when I gave it. Define a problem. Don’t talk about any general part of the problem, just talk about your awesome tool that nobody else is using and why it’s awesomeness is overwhelming. Frequently, this involves ignoring any other way of solving the problem.

6. “My Company Is Great”

Oy. This one usually goes like this:

“At my company we have the perfect process. We never have meetings. In fact, if more than two people show up in the same room, we beat them with sticks. We deploy once every microsecond, and everybody can ask for a deploy, including the people at the company across the hall. We exist in a state of perfect harmony. If you are not like us, your company is substandard. Is that why you are sad? Join us.”

It’s a bit much, and I say that speaking as somebody who has generally been proud to identify with the companies I’ve worked for. What’s usually missing is a) the context of why good processes have taken hold at your company and b) what those of us who are not blessed can do to make progress toward Nirvana.

7. Trendy Slides

A personal pet peeve, and I don’t expect this to bother you as much as it bothers me. In a way, this is another standup thing. It’s easy to get a laughter from an audience without actually being clever. You can shock them, you can flatter them.

For me – and I think I may be alone in this – putting the latest meme in your presentation just because it’s there is in the same category. It’s quick, easy, the audience will react, but ultimately it’s a distraction from what you are trying to. Remember, you want the audience to focus on you, not the slides.

That said, it is possible to add a meme or something cleverly. It’s just that the bar is pretty high.

8. Illegible slides

Let’s make this simple: every word on your slides that is communicating information needs to be clearly legible from 50 feet away, period. The body text on the presentation I’m giving friday is 96 points. With the exception of a few code slides, there are fewer than 15 words on a slide – this is a performance, not an eye exam.

Dark text on light background is usually more visible in a projector context than light text on a dark background.

9. Not knowing the audience

This comes in a couple of forms.

  • Not knowing that your audience may have a different expertise or knowledge level than you expect.
  • Not realizing that people in the audience may be different in general, and have different reference points, or different standards of what is uncomfortable or offensive. They may have genders or nationalities different from your own. That doesn’t mean you have to be bland, but it does mean you need to be aware that there’s a wider world out there.

10. Incomplete lists of ten


I wasn’t going to write this, because it’s not like the Internet has a dearth of people writing about Steve Jobs who never knew him or interacted with him in any way. I wrote it anyway.

I’ve watched the first few minutes of the keynote introducing the iPhone several times. It amazes me – both as a seminal moment of technology and as a presentation. Jobs starts of by saying he’s been looking forward to this day for two-and-a-half years, and that he’s been fortunate to work on multiple “revolutionary” products in his career.

He says that “Today, we’re introducing three revolutionary products” – remember this part?:

  • “A widescreen iPod with touch controls” – he says, and the crowd goes nuts.
  • “A revolutionary mobile phone” – the crowd goes berserk, this is what they came for.
  • “A breakthrough internet communications device” – polite applause, but really, nobody knows what the hell he’s talking about.

He repeats the phrases, makes it clear that he’s talking about one device, “and we are calling it… iPhone”. Then he shows a gag picture of an old iPod with a rotary dial, and it’s funny – not a phrase normally associated with Jobs’ keynotes.

It’s a fantastic performance. Here’s the thing… People went crazy for the iPod and phone parts. Almost five years later, there’s no doubt that that part that nobody got at first – the internet communicator – is far and away the most revolutionary part of the iPhone experience. I had a phone in my pocket before 2007. I had an iPod in my pocket before 2007. The biggest change to my behavior from the iPhone is the way I can access the Internet from my pocket. (Yes, I know there were mobile phones that could connect to the Internet before the iPhone. I even used some. It wasn’t the same thing in an way.)

Which makes me wonder, why describe the device as an “internet communicator” at all, let alone have it as the last part of the description? I mean, it’s nice to have three beats in description, but the build from iPod (yay!) to phone (YAY!) to “Internet communicator” (huh?) is certainly weird. I assume that the “Internet communicator” part is there because somebody – presumably Jobs – felt that it was going to be important. Placed it last because it was most important. Even if nobody else realized that yet.

It’s been interesting to see how Jobs has been described in media reports, and how none of the descriptions quite fit. “Inventor”, “pioneer”, “visionary”, “technology titan”. They all have a grain of truth, but it’s almost impossible to imagine a short phrase that could encapsulate exactly what Jobs’ role was in all of these revolutionary products. At this point, the glib, writerly thing to do would be to claim that “Internet communicator” is the phrase that fits. It’s tempting, but kind of forced.

I used to say this: “Apple is a long-range experiment in how much people will pay for good design. And the answer is not much”. I said this for years, probably first around 1994. It’s become less and less true over the past few years, not because Apple is any less a design experiment, but because the audience has finally caught up with them and more and more people have been willing to pay for devices that are well designed. Jobs was the curator of that design sense, and that design sense has shaped the tools I use and the way I live and work.

Coming Soon: Getting Things Done In JavaScript

Okay, the blog has been very quiet for the last month or so. Please be polite and pretend you noticed. I’ve alluded online to a new book one or two places and now I think it’s far enough along that I can mention it in public without being too scared.

Let’s do this Q&A style, call it an infrequently asked question list…

Q: What’s the new book?

A: Great question. The working title is Getting Things Done In JavaScript. That may not be the final title. My proposed titles, Enough JavaScript to Get By and JavaScript for People who Hate JavaScript were (rightly) deemed unsuitable.

Q: Okay. That’s the title. What’s the book?

A: Here are some excerpts from my proposal:

  • The intended audience are developers used to doing back-end development, probably but not necessarily in Rails, who are increasingly asked to move functionality to the client, and are not familiar with the best JavaScript tools available for the job.

  • This book is aimed at developers who are explicitly working on front ends for web applications and looking for guidance on how to approach the simple parts first and the complex parts as needed. In my head, this is triangulated with three non-JavaScript books that I think are around that level: Beck’s Smalltalk Best Practice Patterns, Olsen’s Eloquent Ruby, and Valim’s Crafting Rails Applications.

  • Everything is test-driven. This book will contain more Jasmine than a Disney princess convention.

Does that help? Put another way, it’s the JavaScript book I wanted to hand our last apprentice when he asked for a good guide to JavaScript. Another way I’ve described the audience is people who have poked at JavaScript a few years ago, just got back into it, and aren’t quite sure why everything is an anonymous function these days. I’ve also called it JavaScript: An Idiosyncratic Guide, as in the thing you use after you have the information in the definitive guide.

Q: Why a book on JavaScript?

A: Because I was a guy who poked at JavaScript a few years ago, just got back into it, and wasn’t quite sure why everything is an anonymous function these days…

Well, that’s part of it. I felt like it was an area where I had something to offer, and where I could leverage the time that I had spent getting back into the latest and greatest JavaScript tools and make it easier for others to do the same.

Q: When can I buy it?

A: The initial draft is maybe 1/3 done. Ish. The hope is to get it available in beta sometime in November, and given the schedule that Pragmatic likes for books these days, to have the final come out something like January. That’s still an aggressive schedule, and I’m probably just a smidge behind, but I have a decent idea where I want it to go, and I’m making steady progress.

Q: What’s actually in the book?

A: The outline is still a bit in flux, but the basic idea is to take a pure server-side application and bit-by-bit move features to the client-side in a slow and not-even-a-single-tiny-bit-contrived way. The JavaScript topics are largely focused on creating what passes for objects, so there’s discussion of the object model, functions and scope, and the like – it’s not (at least at the moment) a tutorial on the basics of JavaScript. There’s a lot of jQuery, and a lot of Jasmine, and there will also be jQuery UI, jQuery Mobile, and Backbone.

That’s the story. Coming soon to a theater near you. Hope you like it.

What I Learned

As you may have heard, Obtiva got bought by Groupon. I’ve been traveling a bunch, so this coming week is my first full week in the Groupon office post-transition. And, well, someday maybe I’ll write retrospectively about Obtiva, but today isn’t that day. I’ll probably write about what I’m going to be doing at Groupon, but today isn’t that day, either.

Instead, I realized that month marks four years since I left Motorola and became a Rails consultant. In that time, I worked, for some definition of worked, on over a dozen projects and probably watched at least another dozen from down the hall.

I must have learned something, right?

I finished out this post, so I guess that means that yes, I do think I learned something. Here are a dozen or so oversimplified, fortune cookie-esque things that I think I learned in the last four years. Some of these are probably blog posts in their own right, which I may get to one of these days.

  • It’s a hallmark of successful engineering teams that they understand that if you do not need to make a decision, then you need to not make a decision. That’s sometimes called “preserving ambiguity”, and I remember from back in my days studying engineering education that it’s a hallmark of successful engineering teams across disciplines.

  • One reason why preserving ambiguity is necessary is that if you get too concrete too soon, then early decisions have a kind of gravity that makes it hard to escape them even when it’s best to explore the problem space more fully. A couple of times in the last four years, clients have come in with polished visual designs, and even if the layout and structure doesn’t work at all from a functionality or usability standpoint, it’s hard to escape the concreteness of the design to find a better design or a better definition of the project.

  • There’s very little that damages a team dynamic more quickly than trying to measure and compare individual contributions. (Technically, I learned this one at Motorola, but it still applies…) On a larger project, measuring subteam contributions also qualifies as problematic.

  • One thing you absolutely must have when coming out of your initial project meetings is a list of things that are not part of your project. Again, a common client pattern was trying to be the “YouTube of X” and the “Facebook of X” and the “Twitter of x”. Pick something to do well and do it well.

  • You can’t escape the software triangle, of scope, budget, and schedule. Keeping a project on track means saying “this is out of scope”, or “okay, we can do this, but that means something else needs to move out of scope”.

  • Hiring is so, so important. I once heard it said that the secret weakness of Agile was that one sociopath could ruin an entire project. That doesn’t mean “just hire your friends”, but it does mean that being able to work as part of a team is important.

  • If the business/management team and the development team trust each other, than almost any process works. If they don’t, almost nothing can fix it. One advantage of Agile methods is they provide a lot of quick, easy, and early opportunities for each side to show trustworthiness. (There’s definitely a longer post in this one…)

  • Because, ultimately, for a lot of our clients, working with developers is like going to the mechanic. When the mechanics say that the fitzelgurbber has been gazorgenplatzed, and it’s 500 bucks, do you trust them? Why or why not? How do you apply that back to your day job?

  • The development team’s job in an Agile project is to honestly estimate the cost of things, it’s the business team’s job to honestly estimate the value. Don’t cross those streams. It’s bad.

  • Agile is about managing change, not continuous change. If anybody on your project tries to justify a change with something like “we’re agile, we can change anything whenever we want”, run for the hills.

  • I didn’t say this, but I remember hearing it a few years ago. The right amount of process is just a little bit less process than you need. In other words, the slight chaos from too little process is much preferable to the overhead of too much process.

  • Look, I’ll admit that those of us that identify as software craftsmen sometimes get overly precious with our naming conventions and of course delivering business value is the number one priority. That said, if you are on a project and are being told to do less than your best work for the good of the project (by not testing, or by incurring too much technical debt), that should at the very least be alarming.

  • Pair programming has more overhead than is often acknowledged in Agile literature. I find that, especially on a small team, keeping a pair in sync time-wise is very hard. That said, I don’t have a better solution for code review yet.

Can’t wait to see what I learn this year. A lot of new stuff for me, should be interesting.

Bill James, Sabermetrics, and You, or At Least Me

I was a nerdy kid.

I suppose that isn’t much of a surprise, given how I turned out. But in those pre-computer days, I was nerdy about math and baseball. I was the kind of kid that kept a daily log of my batting statistics in the recess kickball games.

So you can imagine my surprise and happiness when this image appeared in Sports Illustrated, in May 1981. I was ten:

Bill James in Sports Illustrated

The man in the foreground is Bill James, who would soon go on to be one of the most influential baseball writers of the last thirty years. At the time, though, he was self-publishing his baseball book to a small but fiercely loyal group of fans, one of whom actually wrote the SI article.

In the background, on the scoreboard, was one of James’ inventions – a formula called Runs Created that purported to be the most accurate way to measure a baseball player’s contributions.

Okay, I’m getting carried away. The relevant point is that I was dazzled enough by the original article to start looking for James’ annual book once he started getting published and distributed nationally. As I said, I was young, and the books cost like seven dollars of my own money, so this was kind of a big deal.

I got lucky in my choice of baseball writers. Not only was James iconoclastic and funny, but he was very good at explaining his methods. And I don’t mean that he was good at explaining the math – James is the first to admit that he is no mathematician (admittedly joking, he once described the “standard deviation” of batting average as “about what your standard deviant would hit”). James’ skill was in explaining why he did his experiments in a particular way. In a very real way, the most important things I learned about how science works were from reading Bill James.

In, I think, the first book of James’ that I read, he responds to criticism of earlier work:

“Journalists start with the answer… [Sabermetrics] starts with the question”

Sabermetrics, by the way, was the word that James coined for the search for objective knowledge about baseball – “saber” from SABR, the Society for American Baseball Research".

In other words, where a journalist would start with “Derek Jeter should be in the Hall of Fame”, James would start with “Should Derek Jeter be in the Hall of Fame?”, and not in the lazy-local-news-headline way where you know from the question where the answer is. More likely, James would start with “What kind of player is in the Hall of Fame? Does Derek Jeter meet that standard?”

I suspect that this distinction is obvious to most of you reading this (though it’s easy to find places in our public discourse where nobody seems to understand it.) But it was a big deal to 12-year-old me.

Later, I remember an epic dismantling of the phrase “Pitching is 75% of Baseball”, starting with wondering what that even meant, and then going one by one through the things that would be implied of that statement was true, determining that none of them actually were, and eventually concluding that even the baseball traditionalists who were fondest of the claim didn’t act in any way consistent with actually believing it. I can still quote large chunks of that one.

Some quotes didn’t really become meaningful to me until I started writing myself:

“One of the operating assumptions of this book is that you either own McMillan’s Baseball Encyclopedia or don’t care what it has to say. In either case, you don’t need me to tell you what an outfielder’s assist totals are”

I’ve used some variant of that comment for every book I’ve written (though it didn’t always make into the final version). I’ve also used in when reviewing books. It’s a really useful way to think about your audience, to realize that you can assume knowledge of or disinterest in certain information.

Another quote that was big with me when I used to read academic papers all the time, but that I also keep in mind when I write.

“This isn’t a bull session, this is science. I only write like it’s a bull session because I don’t like how scientists write”

James is always been a little cranky on the subjects of professionalism and expertise, which he sees as often being used as nothing barriers to keep out the riff-raff.

“When you write something it is either true or false and being an expert or not being an expert has nothing to do with it”

What’s really stuck with me, though is the way James went about seeking more objective knowledge. The process was simple.

  • Ask a question.
  • Determine something that is observable that would be true if the answer to the question is true.
  • Use small, empirical measurements. James is the king of quick-and-dirty measurements that favor ease of calculation and understanding over multi-digit precision.
  • Compare similar items that differ in one aspect. In the mid 80-s James was more excited about a method to measure how similar two players were than almost anything else, because it allowed him to create controlled studies.
  • Follow the data. You probably won’t learn what you expect. Respect the data and respect its limitations.

If you are interested in James’ baseball work, the best introduction right now is probably the Historical Baseball Abstract, which is an overview of both his statistical methods and his historical interests. A more biographical look at his effects can be found in Moneyball, by Michael Lewis, which is about how the Oakland A’s applied James-style methods to actually win games. It’s a great non-fiction narrative, and Lewis is, as far as I can tell, unusually factually accurate.

James’ most recent book is Popular Crime, which is not about baseball, but rather a historical overview of crime stories that become pop-culture touchstones, and also the books that have been written about them. It’s cranky, scattershot, obsessive, and hard to put down.

Red Buttons, The Uncanny Valley, And BDD Workshops

I want to tell you about LoneStar RubyConf and how my session went and all that, but first I want to tell you this seemingly unrelated story.

Once upon a time, my Senior undergraduate project was an educational software tool I built to teach fractions to elementary school students. (To give you the time frame here, it was written in Visual Basic 1 on Windows 3, and I had to ship my own desktop to the school to ensure that they’d have something I could run it on. Also, I travelled to the school via dinosaur.) Anyway, the metaphor for the program was slices of pizza, and at the beginning of the game, the student saw an uncut pizza on the screen. Times being what they were, I was using the VB graph library to draw the “pizzas”, so a new pizza was represented by a red 3D pie chart, which means it basically looked like a red cylinder.

The first student sits down and starts clicking on the pizza like there’s no tomorrow. I immediately realize that the red cylinder that I had set up to be a pizza looked like a huge red button right in the middle of the screen. I couldn’t possibly have given it more focus – honestly, it looked like it might launch missiles or something. And I know, that even though I had never thought of it in that way, that every student is going to do the same thing and that I’m going to spend my day telling people not to click on the pizza. Which is what happened. And I felt like an idiot – how could I not have seen it before?

Which brings us to my workshop at LSRC, “Correctness is only a side effect: Improving your life with BDD”. Here was the plan:

  • I wanted the workshop to have kind of a code retreat kind of flavor, where the attendees would be able to focus on the pure process without regard for real-world constraints.

  • The idea was that there would be a hands-on code problem, some discussion of how that was done via BDD based on the student’s concerns, then some prepared material based on the topic.

  • The extended example was some kind of restaurant recommendation system, where each restaurant would have a score based on, at first, just ratings, then cuisine, price, location, and so on. The plan was to build up an increasingly complicated score function than show the process of using BDD to refactor it to it’s own scoring engine.

Well, that didn’t work out. Some of it did. The prepared material was decent – I’ve used a lot of it before. A couple of other things happened, of which the most interesting was how the attendees interacted with the problem.

I started by presenting the problem and mentioning that we were going to be focusing on testing a score method, because that was where the interesting logic to test was going to be. We walked through the failing test for initial conditions, did the method returning a literal to make the test pass, forcing a dynamic method with another failing test. So far, it seems to be going smoothly from my point of view. This was quite an advanced group of students – often when I do these workshops at regional conferences, the attendees are on the newer side, but this group was experienced, knowledgable, and already largely bought into the idea of BDD. (Based on earlier experiences, I had pitched the material maybe a little to beginnery for the crowd, causing me to worry if I was presenting any useful information to them at all).

Soon it’s time to break out for the first hands-on example, which is adding some new features to the score function. And the conversation went something like this: (I’m compressing this a bit for dramatic effect…)

Me: And the task is to make recommendations based on cuisine and price. You can do this by filtering a list of restaurants, or, I’d recommend trying to do it by modifying the score function.

Clever Attendee: How do we store the list of restaurants?

Me: Oh. Um. I don’t really care. In a real system the framework would manage that. You can explicitly pass an array of restaurants if you want, or just test the score function for a single restaurant.

Clever Attendee: Okay. But how should I store the list of restaurants?

Which was my red button moment. Of course somebody coming to this problem for the first time would want to know how things were stored. Of course a person who didn’t know what I had planned for the rest of the day would worry about that.

And I realized that I had landed in the uncanny valley of example problems – close enough to realistic for people to care about practical concerns, but not specified enough for those concerns to be nicely handled. And I missed it because I was fixated on how I would test the score method.

We worked through it, though, and even did another round of examples using mock objects to fake out a location service. Still, we weren’t able to get anywhere near my plan of building up a complex system via BDD. Again – my fault for not getting the example right – the attendees were all great.

Ironically, I think I could have gotten away with it if the example was in print, where I would been able to just work through the changes in the score example.

Toward the end of the day, I kind of got the feeling that everybody, including me, was a little frustrated, so I just came out and said it. “I think the prepared material has been fine, but I don’t think the example has really worked. Would anybody mind trying a more abstract, code kata-like problem via BDD as the last example.” Everybody pretty much unanimously picked the abstract example, and so we pivoted to the abstract problem that I wrote for Ruby Learning a little bit ago. People seemed to work on that enthusiastically.

In the end, I think I provided value for everybody that was there, many attendees said nice things. But I’m annoyed with myself that I wasn’t able to deliver everything I wanted to.

Lessons for next time:

  • For this workshop, it seems likely that a well-specified but abstract problem is going to be better than a less-specified but nominally real-world problem. I think if I did this next time, we’d build up a simple game.
  • The content of any workshop like this is always dependent on the attendees needs. As the presenter, I have to be paying attention to how people seem to be doing. As the attendee, you should feel free to let the presenter know what you are hoping to get out of the session and if it’s working for you.

So, thanks to those of you that came out – you were great, I hope you learned something, and I appreciate they way you helped me improve my teaching skills. But I really hope you learned useful stuff, too.

In The Jungle, The Mighty Jungle

A few quick notes about Lion, mostly first impressions and things I haven’t necessarily seen a ton of coverage on.

The install itself

This is, I think, my third major OS upgrade since I started using OS X all the time. It’s by far the easiest install. The biggest problem was the time it took to download the installer. I also had a problem where the XCode installer finished but didn’t register itself as finished, such that it appeared to hang. That took a little effort to track down, but wasn’t actually damaging.

Beyond that, though, nearly everything just worked. I had to reinstall exactly one Unix-y binary (ImageMagick, ever the outlier when dealing with annoying installations). I was afraid that I’d need to fuss with things like MySQL or my Ruby install, but by and large, I didn’t.

That Darn Scrolling

The most obvious change as you go to Lion is the new scrolling – it’s such a big deal, that Apple even gives you a dialog box on your first Lion boot reminding you that things have changed.

So, is the change irritating or merely annoying? Okay, for the first hour or so, it was completely unmanageable, to the point where I could feel the tension in my wrists from straining to remember which way to push the track pad.

At the risk of being obvious, what’s happening here is a metaphor shift. Rather than imagining that scrolling is the act of moving a window over your document up and down – moving the pointer down moves the window down and shows you a lower part of the document you now imagine that you are moving the document itself so moving the pointer down drags the document down and shows you a higher part of the document. As pretty much everybody has noted, this is exactly how scrolling works on iOS devices, where you the metaphor of dragging the document itself is much more concrete. (Weirdly, I used iOS devices for quite a while before I consciously started to think about how iOS was backward relative to the Mac.)

After a few days with the new scrolling I’ve basically got it. I find that if I don’t look at the scrollbars when I scroll, it’s much easier to imagine that I’m dragging the document. Also, for some reason, I took to the new scrolling most quickly in minimal apps or apps that are very similar to their iOS versions, such as Reeder. And I can’t seem to get it right in iTunes for some reason.

Is this change a good thing? Dunno. It’s clearly a thing. It’s a little weird to have something as fundamental as scroll direction be subject to user whim – I expect it’ll make pair programming interesting if it really becomes something that a significant minority of users don’t switch to the new version. There’s one problem with the new system that I think is unambiguously bad – since the scroll bars fade to the background when they aren’t used, it’s much harder to see how large a document is and where you are in the document from a quick glance. That’s a loss of information that doesn’t seem to be counterbalanced by anything. It’s also weird that you can still grab the scroller itself, and move it in the traditional direction (although since the scroller is now on top of the view in many apps, it’s sometimes hard to actually grab something at the edge of a document). My overall feeling is that this would make total sense if we had been doing it for fifteen years, but right now it’s going to feel weird for a while.

Another thing is that if the document is scrollable in two directions, it seems to be much harder to keep a pure vertical scroll without it drifting into a slight horizontal scroll. Also, I can’t imagine this working if you were using a mouse instead of a trackpad.

Overall look and feel

Broadly, it seems like there are three overlapping mandates for the look and feel changes in Lion – make interface elements less prominent (with the glaring exception of iCal), incorporate successful features from iOS, and animate anything that’s not nailed down. So scrollbars and other basic interface elements have become more muted across the board. Those changes are not dramatic, but I like them, they do tend to keep focus where it belongs.

I really like Mission Control as a re-imagining of Spaces/Dashboard/Expose. The Mission Control screen is very nice, easy to see, and it’s very easy to manipulate spaces – this is one case where the gestures really work. (I never was able to stick to using spaces before, but I have been using them a bit in Lion). The new full-screen mode doesn’t work for me, mostly because I’m often in a dual monitor situation, and the second monitor is ignored in full-screen, which seems a waste, but I can see how making each full-screen app its own space makes dealing with a bunch of full-screen apps much easier. Launchpad seems to be something that I don’t need, and it feels like it would be hard to manage.

The animations don’t bother me as much as they seem to bother other people – though ask me again about Mail.app in a few weeks. I’ve seen some complaints about the speed of the animation between spaces, but it seems reasonable to me.

That said, the iCal redesign doesn’t do much for me, but I’m not a heavy iCal user. Address book I like better, though I still think it’s a little hard to use. One feature that I do like is that, if you use iPhoto’s faces feature, Address Book can easily search iPhoto for pictures matching the name of the contact to use as the avatar for that contact.

Auto-Save and Versions

One of the biggest functional features of Lion is the auto-save and versioning. Lion-native apps auto save when idle or at a timed interval, and automatically save when the app is closed. They also automatically restore state when the app reopens. Apps have a Time Machine like interface to view old versions of the same document. Points:

  • Basically, this is awesome.
  • I think it’s going to be much harder to break my typing tic of pressing command-s at the end of every sentence then it is to adjust to the scrolling thing.
  • I also think it’s going to take some time to get used to the new “Save a Version/Duplicate/Revert To Saved” wording in the file menu.

One thing I haven’t seen commented on is that there seem to be two different kinds of version support in Lion. Which may mean that I’m getting this wrong. But it appears that there is a subtle difference between apps like Pages, Keynote, and other applications. In Pages and Keynote, you have access to every save point over the history of the document.

For other applications, if you are connected to your Time Machine drive, you have all time machine snapshots. If you aren’t you seem to have access to maybe the most recent time machine snapshot. I’m not 100% sure exactly what’s going on and I’m not sure yet if it’s an app thing or a document type thing – for example, it seems like Apple’s TextEdit can create multiple versions of a text document, but, for example, Byword can’t. But Byword is Lion-compatible, in that it has the new-style File menu. Ultimately, as cool as this is theory, it’s a little confusing in implementation.

New Apps

I’ve started playing with Mail.app, which I stopped using about two years ago on the grounds that it was really irritating. It’s a lot better now, with a more useful three-column layout (that can become a two-column layout), conversation threading, a really, really nice search feature and a bunch of animations that straddle the line between charming and annoying. For the record, the popout animation for replying I find a bit much, but they way sent messages fly up off the top of the screen kind of makes me smile. (And if you liked the animation from the App Store where the icon files into the dock, note that Safari uses something similar for downloads, and Mail uses it for replies.)

One nice touch that I haven’t seen called out much is that in Mail and iChat, and I’m not sure where else, inline url’s have a little arrow after them, which triggers a quick look preview of the web page, similar to the way Google’s quick preview works. That’s nice.

Anything else I can think of

Lion has also added a system wide autocorrect clearly based on the iOS version. I thought this was going to bug me, but actually I kind of like it. It appears to work a little better than the iOS version at identifying and correcting actual typos, the UI is a nice combination of unobtrusive but yet making you aware that a change has been made, and it’s much more responsive than TextExpander (which I love for deliberate macros, but which has always felt a little sluggish when correcting typos). Also, the autocorrect has fixed like five typos just in this paragraph, and only got one of them wrong. I’ll actually take those odds.


Too many words to say this: I like Lion so far, although some of the specific choices puzzle me cough iCal cough. It’s taken me less time to get used to the changes than I thought, and I’m finding some of the changes making definite improvements in my normal workflow.

In Which I Blather About Self-Publishing

So I tend to keep an eye on interesting things in the Ruby self-published technical book space.

This isn’t exactly recent, but I did want to mention and endorse Avdi Grimm’s Exceptional Ruby. This is exactly the kind of thing that should be happening in the self-publishing space. It’s a brief, thorough exploration of a very specific topic, in this case error and exception handling in Ruby. You may think you understand Ruby’s error mechanisms, but I’m pretty sure that unless you are actually Avdi, you will learn something both about the mechanics or Ruby’s exception handling and how best to robustly integrate error management into your code.

The book is clear and authoritative, not least because Avdi is up front about certain code patterns that he is presenting but has not had wild amounts of experience with. I like when a technical author is comfortable enough to admit less than perfect omnipotence.

Anyway, it’s $15 dollars at both exceptionalruby.com and at Pragmatic – Avdi worked out a deal where Pragmatic is co-distributing the book. Unlike what I did with Rails Test Pescriptions, Exceptional Ruby is just being distributed by Pragmatic – it didn’t go through Prag design or edits, and Avdi also sells it on his own. This strikes me as a very interesting experiment, and I hope it works out for both sides.

Which brings me to the latest from Thoughtbot, namely a new ebook on Backbone.js and Rails.

I need to start with a disclaimer – there’s a sense in which this book partially competes with my Not Completely Announced JavaScript book. Also, I haven’t read what they have yet, although quibbles aside, there’s a good chance that I’ll buy it. Also, I use all kinds of Thoughtbot tools and I have a lot of respect for them as a team.

Okay, we clear?

Thoughtbot is producing a new ebook – apparently as a group, because they aren’t listing specific authors. (As a matter of marketing, and consumer confidence, I really recommend that they list the authors…). They have an extensive outline on the site, although they don’t estimate the final page count. The distribution model is interesting – when you pay, you get access to a github repo containing up to the moment source code that can be converted to a variety of formats. (Though it is unclear if any format other than HTML is supported immediately). The outline appears to be solid, can’t quibble with any of that yet.

Now how much would you pay?

It’s $39. Until August 1, when it goes up to $49.

That is a bold pricing strategy.

Which doesn’t mean it won’t work out fine for Thoughtbot.

To put that $49 in context, that’s more than double most Pragmatic ebooks. It’s almost triple what O’Reilly sells their new jQuery Mobile book for, which would seem to be a reasonable comparison, topic size wise. And, of course, it’s five times what I self-published for a few years ago. More on that in a second.

Offhand, I can think of three reasons why they might try that pricing strategy:

  • Value pricing: if this book saves you an hour of research or coding, then that easily covers the price for most purchasers. Which is true, if not exactly how the market prices technical books. But if you look at it as a fraction of what a typical training course costs, then it makes more sense.

  • Profit pricing: Thoughtbot may have decided they need to price at this level to make the cost in time spent on the book worthwhile to them.

  • Boutique pricing: Thoughtbot may want to place a marker down as experts in this space, but limit their customers to people who are seriously interested in both the subject and the somewhat interactive model they have chosen for creating the book.

All these arguments seem valid, or at least defensible, and I have no idea what Thoughtbot’s strategy actually is. I’m really curious to see what happens, though. I’ll report back after I buy it and they get some time to put content in place.

It seems to me like part of the marketing side self publishing a book is giving potential readers as few reasons as possible to not buy the book. Right now, there are a lot of reasons here – the price, the lack of a sample, the lack of an author or publisher who might have a track record (although obviously Thoughtbot itself has a great reputation, and this will be more meaningful to some people than others). Some of this will correct itself over time – if things are good, they’ll get some word of mouth – testimonials would be a great thing on their website.

Which is a roundabout way to say a couple of things about self-publishing based on my own experience.

First is that it’s wildly clear that I chickened out on the pricing. (Rails Test Prescriptions was $9 when I self published it.) I could make up something about how I was pursuing a mass-marketing strategy and blah, blah, but the simple fact was I was petrified that nobody would see value in it if I went above $9. In retrospect, I probably could have gotten away with a higher price.

The other mistake I made – or what could potentially have been a mistake – was to not set a finite goal. Avdi, I think, has this exactly right. He took a specified chunk, wrote about it, and called it a day. When I first started with RTP, I said a lot of things about how I would keep the book updated. It didn’t occur to me until after I started selling that I was setting myself up for an infinitely long task. Again, though, I was afraid that there would be a lack of perceived value in a book that ended, and obviously one of the potential advantages of an ebook is ease of updating.

One thing the Thoughtbot team has right, though, is an easy way of updating – their book will be a git repo. I hope, though, that they’ll separate in-progress from edited and reviewed by putting them on separate branches. I messed this up a bit by assuming that my distribution channel could handle it and then having to come up with a stopgap fairly quickly.

I will say, though, that publishers and editors are somewhat like the government in that when they do their jobs well, you don’t realize how much value they can add. There’s a process for doing things that the author might not want to be involved in – design, indexing, distribution.

I don’t have a grand conclusion here – I’m very interested to see all kinds of experiments with self-publishing, I don’t think anybody really knows how things will play out.

Old Testing Interviews

Back in January 2009, I did a bunch of interviews with prominent Rubyists about their test practices. The interviews vanished when I moved the site to WordPress, but I still get hits from a link to the interviews, and I thought it would be useful to get them all in one place.

Remember, this was 2009, and I’m sure everybody’s habits have changed since then. Other than putting them all together in one post, I haven’t edited these at all.

Noel Rappin

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

I started with automated testing very shortly after reading Kent Beck’s original XP book. The XP book came out at a time when I was very receptive to the ideas—I had just come off a project that had suffered from a lot of regressions and all the other kinds of pain that XP promised.

It didn’t take long for me to see how much better my code was when I did a lot of testing… what was more surprising was how much more fun writing code test-first turned out to be. The quick feedback and the ability to clean up code with confidence turned out to be really satisfying.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

When I’m adding a new feature, I tend to start with a skeleton controller test that validates that the controller sets the right variables. I don’t put much code in the controller, so then I move to testing the model for the new functionality. If the view logic seems to require it, then I’ll add view tests after I get the view in place. I go back and forth between test and code pretty quickly, but sometimes the code will get ahead of the tests, especially when doing view layer stuff. I don’t use integration tests very much at the moment.

I seem to have moved back into the core Rails test features recently, although I still use Shoulda for contexts and for the additional assertions. My most recent project used core Rails plus Matchy. I’ve also been using the various factory replacements for fixtures, which I like quite a bit.

What’s the most interesting thing you’ve discovered about testing recently?

The biggest change I’ve made recently is using factories for generating test data, which makes the tests much more readable and stable by keeping the setup closer to the actual test.

Is there a tool you wish you had for testing that you don’t think currently exists?

I wish I had a really good way of validating view logic, none of the ones I’ve tried have been completely satisfying. It’d also be nice to have more sophisticated coverage reports. Of course, these things might actually be impossible…

What advice would you give somebody looking to write more effective tests?

Automated testing is much easier and more valuable if you keep a tight feedback loop between your tests and your code.

Geoffrey Grosenbach

First up on the Testing Practices Interview series is Geoffrey Grosenbach, Senior Visionary of Topfunky, and also the person behind PeepCode. Geoffrey blogs at http://nubyonrails.com/, and is responsible for the gruff graph generator and, most recently, a task tracker based on David Seah’s Online CEO. He was also kind enough to write his responses in Textile, which I heartily endorse. Take it away…

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

I remember watching tests run during installation back when I was using Perl (wouldn’t that be nice if RubyGems optionally ran their test suite during installation?). But it seemed like an advanced topic that only some programmers did.

When I started using Ruby and met the testing fanatics at Seattle.rb, I started to understand what it was about and why I might want to write a test.

Three things helped me get started with test-driven development:

  • Watching other people do it.
  • Writing a graphics library (gruff). I needed to generate a bunch of samples with various data inputs and Test::Unit was a great way to do it.
  • Finally, I started out by writing a single test for an existing Rails app whenever I encountered a bug. It gave me peace of mind.

Since then, I’ve appreciated the process of thinking that I get into when I code test-first.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

I’ve tried several libraries and tools.

I started with Test::Unit and still use it on some existing projects.

For a while I used Jay Fields’ Unit-Record style of separating out unit and functional tests for both models and controllers (see also). It also provided a nice test method that took a string and a block of assertions (similar to what’s in Rails now).

I’ve used RSpec’s ability to add should syntax into Test::Unit.

I’m currently happy with straightforward RSpec. I also have some Test::Unit integration tests in my Rails apps but have also used RSpec User Stories and their replacement, Cucumber. Given the fact that I’m both the designer and coder of most of my apps, I don’t get much benefit from Cucumber. But I can see how it would be useful to people working for a semi-technical client.

Honestly, it’s a bit overwhelming with all the options out there!

When I’m actually coding, I’ll use Eric Hodel’s ubiquitous
autotest or rstakeout to run my test suite.

What’s the most interesting thing you’ve discovered about testing recently?

I’ve been working on a small command-line Objective-C app and am experimenting with using Ruby to run a suite against the command-line app to check the inputs and outputs. Ruby is useful that way and works better for me than trying to use Objective-C for the same purpose.

Is there a tool you wish you had for testing, but which you don’t think currently exists?

I can’t think of one. Usually I end up writing a tool if I need it and I can’t find it anywhere, such as test_benchmark to show individual test runtimes for Test::Unit. Someone recently imported it to GitHub as well.

What advice would you give somebody looking to write more effective tests?

Find a mentor. Work with someone else who is doing it. Concentrate on testing the effects of your code, not the way they are implemented. It’s easy to write tests that really don’t do anything and won’t reveal meaningful changes in the code if it stops behaving properly.

Gregg Pollack

Next up in the Testing Practices interview series is Gregg Pollack. Gregg is one of the proprietors of Rails Envy, and is one of the co-hosts of their Rails Envy Podcast, which mentioned Rails Prescriptions today—thanks Gregg!

Gregg is also one of the founding members of the Rails Activists. He’s also done a lot of video production, including some excellent ruby and rails screencasts, and his series condensing various Ruby and Rails conferences. Put it all that way, and he seems kind of busy, actually…

Take it away, Gregg…

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

I have to admit, my first 3 Rails projects didn’t contain any tests. I got into testing when RSpec started on the scene. RSpec just made more sense and the documentation on the RSpec website was really useful. Once I figured out how to use RSpec with autotest and growl, testing became much more fun.

I also ended up doing a talk at my local users group about how I came to love testing. It’s a little dated, but still quite relevant:


What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

I used to write isolated tests at the model and controller level using RSpec, properly mocking and stubbing at the controller level. Often times integration tests would get ignored.

Currently I’m working on a project using Shoulda for Model tests and Integration tests with Webrat. Yes, we’re not doing controller or view tests. So far I’m really liking the combination, and it seems to cover things pretty well without having to deal with much mocking and stubbing of controllers/view tests which have very little logic anyways.

What’s the most interesting thing you’ve discovered about testing recently?

Webrat rocks for integration tests.

Is there a tool you wish you had for testing, but which you don’t think currently exists?

Hmmm.. James Golick recently blogged about one line tests using a library called Zebra. He also argues that test names are essentially comments, and well.. too many comments are a code smell.

So what’s the alternative?

Creating a DSL that allows us to write tests in a way that doesn’t need names/comments. Shoulda gets us pretty close with all of it’s one line helpers like:

should_belong_to :user
should_have_many :tags, :through => :taggings
should_require_unique_attributes :title
should_only_allow_numeric_values_for :user_id

None of these tests need comments to figure out what they’re testing! I’d love to figure out a way to do more of this, and the Zebra library James put out is certainly a step in the right direction.

What advice would you give somebody looking to write more effective tests?

Integration tests are probably more important then anything else, and using a library like Webrat makes them very easy to do.

If you’re working with a team of people and you want to ensure you’re building a solid test library then a Continuous Integration server is imperative. Set it to run all your tests every time something is checked in and if it fails to email everyone. Make a rule that whoever checks in code that causes tests to fail has to buy everyone a round of beer, or has to perform some humiliating task. Checked in code that fails should be fixed immediately.

Ryan Bates

Next up on the testing interviews is Ryan Bates. Ryan runs Railscasts, a weekly screencast on a new Rails topic that is simply one of the best ongoing sources for tutorials about Rails. Seriously, if you aren’t familiar with it, drop everything and prepare to spend some time watching his videos. Ryan has also done two screencast series for Pragmatic, Everyday Active Record and Mastering Rails Forms, both of which are available at pragmatic.tv.

On a related topic, I didn’t introduce myself to Ryan at last year’s RailsConf, even though I walked past him a few times. This is because every time I walked by him, people were coming up to him and thanking for all the great Railscasts. So, thanks Ryan.

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

About 6 years ago I read the book Extreme Programming by Kent Beck. This sparked my interest in testing (specifically TDD), but I could not find many practical examples of the practice. I spent some time researching the topic but honestly did not “get” it until Rails came along. Rails provided practical testing patterns which were fairly easy to follow.

I find the most difficult part of testing is coming up with a pattern which works well for a specific situation. Once that is done, adding similar tests becomes very easy, and that is where it starts to really pay off.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

I primarily use RSpec for testing, however my tests are quite different than what they recommend. For one thing, I use controller tests like functional and integration tests. That is, they execute the entire stack (including models and views). I don’t test views exclusively beyond this because I find that requires too many mocks and leads to brittle tests.

I test models and helpers exclusively (like unit tests). That is, I test each method on its own to ensure it functions properly. My theory is, the more deeper a piece of code is, then the more it is used by various parts of the application, and therefore should have better test coverage.

Fixtures are kind of interesting. I don’t use them at all in unit tests, instead I prefer factories (factory_girl) for this. However I do use fixtures in controller tests as filler data to help catch errors. Each fixture usually does not have more than two records, and I often leave them with their default generated content.

What’s the most interesting thing you’ve discovered about testing recently?

I just recently discovered the RR mocking framework and I like its syntax more than Mocha. However I haven’t moved many projects over to it yet, so I can’t say how well it works in real world use.

Is there a tool you wish you had for testing, but which you don’t think currently exists?

Perhaps a tool for testing private methods and accessing instance variables in a clean way. I know in theory tests shouldn’t need to do this, but I would still find it useful. There may already be one out there, I haven’t looked much.

Beyond this I would love to see more documentation, examples and experiments done with regard to testing. I still feel it is a fairly unfamiliar territory in the programming world, and everyone seems to have their own way of doing things.

What advice would you give somebody looking to write more effective tests?

Be careful with mocks and stubs. They are often an easy, immediate solution but can lead to brittle or deceiving tests. Only use them if you can find no other cleaner way to test something.

Overall, don’t give up on testing if you don’t grasp it right away. Try a technique for a while, if it doesn’t work with your flow, try something else. Don’t feel bad if you find testing is hard – it really is. But it is so worth it.

James Golick

On to the interivew. James Golick is the founder of GiraffeSoft, a boutique Rails consulting firm out of Montreal. He also maintains the James on Software blog. Within the Rails community, he’s the author of resource_controller, a common parent for RESTful controllers, and active_presenter, which allows you to create presenter objects out of aggregations of ActiveRecord models.

Most recently, James has created zebra, a test library for the quick creation of single line tests.

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

I worked at a few really cheaply run companies, where I was the one man technology department. I didn’t sleep much in those days.

In those days, I was always desperately looking for ways to get better at what I was doing, if only to get the occasional extra hour of sleep. At one point, I came accross an article about automated testing and TDD, and it all just made so much sense to me. When you’re that strapped for time, automation is a necessity. Once I was introduced to the idea that tests could be automated, too, I jumped all over it.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

At giraffesoft, we’re very serious about TDD. So, naturally, everything we do is test-first.

Currently, we write extensive unit tests and functional tests. We’re slowly adding cucumber to the mix. I’m definitely sold on the benefits of acceptance test driven development. So, that’s where we’re going.

We use Shoulda, largely because of its macros. Duplication in tests becomes incredibly tedious. So, expressing certain kinds of repetitive tests as one-liners is a huge win.

However, as I mentioned in the release announcement for zebra, we’ve started to feel the burn with Shoulda’s macros in certain situations. Often, test failures result in completely useless backtraces and the string programming catches up to you after a while.

So, we’re currently moving towards a context & zebra stack to replace Shoulda.

What’s the most interesting thing you’ve discovered about testing recently?

Using Jay Fieldsexpectations testing framework completely changed the way that I approach unit tests. Not having to describe each test in english is incredibly liberating.

If your code is readable, you shouldn’t need to document it at a micro level, except in special cases. Your code probably isn’t littered with comments describing every couple of lines. So, why should your tests be?

Is there a tool you wish you had for testing, but which you don’t think currently exists?

If you’d asked me 2 weeks ago, I’d have replied, something that would allow me to write more expectations-like tests in my every day hacking. That’s what zebra is. So, now I’m feeling pretty happy about my toolset and where things are headed.

What advice would you give somebody looking to write more effective tests?

Be pragmatic. I get a lot of questions about the “proper” way to mock or stub something, for example. Stop worrying about getting things “right” and try to make judgements that get you the best possible test, while striking a balance between productivity and the longevity of the test.

Additionally, I’d really encourage people to use expectations for a small project – a rails plugin or something. For various reasons, you probably won’t want to use it for every day stuff, but you might learn a lot from giving it a serious look.

Chad Fowler

I’m very excited to have Chad Fowler as the latest participant in the Testing Practice interview series.

Chad Fowler is an internationally known software developer, trainer, manager, speaker, and musician. Over the past decade he has worked with some of the world’s largest companies and most admired software developers. He loves to program computers and, as part of his role as CTO of InfoEther, Inc., spends much of his time solving hard problems for customers in the Ruby language. He is co-organizer of RubyConf, and RailsConf and author or co-author of a number of popular software books.

And so, let’s hear from Chad…

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

For me it was when I was exposed to TDD for the first time. I had been practicing the typical “guru reads the output” style of testing, primarily in Java at the time. That means every class typically had a main() method at the bottom which would exercise my code and print a bunch of hardly decipherable junk to the screen. As I was developing, I knew what that junk meant. Nobody else ever did. Two days later, neither did I. But the main() methods remained. Because, hey, those were the tests.

I think the way most people worked in an environment like that is that if they needed to change anything in the production code, they would hack the existing “tests” in the main() method such that they could understand what they meant (since this stuff was embedded in production code, you didn’t typically venture out of main() for fear of polluting the namespace). So it was more of a scratchpad than a test.

At the same time, I was doing a lot of mentoring of junior developers on how to do object oriented programming. Specifically, I was trying to help a large group of developers stop generating unmaintainable spaghetti Java. I started using a technique that I call Error Driven Development. It was very much like TDD, which I had not yet heard of. You start in the area of the application you’re trying to implement. Maybe it’s a controller in an MVC setup, for example. And you type in the code you wish already existed as an API. You express your intent as clearly and succinctly as possible within the scope of what would be technically possible in this magical but not yet existing API (paying attention to which data needs to be passed around as parameters, which imaginary objects would best play the role of owning which function, etc.). Then you try to compile and/or run your code and follow the error stream until everything works.

With this kind of development, you get to always work at the level of abstraction you’re interested in while you’re developing. When I’m in a controller, I don’t care about SQL. When I’m in a view, I don’t care how business logic is implemented. To make everything run, of course, I have to walk down through the layers of abstraction and repeat this process—-imagining the perfect API and just using it. Eventually I’m done. It’s motivating and makes better code.

So, the question was about testing. This Error Driven Development technique was just a lame version of how good TDD works. TDD gives you the extra advantage of a nice framework with assertions and reports. So the first time I saw TDD, I was hooked. It was a better version of what I’d been working toward in my quest to write and help others write better code. It just happened to also create tests as a side effect.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

I use whatever testing framework and tools the team I’m working with uses. I’ve done everything from out-of-the-box test/unit to RSpec. Given a choice these days, I’d probably depend on Shoulda and Mocha. RR is really interesting as well but I haven’t fully switched to it. I suspect I might replace Mocha with it at some point in the near future.

I typically start by writing model tests. They’re called unit tests in Rails, but they’re rarely isolated unit tests. Ideally, as much logic as possible lives in the models, so I spend a lot of time here. By far more than anywhere else. I do everything test-driven unless I’m hacking something together quickly. Even then, I usually reach a point where I wish I was doing things test-driven and switch.

Ideally, your controllers are going to be tiny. They’re also likely to be composed of calls to objects and methods from your model layer. So, though I do functional (controller) tests, I try to minimize the need for them. If you’re already testing a method in a model, you don’t need to duplicate that test in a controller if the controller is simply calling the model. You do need to make sure the controller is doing its job well. That’s where things like mocks come in. I use mocks not so much to avoid calling code in the dependencies an object has (such as the classic credit card processor example) but more to allow me to specify a process in terms of what the code I’m testing is supposed to do vs. how it does it.

Ultimately, it’s a good idea for someone to actually write real automated tests. These aren’t the ones I do unless I’m playing the role of tester. For example, Selenium is an excellent tool for really testing a Rails app. It’s great to have automated tests at that level that run with a continuous build and so on. I don’t usually actually do that so it’s not part of my process per se, but I’d always advocate that it be part of a team’s process. I don’t get much value out of trying to do selenium-first development, though, for example.

What’s the most interesting thing you’ve discovered about testing recently?

I wouldn’t call it a discovery, but I’m starting to change a long held opinion about the value of tests. I used to think of them as executable requirements specifications. I know a lot of people do. I’m from the school of TDD that blossomed into what’s now called BDD. BDD people even tend to use the word “specify” when they talk about tests they write up front.

That always sounded like a great idea. Requirements docs you can execute for validity. In my experience it rarely works out that way, though. Tests don’t end up being readable like english. RSpec and especially Cucumber are a step in that direction, but I’m starting to believe that ultimately developer tests should read like good code. Maybe a little different from normal good code, but they are code after all. And they’re not for validating the production code you write. They’re for motivating the production code you write.

So maybe the goals of executable requirements documentation and motivational specs are at odds with each other. And if the tests do the job of driving you to make well designed code but don’t really read like requirements documentation afterward, that’s nothing to feel bad about.

Maybe it’s even OK to throw away the tests eventually in the same way we used to throw away the code in our main()-method scratch pads.

I’m pretty sure I’m exaggerating, but that’s the general idea.

Is there a tool you wish you had for testing, but which you don’t think currently exists?

Not really. Marcel Molina and I used to talk about how we longed for something that would sit in the middle of our objects and their method invocations, such that you could set up how you expect an object to behave and then verify, without overriding the method’s behaviors, that the object did the things you asked. Like a partial mock which doesn’t change the method implementations it’s setting expectations for.

RR now does this with its proxy implementation. Now that it exists, though I like the feature, it doesn’t feel like it filled a big hole. Go figure.

What advice would you give somebody looking to write more effective tests?

Assume that writing more effective tests means writing better code. Developer testing (which is what I do) isn’t primarily about verifying code. It’s about making great code. If you can’t test something, it might be your testing skills failing you but it’s probably your code code’s design. Testable code is almost always better code. Code written as a result of a series of failing tests is very likely (by definition) testable. (An example of a design choice in Ruby that might result from this sort of approach is to use more mixins and less inheritance.)

That being said, it’s easy to fall into a trap when you start coding this way. I often come across heavily TDD’d code with a huge focus on some trivial but easily tested feature. For example, you might start writing tests for the Ruby comparison method (<=>) or to_s on an object, simply because you know how to write tests for it. I’ve seen programmers spend a disproportionate amount of time testing and implementing ancillary features because they get the TDD (or BDD) bug and find a comfort zone to hang out in.

Instead, always focus on testing the core of your domain. Other tests are nice to have, but when you focus on the core of your domain (the features that define the product you’re implementing), you drive that domain model forward and avoid spinning your wheels on testing for the sake of testing. Kent Beck used to say “test everything that could possibly break”. That’s good advice, but I’d add “and actually matters”.

July 15, 2011: Stale Links

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.

June 30, 2011: Among Other Things, Me In Texas

So, as threatened on Twitter, I decided to overreact to Vim users by trying out BBEdit for my Rails development. Expect a write up soon, but the first pass is that it’s clearly a very powerful program, but it also clearly was developed in response to a set of needs that are not completely congruent with my needs.

1. Contains Me

I’m very excited to mention that I’ll be doing a day-long training session at Lone Star Ruby Conf. The session is entitled Being Correct is Only a Side Benefit: Improve Your Life with BDD. Here’s how I’m describing the session:

In this workshop, attendees will build a complex program using the strict BDD process. Along the way, they will see how BDD improves developer speed and code quality, learn the five habits of highly successful tests, and discover how to best leverage existing tools to improve their coding life.

It’s going to focus on the BDD process itself, rather than on specific tools, and on the benefits to your code from writing tests first.

You can sign up for the session at the Lone Star page. Please sign up, it’s going to be a lot of fun, and we’ll all get better at testing together.

2. Ruby Readability Links

Here are a few recent links on readability and Ruby code

Josh Susser would like to tell you that a meaningful symbol is a better argument than a boolean, while Martin Fowler suggests that it’s even better to have separate methods for each flag value.

Meanwhile, Phil Nash wants to be very clear that he doesn’t like the alternative Ruby 1.9 hash syntax y: 3 as the replacement to :y => 3. I have to admit, I’m not sold on it yet either, it still looks weird to me.

3. Postgres

One of my takeaways from RailsConf this year was the idea that the Ruby community is starting to shift toward PostgreSQL as a database, citing PostgreSQL’s superior performance and stability.

Ruby Inside presents a tutorial from Will Jessop about how to install PostgreSQL on OS X systems. It’s nice, though I’d really like to see the grab-bag of Postgres tools alluded to in the post.

4. Verbosity

Meantime, there was another debate going on about Ruby’s verbose mode, including Mislav Marohnic describing how Ruby’s verbose mode is broken, essentially because verbose mode is both verbose, and a code lint, whereas it might be more useful to separate the features.

For his part, Avdi Grimm extends the post and defends verbose mode by describing how Ruby’s verbose mode can be helpful, and providing a different perspective on some of the warnings.

5. Drumkit

Just yesterday, Obtiva’s own Chris Powers presented his nascent JavaScript web framework called DrumKit.js. The goal of DrumKit.js is to provide a framework where as much code as possible can be shared between the server — in this case running Node.js, and the client — running in JavaScript on the browser. So, once the page goes to the client, subsequent requests are handled in Ajax, but the application code remains the same.

It’s a super-cool idea, and I’m looking forward to it getting fleshed out and expanded over time.

iaWriter for Mac

I’ll say up front that I’m skeptical of claims of “distraction-free” writing environments, especially the super-precious over the top ones, for all the reasons that Merlin Mann has laid out in various easily findable places on the internet.

That said, I think I really like iaWriter for Mac. And I say that even though I’ve basically abandoned iaWriter/iPad in lieu of somewhat more functional options, like Nebulous and Textastic. But on the Mac, I already have more functional options, and although I was originally skeptical of when I might use iaWriter, I think I have found a niche for it for quick writing tasks like blogging and taking notes.

Having used iaWriter for about a week (this post, plus the last few daily posts, plus some other note kind of things), I think that the “distraction free” frame is a little misleading. iaWriter is not distraction free in the sense that a white room is distraction free. It’s distraction free in the way that a race car is.

Forgive me for this metaphor, I’m not a big car guy. It feels like every part of iaWriter has been precisely engineered to reduce friction and become fastest possible path between your brain and a text file. And if that means that some luxuries have been jettisoned, like cup holders, or comfortable seats, or the ability to change fonts… well, nobody expects a race car to take them to the grocery store.

Visual impressions

It really is a beautiful app. I still really love the Nitti Light font and although it’s minimalist, the type is crystal clear, easy to read. The thing loads almost astonishingly fast, the background is subtly textured so you know it’s there, but doesn’t call attention to itself. The cursor is a big thick blue bar, easily visible but not garish. The window drag bar is small, and fades away if you start to type. There are no preferences, and only a few toggleable menu items.

The width of the page is set to 64 characters, and you can’t change it. There’s a nice margin around the text, but if you go to full screen mode, it looks goofy — a huge margin around a strip of text. (Actually, I think one of the reasons why it feels like I can get text down on the page so quickly is the 64 character limit is smaller than my normal default of 80 which means that I run through lines faster than I otherwise would. The font is big — I normally type with a big font, and this feels natural to me. Again, easy to read. When you hit the bottom of the screen, the cursor and the writing space snaps back up a bit (in focus mode, it snaps back to the middle of the page, which I really wish it would do in regular mode as well).

There are keyboard shortcuts to move up and back one sentence, which I guess is the Mac analogy to the iPad version’s special keyboard navigation. And there is focus mode, which fades out everything other than the current sentence. I don’t know about that one, I think it pushes things too far, but if it works for you don’t listen to me.

iaWriter has a kind of semi-wysiwyg mode based on Markdown, where things that are marked as bold or italic in Markdown will have that font applied, which is nice. Also, when writer sees a line that starts with a Markdown decorations like # for headers and * for bullet lists, it will put the decoration in the left margin so that the text remains lined up with other text. The effect is interesting, making it easy to scan the document for headers, but the fact that all header levels get the same font treatment is a little odd.

What I can say about it, is that using it for five minutes made me want to find something to write so that I could use it some more, and even try and figure out a way to work it into my blogging workflow.

Some oddities

New files open in a window that is only a few lines high, which I think is a little strange.

It remains irritating that you can only open files that are of type .txt and .markdown. I’d love to try some others.

It’s a major irritation that it does not remember what files were open when you reopen the app. Nor, somewhat astonishingly, does it remember the settings for spell and grammar check. This will apparently be fixed in a future release.

A couple of spacing glitches, it fades the last line to grey at the bottom of the screen, which is kind of cool, except when you are actually typing in that line, in which case it still fades the line and it’s a pain. The docs claims that it maintains indentation if you indent a little, like for a Markdown code block, but I’ve found that intermittent in practice.

June 23, 2011: Distributed Magic Control

1. Today’s News: Github for Mac

Odds are you heard this one already, but the fine folks at GitHub announced a Mac desktop client. It differs from, say, GitX in that it attempts to be a front end to your entire GitHub account rather than one particular repo.

I haven’t used it a ton yet, but a couple of quick impressions:

  • I think we can now definitively say that Tweetie and Loren Brichter is to the current set of Mac applications what Delicious Library was to the batch a few years ago — the source of a widely used design aesthetic.
  • It’s got a nice set of branching features, the one thing I’m really missing is a way to browse the actual current state of the files in the repo, though I guess you can always go to GitHub itself for that information. It feels a bit feature-light overall.
  • I’m guessing the main users of this initially will be team members who aren’t commonly on the command line, but who need current code, like designers. (Though I do use GitX a fair amount to visualize history, and might use this in its place for some things). The merge tools are interesting, I’ll probably try them once to see what they are like.

2. JavaScript Gripes

If you think the main problem with this blog is that I don’t link to enough cranky rants about JavaScript, here’s one by Fredrik Holmström, of the IronJS project. The strong claim is this:

my point of view after having developed IronJS is that there are a couple of critical problems with JavaScript that prevents it from ever being a viable alternative as development platform for server application development.

I suspect the gripes themeselves will be broadly familiar to JavaScript fans — lack of namespace support, crazy language design choices, lots of run times. It’s nicely ranted, though points off for using the comparison between JavaScript: The Definitive Guide and JavaScript: The Good Parts, that’s kind of hacky.

3. jQuery Mobile Goes Beta

jQuery mobile came to my attention via Obtiva apprentice Carl Thuringer. It’s a cross-platform framework intended to simplify web applications targeted at mobile browsers using HTML 5 and JavaScript. It looks really nice, and they just announced beta 1

4. Pottermore

Also nearly breaking news about another RailsRx obsession, ebooks. According to multiple sources, J. K. Rowling’s new Pottermore site will be the curated official fan site she’s always wanted. Also, Rowling will apparently self-publish cross-platform ebooks of the Potter series.

This is interesting for a couple of reasons, not least of which is that it’s another blow to the long-standing model where publishers and labels used bestsellers to subsidize everybody else. As far as I can tell, nobody has mentioned what she’s going to price the books at, but it seems like her overhead costs per-book at this point are rather low. I doubt she will, but it’d be interesting if she tried to break the current price structure by hitting a $4.99 point. I suspect she’s more likely to do a middle ground of $9.99.

5. Soccer Stats

And, as a longtime baseball stat nut, this article about new statistics taking over soccer was interesting. One big flaw in the new soccer stats is obviously that it’s nearly impossible for the casual watcher to track the stats, since they are measuring things like how much distance each player runs at top speed and the like. Still, I like the look at how you even begin to measure a complicated system like this, and how you determine what’s important to look at.

June 21, 2011: In Brightest Day

I’d like to pretend there was some thread connecting these things, but you and I both know there just isn’t…

1. Actual News: Cucumber 1.0

Starting with something approaching a real news story, Cucumber 1.0 was released today. According to that post from Aslak Hellesøy, the project has had nearly 750,000 downloads. Oh, and there’s a native JavaScript port in progress. I didn’t know that.

Anyway, Cucumber 1.0 adds Rake 1.9.2 support. Recent changes you may not know about include a -l and --lines command line switch as in RSpec’s and a new transform syntax that allows you to factor out duplicated parts of step definitions. Haven’t seen official docs on this, but it looks like it allows you to capture bits of step definition and run a block against it. The code example within the Cucumber tests looks like this:

Transform(/a Person aged (\d+)/) do |age| 

Given /^(a Person aged \d+) with blonde hair$/ do |person|
  puts "#{person} and I have blonde hair"

In other words, the snippet a Person aged \d+ is captured and transformed and the result of that transform block is what is passed to the step definition block.

Interesting. I wonder if people will use it?

2. The End of the World As We Know It

This post from the Armed and Dangerous blog tries to imagine a world without the web. The general idea is that if Congress had understood what DARPA was up to in the early 80’s, then funding would have been cut, and TCP/IP would not have been developed and popularized.

It’s an interesting argument, and as much as I’d like to believe it’s to dark, the examples of the cable and cell phone industries are eloquent. (I’ll grant that the author is probably trying to make a libertarian point I wouldn’t agree with in general…)

3. Books: Fuzzy Nation

Continuing playing catch-up with brief book reviews, Fuzzy Nation by John Scalzi. Fuzzy Nation is something odd — a genuine remake of a beloved SF classic (well, beloved by some, I’ve never read it), namely Little Fuzzy by H. Beam Piper. Scalzi has taken the basic elements — a guy who encounters small, sentient aliens who are, wait for it, Fuzzy — and wound his own story around them.

Fuzzy Nation is pretty much purely entertaining, fun, well structured, fast paced. It’s not as much interested in the existential questions around alien intelligence as the practical question of protecting them from a corporation that wants to strip-mine their planet. (Subtle, it’s not.) It’s one of those books that isn’t interested in re-defining the genre as much as telling a good story inside the existing boundaries.

4. Moving Beyond Thin Controllers To The Downright Emaciated

Gary Bernhardt over at the Destroy All Software blog posts some suggestions about using routing or routing-like structures to effectively remove controllers from the system. The theory is that if controllers just exist to dispatch to a specific method someplace else in the system, and Rails manages all the other connections, then why not route directly to that method with some declarative or rules-based logic to handle things like security logic, exceptional conditions, or other high-level logic.

It’s interesting, and probably could be built within Rails 3. I suspect most systems aren’t pure enough in the controllers to take advantage of it, which I guess is the point, and I wonder if the gain is worth breaking the default linkage between URL and controller/action pairs, but I’d be curious to try it.

5. In Brightest Day, In Blackest Night

Finally, I haven’t seen the Green Lantern movie yet, but I’ve been telling anybody who will listen that I’ve been waiting 30 years to be disappointed by it. Thanks to io9 for reminding me why be recapping an awesomely over-the-top Green Lantern comic from 1980 that I owned, loved, and could still quote alongside the recap. Watch GL stagger through the Arctic wilderness without his ring set upon by polar bears and wolves.

June 15, 2011: Six Sigma Tyrannis

Hey, twice in one week. I might be actually getting back on a pattern here…

1. Popular Crime

Catching up on books, I started off last month with Bill James’ Popular Crime. James, known mostly for his writing about baseball, has written a labor of love book about, well, popular crimes.

There’s a whole ‘nother essay to write about how the way James approached both writing about baseball and what you’d have to call the scientific method warped my brain way back when.

Anyway, what I was expecting here was something like James’ book on the Baseball Hall of Fame — a mix of history with a meta-level talking about why things are the way they are. That’s mostly what we’ve got here, it’s a book that careens back and forth from, say, arguing Lizzie Borden’s innocence, to trying to classify types of evidence, to the Lindberg baby, to a taxonomy of what makes a crime catch the public interest. You’ve probably never read anything like it.

I can’t quite say it has the level of insight of James’ baseball books, and judging from the Amazon reviews, it’s clearly not for everybody, but I thought it was mostly riveting. James is great when he gets opinionated and cranky, which is a large part of the book. The biggest failure is a lot of the individual stories kind of end abruptly.

2. Six Sigma, Tyrannis

Excuse me while I giggle over my own obscure headline joke.


Coming from the weird intersection of technogeekery and politics is this item about Republican candidates embracing Six Sigma as a way to cut government spending.

As a former employee of a company intimately associated with Six Sigma, I can have no other reaction but to shudder uncontrollably.

3. Teaching Rails or Off The Rails

I believe this is what they call in the biz a “grabber”, by Steve Coast

Ruby on rails used to be about elegant simplicity, now it feels like it’s about disappearing up its own asshole.

Okay, you have my attention.

Coast goes on to claim that Rails is leaving newbie developers behind:

But it just feels like we’re making this herculean effort to write elegant code and disappearing off on our own cloud of perfection, leaving behind anyone who wants to learn rails…. Rails is busy optimizing for the anal superior coder who wants to learn things for the sake of learning things, which is neat and cool but not worth it if you just want to make a website.

I am of two minds here.

On the one hand, it is objectively true that it is harder to teach Rails than it was in the 1.x time frame. The REST stuff adds a layer of indirection to everything that is not intuitive, there are a lot more library choices, you actually have to know a JavaScript library to get started now, and so on.

I can make that claim because I’ve taught Rails on both side of the divide. I can’t make a strong claim about Rails vs. other frameworks in this case, because I haven’t put in the effort to try to teach them to newbies.

I’d argue, though, that there has been a reason why Rails has gotten more complicated, and I don’t think it’s because the Rails core team likes complexity or because they have let things get away from them.

I think web applications turned out to be complicated.

I think that, although the path from novice to initial website is probably harder than it was four years ago, the path from initial website to good, actually practical website is much, much shorter. There are a lot of things in the Rails ecosystem that are much easier to do in 3.1 than in 1.x, and most of them have to do with the difference between the 15 minute blog app and a real web app that can handle complexity and traffic.

Later update: It wouldn’t be a RailsRx daily update without Yehuda Katz. He explains some of the technical issues behind Rails changes referenced in the earlier article.

4. Pipeline Those Assets

In a related story,
The Flowdock blog has a nice post about the new Rails 3.1 asset pipeline.

One thing to call out for updaters that wasn’t mentioned is this:

stylesheets and asset helpers are broken and should be replaced with call to relative helpers, e.g. image_path /images/subdir/rails.png should be asset_path “subdir/rails.png”.

5. SpiderMonster

And, just ’cause, here’s the Sesame Street parody of the Spiderman musical.

June 13, 2011: The Kathy Sierra Question

1. Annnd… We’re Back

Okay, I’m trying the semi-regular daily links post again. Two changes from the last time I did this: a wider range of links beyond just Ruby, and it probably won’t quite be daily, but more when I build up five things that I have a short opinion on.

Mostly, though, I need to get back in the habit of actually finishing posts, and realizing that I don’t need to write a 2000 word essay on something for it to be posted here.

2. Grantland

Speaking of not linking to Ruby topics, Bill Simmons launched Grantland this week, a new site which intends to put form long-form magazine-style articles on sports and pop culture, featuring Simmons, Chuck Klosterman, Dave Eggers, and then some. I’m excited for a few reasons: not least is that there’s a lot of talented staff involved, and the website doesn’t look like a bunch of ads with a tiny amount of content in the middle.

Whatever else you may think of Simmons, he’s always been respectful of great magazine writing of the past, and if this thing works it’s going to be a constant destination. Highlights of the first week include a very long review of L.A. Noire that turns into a discussion of games, fun, and storytelling, and Charlie Pierce’s’ history of his time at the National Sports daily (especially interesting because Pierce and Simmons have feuded a bit in public..)

3. Kathy Sierra is Back

It’s always a good thing when I’m reminded that my projects need a little more Kathy Sierra, and she dismantles unneeded social networking and gamification in a blog post this week. The takeaway is that you don’t want to be the kind of product that’s
dependent on gimmicks to work, and, as always, the question is “How do I help
my users be awesome.”

4. iOS 5 Thoughts

Just a couple of quick thoughts on iOS 5, iCloud, and upcoming Apple things.

  • I’m already enjoying having apps and things automatically download to
    my device after I purchase them. I can’t wait for the full wireless
    sync. In particular, I hope they fix iBooks, because for some reason, the
    iTunes mediated iBooks sync has a lot of trouble keeping the same books
    on two devices. Especially if they are being sideloaded, and especially if
    they get updated with a new version, like, say, a Pragmatic beta book.
  • I currently have at least four possible sources of truth for my calendars
    (three devices, plus a Google Calendar). I couldn’t tell you on a bet how
    they interoperate at the moment, so some clarity there would go a very
    long way.
  • I’ve seen some reports about the iTunes match service that state that the
    $25 a year effectively protects you against any accusation that your
    music is pirated. But as far as I can tell, they’ve all been second-hand.
    I don’t think we’ve seen an official Apple source confirm that — at the
    actual event, they were careful to say that iTunes Match worked on CD’s
    that you had ripped. (The exact statement on the website right now is
    “including music you’ve ripped from CDs or purchased somewhere other than
  • Seems like everybody is really quick to write off indy apps that overlap
    with new features announced last week (Instapaper, Due, Dropbox, Camera+,
    Sparrow just to name the first few off the top of my head). In, I guess,
    the same way that the weather app killed off all other weather apps, or
    the existing camera app killed off other camera apps or… I could do this
    for a while, the point is that some of these apps are in trouble, some
    are already providing a better experience than the official app, and some
    will appeal to a specific niche. Just like now.

5. Dream of the blue lobsters

Hey look, a blue lobster. Really.

Can I have your attention please?

So, apropos of nothing, and after RailsConf, some thoughts on public technical speaking. You’re not going to read about how to arrange your slides here, not least because I’m pretty bad at the fancy slide thing. Instead, I want to talk about working the room. This is what I try to do when I give a technical talk.

You should think of this kind of presentation as a performance. You have a story to tell and information to share, and you want the audience to pay attention to you. (One reason why I don’t push too hard on fancy slides is that I want the audience to pay attention to me, not the screen.)

The key to a successful performance is energy. Energy means that you come off as excited and happy to be there, and interested in your subject — interested people are (to a point) the most interesting. Energy means speaking with inflection and volume. Energy doesn’t just come from the speaker, it comes from the audience, and their attention to the speaker. Even in a quiet room, you can tell the difference between an audience that is paying attention and one that is not.

Any stand-up comedian will tell you that you get the best energy from a room when people are close together and when you are relatively close to them. Picture your classic comedy club. The tables are close together, the performer is only a few inches higher, at most. Also, everybody is drunk, but that’s generally not an issue at a tech conference. At least not in the morning…

Anyway, picture your typical conference setup. A hotel ballroom, badly lit. The speaker can easily be 10 feet from the audience, and the audience somewhat spread out, and often with computers as distractions. Sometimes the speaker is set up far away from the projector screen and it’s not easy to move around. Granted, you’re not trying to be Bill Cosby up there, but your job is getting and keeping everybody’s attention, and that means fighting the room.

You’ll never have more attention than you will right at the beginning of your talk. Take advantage of that moment. Do something up front to engage the audience. Surprise them a little. This doesn’t mean “open with a joke” — for God’s sake, don’t open with a joke unless you are about 120% sure the joke will land. It does mean starting off by asking a question, or calling out to the audience in some way. At RailsConf, I started with an unrelated slide that was a kind-of-funny session title of a Medical conference in the same building. At RedDirt, Jeff Casimir dared the audience to close their laptops or give him the finger for twenty minutes, which got my attention.

It’s a classic stand-up trick to start with a “Hello, Cleveland” or something to get a cheap applause line up front. (When I was in college, I would go on stage with a tape recorder, and ask the audience to laugh and applaud so I could play it for my Mom. Cheap. Effective.)

The key, though, to dealing with an audience is to both be and appear responsive. Don’t hide behind a podium, if you can help it. Pay attention to whether people look confused. I like allowing questions during a talk unless there’s a really good reason not to, because interactive tends to be more engaging, but you do need to be ready to cut somebody off if needed to get on with your material.

Preparation always helps. It’ll also help you be less nervous. There are three kinds of useful practice for public speaking.

First, of course, is practicing the content of your presentation. I’m not really giving tips here on how to structure a technical talk, but your goal here is to be comfortable enough with your material to remove that as a source of nervousness as you speak. Another way to look at that is the less effort you need to place in deciding or remembering what to say, the more effort and attention you can pay during the presentation to observing the audience and monitoring how things are going.

I will say that I’m not a big advocate of writing down your talk verbatim — my experience is that it’s hard to read something word for word in public and have it sound natural. Normally I write an outline (usually it becomes my slides), and occasionally use brief notes to remind me of specific points I don’t want to forget. The reason for knowing your content well, though is not so that you can deliver it perfectly from memory, but so that you can free yourself up to be flexible during the actual presentation.

I find it hard to do a full-energy version of a practice talk when it’s only me, and I recommend not even trying — fake enthusiasm isn’t helpful. When you practice by yourself, it’s about the content first, and secondarily about the physicality of the performance itself. The actual physical act of delivering a talk is the thing that I suspect people don’t practice enough. Just standing in more-or-less one place is a challenge. Even at home, try to practice in as close to the real setup as possible. Stand up. Understand how far from your computer you can be and still have the remote work. Try not to pace unrealistically (I fail at that, I tend to walk all over when I practice). Try not to stop, so you get used to talking for 45 minutes.

On a related topic, if you get a chance to scope out the actual room before you talk, do that. Being early and making sure that technical stuff is in place will make you less nervous, and give you some time to scope out the audience before you start.

Finally, you want to practice in front of an audience in general. Every chance you get to realize that the audience is unlikely to eat you if things go badly is helpful. There are things you will only learn by getting used to seeing an audience in front of you. Talk to specific people. Try and get feedback. If possible, watch video of yourself, you’ll definitely see something you can get better at. When I was a high-school performer, a director had me watch a fast-forwarded version of a performance, which really exaggerated a habit I had of swaying back and forth. Being aware of these habits will help you get rid of them.

Oh, and that thing about picturing the audience in their underwear… Don’t do that. It doesn’t work.