(void* dan)

In development of a new, greenfield application I had flash messages popping up twice: once for the current page, and then again on the next page.  It turns out I was using flash[]= and then rendering within the same action.  As flash[]= is designed to carry over to the next action (i.e. after you redirect, a new action is performed) it was showing up again.  The solution: flash.now[]=.  This hash is cleared after the current action.  The following code illustrates when to use each:

def create_application
  #do work
  if it_worked?
    flash[:notice] = "Great success!"
    redirect_to @cash
  else
    flash.now[:error] = "Let's try that again"
    render :action => "new"
  end
end

The flash[:notice] must be carried over to the action that handles the @cash path (following to the redirect), whereas the flash.now[:error] will be shown for the current action (even though it renders a different view) and should not be carried over to the next action.

It seems somewhat strange to me that I’m just discovering this now.  I suppose that as I learn more about Rails and web applications in general, I adjust my techniques and start experimenting with new ones (that aren’t always better).  The fact that flash[]= carries over to the next action and flash.now[]= doesn’t has only come into play now that I’m using flash as more of a central messaging system than just the standard notices from scaffolds.

I suppose the idea behind Rails’ migration is that once you create them, you don’t change them.  This is usually the right concept, and from this decision grows many of the rake db:* tasks.  Such tasks — migrate, reset, schema:load, schema:dump, and setup — do not re-run migrations as they assume schema.rb is up to date (rightfully so).  But oftentimes (especially on greenfield development) I will tweak my migrations and want to start from scratch.  So here’s a quick hitter I now have my application templates add to every project I start:

module DBTasks
  namespace :db do
    
    desc "drops, creates, migrates and seeds the DB"
    task :fresh => :environment do
      puts "Dropping DB..."
      Rake::Task["db:drop"].invoke; puts "done."
      puts "Creating DB..."
      Rake::Task["db:create"].invoke; puts "done."
      puts "Migrating DB..."
      Rake::Task["db:migrate"].invoke; puts "done."
      puts "Seeding DB..."
      Rake::Task["db:seed"].invoke; puts "done."
      puts "Your DB is so fresh and so clean clean!"
    end
    
  end
end

If I wanted to tweet about a silly magnifier glass iPhone application, today I could tweet

What a pointless iPhone app http://bit.ly/172F9b !

But that uses too many characters just on the shortened URL without expressing anything!  We should be succinct and stop wasting random letters on bit.ly’s unique id:

What a http://bit.ly/pointless_iPhone_app!

Now that’s a nice (and short!) URL.  bit.ly is 6 characters.  The unique id they use (in this example 172F9b) is also 6 characters.  By dumping the unique id entirely and allowing custom text in the URL, bit.ly would waste only half as many characters and become an integral part of the message.

Ruby ignores the underscore character within integer literals.  Instead of writing

bank_account.deposit(:cash => 1000000)

you can write

bank_account.deposit(:cash => 1_000_000)

which is much easier to read.

When I’m depositing a million at my ATM however, I will a) refactor that constant out of my code and b) probably be blogging from somewhere other than my bedroom/home office =)

I don’t like magic because I don’t understand how it works.  After I understand it, it’s no longer magic, but I usually have a much greater appreciation for the execution.

I’ve been using Ruby without understanding the language’s nuts and bolts for a while.  So I picked up O’Reilly’s The Ruby Programming Language and am making my way through it.  Along the way I will document some of the useful and interesting pieces that I enjoy…

A ‘fluent API’ allows coders to conveniently chain many statements together which act on an object (or a series of objects there derived) in a logically progressive manner.

indy500_winner = Race.new('Indianapolis').start.run_laps(500).winner

While elegant, these chains can get very long.  Ruby 1.9 has altered its statement terminator rules to allow continuations on successive lines.  When the first non-whitespace character on a line is a period, it is considered a continuation.

indy500_winner = Race.new('Indianapolis')
  .start
  .run_laps(250)
  .yellow_flag(10)
  .run_laps(240)
  .winner

Nice, eh?

After learning cron syntax, figuring out what the PATH is during cron execution and how to set it in my crontab, and documenting my crontab within my application, I discovered Whenever.  Javan Makhmali’s Whenever gem allows you to write self-documenting ruby in your application to define your cron jobs, then integrates beautifully with Capistrano to update  your crontab on deploy.  It also saves me from having to lookup cron syntax every few months when I need to edit something (and have, of course, forgotten the syntax).

The documentation for Whenever is very good, and there’s even a Railscast that provides a step by step.  But there is one setting not mentioned anywhere, which I only found digging through the code:

set :set_path_automatically, false

Nominally, Whenever writes a PATH=... line before it lists your cron jobs.  This is fine most of the time, but on some systems (like Joyent’s SunOS 5.11) the extended Vixie Cron syntax (the standard used on most *nix systems) is not supported.  As such, you may see an error like

crontab: error on previous line; unexpected character found in line.

if PATH is set in your crontab.  So, disable it in your schedule.rb and get back to real work.

p.s. Will Tumblr ever create a post type for code?