I‘ve decided the only way to go viral is to get a cat to use state_machine. I’m just having a hard time getting past that whole “cats can’t program” thing… so blogging it is! Last week, state_machine 0.9.0 was tagged after a month’s worth of active development. This is a major milestone that I’m really excited to share with all of you.

If you can dodge a bullet, you can dodge a ball. Wait, what?

If you’ve been following the project for a while, you’ll know that I only bump major versions when there are significant changes in either the public API or the feature set. Fortunately, this release comes loaded with a bunch of new features (and some fixes) that I hope you’ll all enjoy:

• MongoMapper 0.5.5+ integration support
• ActiveModel 3.0.0+ integration support (extracted from ActiveRecord)
• DataMapper 0.10.3+ support
• around_transition callbacks (supplements before/after callbacks)
• Rails 3 railtie integration
• Consolidated rake tasks
• Unified API for event / attribute transitions
• …and 7 bug fixes

To me, the most interesting part of this release has been building support for around_transition callbacks. Here’s a basic example of its usage:

class Vehicle < ActiveRecord::Base
  state_machine :initial => :parked do
    around_transition :on => :ignite, :do => :benchmark
    event :ignite do
      transition :parked => :first_gear
    end
  end
 
  def benchmark
    puts "...starting benchmark"
    time = Benchmark.measure { yield }
    puts "...completed in: #{time.real}"
  end
end
 
v = Vehicle.new
v.ignite
# ...starting benchmark
# ...completed in: 0.0642118453979492
v.state # => "idling"
 
v = Vehicle.new(:state_event => 'ignite')
v.valid?
# ...starting benchmark
v.state # => "idling"
sleep 1
v.save
# ...completed in: 1.00799298286438

See the full list of changes here.

I can only show you the door… unfortunately, it’s locked.

Besides addition of the above features, 0.9.0 is also a significant milestone as it marks the beginning of feature lockdown on state_machine. All future changes will be primarily for maintenance means (fixing bugs, compatibility with releases of integrated ORMs, etc.). This is the final push to get to an official 1.0.0 release.

However, I need your help to get to 1.0.0. If you encounter bugs in any part of the code or see any issues with the documentation, now is the time to report them.

Otherwise, enjoy this release

If you had asked me 6 months ago when the next release of state_machine was going to be, Pi Day 2010 would probably not have been my first guess. If it had been, I probably would have asked you to admit me into a hospital so I could be treated for delirium. Then again, what better way to celebrate such an important holiday?

Be a thinker, not a stinker. Or at least take a shower. Seriously.

Without further ado, I am excited to announce the release of state_machine 0.8.1. This is the most stable, feature-rich release yet. Given that I never officially announced the 0.8.0 release 6 months ago, below is a brief overview of everything that comes with the Ocho package:

• ActiveRecord 2.0 and 3.0 support (Rails 3 users, rejoice!)
• DataMapper 0.10 support
• ruby-graphviz 0.9 support
• Full compatibility with ORM dirty attribute tracking
• Default state-driven behaviors
• More control over whether after_transition callbacks get run after failed actions
• Define multiple callbacks in a single before/after_transition call
• ActiveRecord i18n support for state / event names
• Query available state transitions with :from / :to / :on requirements
• Earlier access to initial states during the initialization of an object
• …and 20 bug fixes!

Here’s a very small bit of code demonstrating some of the visibily new features:

class Vehicle
  include DataMapper::Resource
 
  property :id, Serial
  property :state, :String
 
  state_machine do
    before_transition all => :parked, :do => [:set_alarm, :lock_doors]
    after_transition :do => :log_transition, :include_failures => true
 
    event :ignite { transition :parked => :first_gear }
    event :park { transition :first_gear => :parked }
 
    state :first_gear do
      def speed
        10
      end
    end
  end
 
  def speed
    0
  end
end
 
vehicle = Vehicle.new
vehicle.state_transitions
vehicle.state_transitions(:to => :parked)

See the full list of changes (and follow the project!) here. If you are on any other version, I strongly suggest (using <strong> tags, too) that you upgrade to 0.8.1. You’ll thank me later. Or you’ll yell at me for not releasing this earlier

I’d like to thank everyone at the academy who I paid off to vote for me.

As with every release, none of this would have been possible without the help of every person who filed a bug, sent me an e-mail, made a pull request, or tried to stalk me. The following Rubyists were particularly instrumental in putting this release together:

• Jeremy Wells
• Joe Lind
• Jon Evans
• Sandro Turriate
• Tim Pope

I didn’t hear no bell. My hearing aid must be broken.

So where do we go from here? The road to 1.0 has been simple for me from the get-go. Over the past year or so, we’ve seen many Rubyists work together to standardize commonly-needed features through libraries like rack, i18n, activemodel, etc. That was exactly the goal for state_machine 1.0… to build a standardized implementation for state machines and become the recommended implementation for at least 1 of the 3 major Ruby ORMs. And that’s not something I can do without your help.

Either way, I’d love to hear feedback from the community. What do you think the 1.0 release should be (or should include)?

Hope you enjoyed some Pi. Delicious, delicious 3.14159……..

Last month, Thoughtbot decided to enable my gambling addiction by opening up an open-source prediction market to answer all the questions that keep you up at night like:

• Who will win a Ruby Heroes Award at RailsConf 2009?
• Which RESTful controller project should I use?
• Which state machine project should I use?
• What am I going to wear tomorrow?

What gambling addiction? You play poker by betting “pretty” colors.

To help visualize how these markets are playing out and for the obsessive compulsive, I wrote a little jQuery plugin which pulls the real-time follower data down from GitHub and generates a Google Chart with it (it’s a hack, I’ll admit it). Now you can see who’s the market leader faster than it takes for a flame war to start involving the words Twitter and Ruby.

Check it out (may take a second to load):

And all of that can be accomplished through just a little snippet of javascript:

<script type='text/javascript' src="http://www.pluginaweek.org/wp-content/themes/pluginaweek/jquery.rubymarkets.js"></script>
jQuery(function() {
  jQuery.rubyMarkets('#market-examples', [
    'RESTful controller',
    'state machine',
    'gem creation'
  ]);
});

I’m most intimidating if I leave my cards face up in poker. No one else thinks so.

Unfortunately, it would appear as of today that Thoughtbot’s Inkling markets account expired and you can no longer participate. Fear not, I’m sure they’re aware of it. Update: The markets are back. Don’t forget, there’s a $1,295 value prize on the line for those of you making good bets. In the meantime, you can see a full visualization of the markets (using the above plugin) and their respective leaders here:

Open-source Ruby Prediction Markets

Feel free to embed these graphs on your own website using the plugin. Wear your market badge proud. Show those wall street brokers who’s boss.

Fast and furious. That’s how development’s been on state_machine over the last month (and is also what happens to sequels when you run out of bad ideas). Yesterday, 0.7 was officially added to the state_machine family of releases. With this release comes better integrations, easier access to more state information, and the all new and improved Done Right™. Check out the changelog for a detailed list of changes.

REST and events – Events are auto-fired when a machine’s action is called (or when validations run) based on the value of #{attribute}_event:

purchase = Purchase.create  # => #<Purchase id: 1, state: "pending">
purchase.state_event        # => nil
 
purchase.update_attributes(:state_event => 'authorize')
purchase.state              # => "authorized"
purchase.state_event        # => nil
 
purchase.state_event = 'capture'
purchase.valid?             # => true
purchase.state              # => "captured"
purchase.save               # => true

This means that your create/update controller actions don’t change at all. For an example of the full Rails/Merb vertical slice, see the RESTful examples.

State rollbacks – If an action fails when firing an event, the transition is rolled back:

purchase = Purchase.find(1)
purchase.state              # => "pending"
purchase.amount = nil
purchase.valid?             # => false # validates_presence_of :amount
purchase.authorize          # => false
purchase.state              # => "pending" # Returned "authorized" pre-0.7

ActiveRecord Observers – The ActiveRecord integration kicked it up a notch (bam!) with new Observer hooks:

class PurchaseObserver < ActiveRecord::Observer
  def before_capture_from_pending_to_captured(p, transition); end
  def before_capture_from_pending(p, transition); end
  def before_capture_to_captured(p, transition); end
  def before_capture(p, transition); end
  def before_transition_state_from_pending_to_captured(p, transition); end
  def before_transition_state_to_captured(p, transition); end
  def before_transition_state_from_pending(p, transition); end
  def before_transition_state(p, transition); end
  def before_transition(p, transition); end
end

You can define the same types of hooks for after_* as well.

DataMapper Defaults – The DataMapper integration no longer uses transactions by default and properties are now auto-defined if they don’t already exist:

class Purchase
  include DataMapper::Resource
  property :id, Integer, :serial => true
  # property :state, String # Automatically done by state_machine
 
  state_machine :use_transactions => true do
    ...
  end
end

Available events / transitions – The full list of available events / transitions for a state machine can be accessed via two new helpers:

purchase = Purchase.find(1) # => #<Purchase id: 1, state: "pending">
purchase.state_events       # => [:authorize, :capture]
purchase.state_transitions  # => [#<StateMachine::Transition ...>, ...]
 
purchase.authorize
purchase.state_events       # => [:capture]
purchase.state_transitions  # => [#<StateMachine::Transition ...>]

This becomes particularly useful when presenting these in a view as a dropdown for users to select from.

Backwards Incompatible! Accessing a specific event’s transition has been renamed from next_#{event}_transition to #{event}_transition:

purchase.authorize_transition       # => #<StateMachine::Transition ...>
purchase.next_authorize_transition  # => NoMethodError: undefined method...

Event arguments – Arguments to event methods can be accessed from transition callbacks:

before_transition :on => :authorize do |purchase, transition|
  amount = transition.args.first
  ...
end

after_transition callbacks – Backwards incompatible! The result of the action is no longer passed to after_transition callbacks. It can be accessed from the transition instead:

after_transition :on => :authorize do |purchase, transition|
  saved = transition.result
  ...
end

This affects all integrations as well.

Parallel events – For classes that use multiple state machines, you can fire events off in parallel on an object. This means their before/after callbacks get run at the same time and actions only get called once if they’re the same:

purchase = Purchase.find(1)
purchase.state                                    # => "pending"
purchase.shipped_at                               # => nil
purchase.fire_events(:capture, :deliver_shipment) # => true
purchase.state                                    # => "captured"
purchase.shipped_at                               # => Sun Apr 05 ...
 
# Bang method is similar to events
purchase.fire_events!(:capture) # => StateMachine::InvalidTransition: ...

And the rest of the gang…

In addition to the above major changes / additions, there were 6 new minor features and 4 bug fixes in this release.

A special Billy Mays shout-out goes to the folks who helped make this release happen, including:

• Aaron Gibralter
• Paweł Kondzior
• Mikhail Shirkov

Stalk me, but not in a creepy way

As always, be sure to follow the project on GitHub! Happy coding!

After 2 1/2 years of blood, sweat, tears, and the occasional Jägermeister, I’m finally officially announcing a project I’ve been quietly working on: state_machine. Well, quietly until some people started mentioning it This is a project which has undergone many rounds of rewrites, but which has finally met its goal, in my opinion, to become the easiest, sexiest, yet most powerful state machine library for the Ruby language.

LOTR reference? Really? What’s next, The Matrix?

Rather than sit here and beat about the bush, here’s a rundown of state_machine’s features (in no particular order):

• Define multiple state machines on any Ruby class
• Namespaced state machines
• before/after transition hooks with explicit transition requirements
• Integration with ActiveRecord / DataMapper / Sequel
• State-driven instance / class behavior
• State values of any data type
• Dynamically-generated state values
• Inheritance support
• Simple instance/class method overrides
• Internationalization
• GraphViz visualization creator

Now if that list doesn’t get you up on the dance floor, we need to have a talk.

Never send a human to do a state machine’s job.

What’s a blog post about code without… well, code? Rather than bore you with words, here’s an example using state_machine with a Purchase DataMapper resource, written just for this blog

class Purchase
  include DataMapper::Resource
 
  property :id, Serial
  property :amount, Float
  property :state, String
  property :shipped_at, DateTime
  property :receipt, String
 
  state_machine :initial => :pending do
    before_transition :log_state_change
    after_transition  :pending => :authorized, :authorized => :captured do
      # Update RSS feed...
    end
 
    event :authorize do
      transition :pending => :authorized
    end
 
    event :reauthorize do
      transition :authorized => same, :if => lambda {|p| p.amount_diff < 15}
    end
 
    event :capture do
      transition [:pending, :authorized] => :captured
    end
 
    event :void do
      transition all - [:captured, :voided] => :voided
    end
 
    state :pending do
      def transaction_id
        nil
      end
    end
 
    state :authorized, :captured, :voided do
      validates_present :receipt
 
      def transaction_id
        id.to_s
      end
    end
  end
 
  state_machine :shipped_at, :initial => :pending, :namespace => 'shipment' do
    event :deliver do
      transition :pending => :delivered
    end
 
    state :pending, :value => nil
    state :delivered, :if => lambda {|value| value}, :value => lambda {Time.now}
  end
 
  def amount_diff
    amount - original_values[:amount]
  end
 
  def log_state_change(transition)
    event, from, to = transition.event, transition.from_name, transition.to_name
    DataMapper.logger.info("#{id}: #{from} => #{to} on #{event}")
  end
end

And now some fun actually interacting with the state machine:

purchase = Purchase.new         # => #<Purchase id=nil amount=nil state="pending"
                                #               shipping_status=nil receipt=nil>
purchase.amount = 5.0
purchase.state                  # => "pending"
purchase.state_name             # => :pending
purchase.pending?               # => true
purchase.can_authorize?         # => true
purchase.transaction_id         # => nil
purchase.save                   # => true
 
purchase.authorize              # => false
purchase.errors.full_messages   # => ["Receipt must not be blank"]
purchase.reload                 # => #<Purchase id=1 amount=5.0 state="pending"
                                #               shipped_at=nil receipt=nil>
purchase.receipt = 'abc123'
purchase.authorize              # => true
purchase.authorized?            # => true
purchase.captured?              # => false
purchase.transaction_id         # => "1"
 
purchase.authorize!             # => StateMachine::InvalidTransition: ...
 
purchase.shipped_at             # => nil
purchase.shipped_at_name        # => :pending
 
purchase.can_deliver_shipment?  # => true
purchase.deliver_shipment       # => true
purchase.shipped_at             # => #<DateTime: 106051652881/43200,-1/6,2299161>
purchase.shipped_at_name        # => :delivered
 
purchase.shipment_pending?      # => false
purchase.shipment_delivered?    # => true
 
Purchase.with_state(:authorized).count        # => 1
Purchase.without_shipped_at(:pending).count   # => 1
 
Purchase.state_machines.each {|name, machine| machine.draw}

Boom shakalak! That covers the basics, but notice that little nugget at the end? That draws a visual representation of the graph for those PowerPoint presentations you’ll be giving. Here they are (click for the full image):

What are we going to do tonight, Brain?

So that’s a taste of state_machine. Take a gander over to GitHub and read the docs. There’s lots more there.

Before I close out this post, I want to recognize a few people who asked the hard questions, contributed back, or provided inspiration for this library:

• Scott Barron
• S. Brent Faulkner
• Pete Forde
• Aaron Gibralter
• Avdi Grimm
• Michael Grosser
• Tse-Ching Ho
• Nate Murray
• Sean O’Brien
• Mike Perham
• Brian Terlson
• Dennis Theisen
• Richard Titze
• …and anyone else I missed!

While you’re here, don’t forget to follow the project on GitHub and help make state_machine a market leader!

Not happy with your current job? Stuck in a code formatting war with your coworker? Can’t seem to convince your boss that Chuck Norris was written in Ruby? We can help with that.

You take the blue pill – the story ends, you wake up at your company and believe whatever you want to believe

Welcome to Viximo. Viximo is a venture-funded startup, based in Boston, building a digital goods platform that will help creators, developers, and online communities monetize social interactions. At least, that’s what the biz folks say We’re currently working on a pilot program on Facebook with the folks over at Birthday Calendar using a gifting platform that’s been under development over the past 9 months. Want to send your friend a cupcake for his birthday? A beer? Maybe a pair of handcuffs? This is where the magic happens

You take the red pill – you come to Viximo and I show you how deep the rabbit-hole goes

I joined the company when we were a small group of 5. Nine months later we’re up to a whopping 15, but we’re still a small company with an amazing group of individuals who know their stuff and know how to have fun. We use Ruby on Rails. We’re built on EC2. We test using RSpec. And we occasionally play Hannah Montana over the office sound system.

Viximo wants you. Viximo needs you. So if you’re interested in meeting us in person, check out our Jobs page.

Is that pill chewable? Like Flintstones vitamins? I really like those.

If you’re not quite ready for a new job or are unsure, e-mail me anyway. If or when you’re in the Boston area, drop me a note and we’ll chat.

This guy’s expression pretty much sums up my reaction whenever a new acts_as_* shows up in my RSS feed for AgileWebDevelopment plugins. As of today, there are 1,115 plugins listed there, 129 of which start with acts_as. That’s about 11.5% and I’m not even including ones like acts_as_hasselholf or acts_as_rickroll

acts_as_chuck_norris is impossible – the only thing that can act like Chuck Norris is Chuck Norris

acts_as_* has sort of become the joke of the Rails community. Everything is acts_as whether it makes sense or not. Something simple like auto_validations becomes acts_as_auto_validated. And, in all honesty, I was sucked right into it like everyone else until I realized how ridiculous it had become. The majority of these plugins have names that are just terrible at describing what it is they do.

chuck_norris_fu consists of one move: the roundhouse kick

*_fu isn’t exactly much better. It seemed like once people started realizing that acts_as_* was becoming old, worn, and so last year, they resorted to suffixing every plugin with _fu. So instead of calling it auto_validations, it would be called validation_fu. The names changed, but the problems remained the same.

Where’s my acts_as_soviet_russia plugin?

Coming up with a name isn’t easy and isn’t always going to be witty and unique. Try to create something that’s, first and foremost, descriptive of what it is that your plugin provides… or you can just get lost in the acts_as_shuffle Either way, I can at least say I warned you!

Disclaimer: I know I have a plugin that starts with acts_as… but I swear it actually makes sense in its context!

Well what do ya know… Pandora, Twitter, Lost, and GitHub have something in common after all! Yeah, so I sort of avoided jumping on the bandwagon for a while, but each time I keep caving under pressure … although I’m still reluctant to admit that I’ve ever watched an episode of Lost.

So that’s big news for this project. I’ve spent the last few weeks tidying up some of the plugins and making the transition from Subversion to GitHub and Trac to Lighthouse. I’m really hoping that this change will help encourage more contributions to this project and give it a better spotlight to shine in.

Check out the goodies

Github: http://github.com/pluginaweek
Lighthouse: http://pluginaweek.lighthouseapp.com

If you need to access the old Subversion repository, I still have it up at svn.pluginaweek.org and it’ll remain there for a while, albeit deprecated, until most people have moved over to GitHub.

I really hope you’re as excited about these changes as I am And I look forward to a more social interaction with other developers such as yourself!

Toot toot! Rails 2.1 is almost out and the gravy train has set sail, full speed ahead! Are you excited? I know the girl to the left here is. She’s totally psyched about the upcoming release. Screw barbie dolls, you’ve got some upgrading to do!

You’ll be happy to know that all the plugins here are Rails 2.1 ready. That’s been my testbed for a while now.

I’m sorry, son. You must be 2.1 or over to enter.

The downside of being Rails 2.1 ready is, well… Rails 2.1 certified means NOT < Rails 2.1 certified. I don’t like code strictly meant for backwards compatibility. This project is maintained against the latest version of Rails and is meant to be implemented with the latest and greatest in mind.

Hopefully, for most people, that decision won’t have much of an effect on your project. If you’re lagging a bit behind and want to update a plugin, you should feel free to just make the appropriate patches needed. Sure, it’s a little extra work, but I think you’ll be happier with code that’s not just a bowl of spaghetti.

You wanted a bowl of ice cream anyway. Screw spaghetti.

Let me know if you run into any issues with the 2.1 release. I’ll be happy to take a look!

I decided to go “green” last weekend and spend a little time reducing the energy consumption of my computer. See, I’ve always left my desktop computer on at home while I’ve been at work or asleep. I’m sort of lazy and suspend never really worked that well in Ubuntu.

After upgrading to 8.04 and finding suspend working, I decided to overcome the “lazy” excuse and write a script that automagically suspends my computer after I’ve left and turns it back on before I come back. Now I never have to think about it (if I’m in a rush) and I can still significantly reduce energy consumption.

Here’s the meat:

#!/usr/bin/ruby
require 'time'
wake_time = Time.parse(ARGV[0])
wake_time += 24 * 60 * 60 if wake_time < Time.now
File.open('/proc/acpi/alarm', 'w') {|f| f << wake_time.utc.strftime('%Y-%m-%d %H:%M:%S')}
system('/etc/acpi/sleep.sh force')

This just takes a single argument representing the next time the computer should start up, sets up the ACPI to wake up at that time, and then suspends the computer.

I have 2 cron jobs set up to use this script:

45 09 * * 1,2,3,4,5 /home/aaron/Projects/Personal/green/sleep.rb 19:00:00
00 02 * * * /home/aaron/Projects/Personal/green/sleep.rb 07:45:00

This means the computer will always be off between 9:45am and 7:00pm on weekdays and between 2:00am and 7:45am every day. Now, sometimes I work late, so if you’re on Ubuntu and use Gnome, here’s a little extension of the script that will display a dialog and give you a chance to cancel the automatic shutdown:

#!/usr/bin/ruby
require 'time'
require 'timeout'
require 'gtk2'
 
begin
  # Wait a few minutes before going on in case we're working late
  Timeout::timeout(5 * 60) do
    dialog = Gtk::Dialog.new('Still awake?', nil, nil, [Gtk::Stock::OK, Gtk::Dialog::RESPONSE_NONE])
    dialog.signal_connect('response') do
      # User is still around
      dialog.destroy
      Gtk.main_quit
    end
    dialog.resize(200, 51)
    dialog.show_all
    Gtk.main
  end
rescue Timeout::Error
  # Time to go to sleep
 
  # Write the time that we're going to wake up next
  wake_time = Time.parse(ARGV[0])
  wake_time += 24 * 60 * 60 if wake_time < Time.now
  File.open('/proc/acpi/alarm', 'w') {|f| f << wake_time.utc.strftime('%Y-%m-%d %H:%M:%S')}
 
  # Suspend the computer
  system('/etc/acpi/sleep.sh force')
end

Every little bit counts

P.S. The dialog extension needs a windowing environment, so I set up KAlarm to replace the cron jobs.

P.P.S. Disclaimer, be careful, blah blah .. you know the story.