Piston 2.0.8 is here. This is a minor bugfix release:

  • piston status with no path would not check any status. Thanks to Michael Grosser for the heads up;
  • The ActiveSupport gem deprecated require “activesupport” in favor of “active_support”. Thanks for Michael for reporting this as well;
  • Scott Johnson reported and fixed a problem where a git mv would fail because a parent directory was missing.

Thanks to all contributors!


1 $ gem install piston

At yesterday’s Montreal.rb I presented Nestor, an autotest-like framework. This is it’s official release announcement.

Nestor is different in that it uses an explicit state machine, namely Aaron Pfeifer‘s StateMachine. Nestor also uses Martin Aumont’s Watchr to listen to filesystem events. But the biggest difference is that the default Rails + Test::Unit is a forking test server. Nestor will load the framework classes—ActiveRecord, ActionController, ActionView, plugins and gems—only once. This saves a lot of time on the aggregate versus running rake everytime.

Nestor's state diagram with events denoting success or failure of a run, and states such as green, running_all or run_focused_pending.
Click for larger version

This release of Nestor is 0.2 quality: it’s not ready for large projects. It only supports Rails + Test::Unit, probably doesn’t run on 1.9 or JRuby, but it’s a solid foundation for going further. In the coming days, I will blog on the internals of Nestor and how StateMachine allowed me to add plugins with very little effort.


1 $ gem install nestor
2 $ cd railsapp
3 $ # edit config/environments/test.rb to set cache_classes to false
4 $ nestor

I already have a plugin that enables Growl notifications. Install and use:

1 $ gem install nestor_growl
2 $ cd railsapp
3 $ nestor start —require nestor/growl

The —require option is where plugins are loaded. This is an Array of files Nestor will require on startup.


You must set cache_classes to false in test mode for now. This is a limitation of how Rails boots. With cache_classes set to true, Rails will load the controllers and models when it boots. Since this happens before forking, the code under test would never get reloaded. Did I say it was 0.2 quality?

While discussing in Campfire with James Golick today, James said he would prefer to have his output directly in Vim, our editor of choice. I initially said that since Vim isn’t Emacs and can’t support a live console, it wouldn’t work. James told me to think outside the box.

1 $ autotest &>tmp/autotest.out &
2 $ vim
3 # :e tmp/autotest.out

Yes, thinking outside the box, and knowing your tools makes it much easier. So far, I’m liking autotest output in Vim very much. It’s easy to navigate the output using Vim movement commands: /Person finds the errors in person, gf opens the named file, etc. All in all, this is a pretty good experience.

Since yesterday, I read a bit more about autotest. I stumbled on Getting Started with Autotest which you should read immediately. The article talks about setting up your plugins and doing all kinds of interesting things.

Getting more proficient with my tools now!


Your Host

A picture of me

I am François Beausoleil, a Ruby on Rails and Scala developer. During the day, I work on Seevibes, a platform to measure social interactions related to TV shows. At night, I am interested many things. Read my biography.

Top Tags

Books I read and recommend


Projects I work on

Projects I worked on