stephencelis

Miniskirt: factory_girl, relaxed

2010-01-11T00:00:00-05:00

Living on the edge isn’t easy. You continuously risk that everything you rely on stops working.

NoMethodError: undefined method `configuration' for #<Rails::Application>
  from rails/railties/lib/rails.rb:53:in `configuration'
  from factory_girl-1.2.3/lib/factory_girl.rb:25:in `<top (required)>'
  from rails/activesupport/lib/active_support/dependencies.rb:167:in `require'
  from rails/activesupport/lib/active_support/dependencies.rb:167:in `block in require'
  from rails/activesupport/lib/active_support/dependencies.rb:537:in `new_constants_in'
  from rails/activesupport/lib/active_support/dependencies.rb:167:in `require'
  from test/test_helper.rb:16

Et tu, factory_girl?

The fix was easy enough¹, but I started realized that I only really used a small fraction of what was under the hood. I took a page out of Ryan Davis’ book, reordered the words, and wrote Miniskirt to complement minitest.

Miniskirt is factory_girl, relaxed. It’s the essential, with some flare:

Blocks are avoidable with Ruby 1.9 string interpolation. Avoid blocks if you can. Your models should handle their own logic.

f.email '%{first_name}.%{last_name}@example.com' # ...not...
f.email { |u| "#{u.first_name}.#{u.last_name}@example.com" }

Sequences are simpler (why bother with blocks?):

f.email 'person%d@example.com' # ...instead of...
f.sequence(:email) { |n| "person#{n}@example.com" }

What’s missing?

Factory.attributes_for :model.: Call Factory.build(:model).attributes, instead.
Factory.stub.: Stub your models like you stub everything else.
Factory#association.: Almost as short, and explicit: f.user { Factory :user }.
Factory#callback.: I can’t think of a callback that should be on a factory but not the model.

Here she is. All of her.

# Factory girl, relaxed.
#
#   Factory.define :user do |f|
#     f.login 'johndoe%d'                          # Sequence.
#     f.email '%{login}@example.com'               # Interpolate.
#     f.password f.password_confirmation('foobar') # Chain.
#   end
#
#   Factory.define :post do |f|
#     f.user { Factory :user }                     # Blocks, if you must.
#   end
class Miniskirt < Struct.new(:__klass__)
  undef_method *instance_methods.grep(/^(?!__|object_id)/) # BlankerSlate.
  @@factories = {} and private_class_method :new

  class << self
    def define(name)
      @@factories[name = name.to_s] = {} and yield new(name)
    end

    def build(name, attrs = {})
      (name, n = name.to_s) and (m = name.classify.constantize).new do |rec|
        attrs.stringify_keys!.reverse_update(@@factories[name]).each do |k, v|
          rec.send "#{k}=", case v when String # Sequence and interpolate.
            v.sub(/%\d*d/) {|d| d % n ||= m.maximum(:id).to_i + 1} % attrs % n
          when Proc then v.call(rec) else v
          end
        end
      end
    end

    def create(name, attrs = {})
      build(name, attrs).tap { |record| record.save }
    end
  end

  def method_missing(name, value = nil, &block)
    @@factories[__klass__][name] = block || value
  end
end

def Miniskirt(name, attrs = {})
  Miniskirt.create(name, attrs)
end

Factory = Miniskirt
alias Factory Miniskirt

Not bad for under 30 LOC.

Miniskirt isn't for everyone. The slightly more conservative, more backwards-compatible Minidress may suit you better. Or maybe factory_girl, with all her bells and whistles, fits you just fine.²

Whatever you choose, though, remember: write less, and write better.

¹ Up and running:

# test/test_helper.rb
Rails::Application.configuration.class_eval { alias configuration config }
require "factory_girl" # Now she loads just fine...
require "factories"    # ...and the rest needs to load explicitly.

² I like factory_girl, and may find myself returning to her when my platform is a bit more stable, especially if she picks up some of these interpolative tricks.

YAAC—yes, yet another…

2009-04-18T00:00:00-04:00

I’ve been rolling my own app configs for awhile now. It’s been just another step in the rails newapp ritual. A chore, really. Rails templates make things a bit easier, but the logic shouldn’t untidy my lib and initializers, should it?

I know it’s been done before, and others will do it again, but I just had to TODO its release when, last month, I heard Jacques Crocker blithely gloat that his take on AppConfig is better than everyone else’s.

Au contraire, mon amie! Let me introduce my way: the way I rather like it.

Hello, App

App is yet another YAML-based, app config for Rails. App should look familiar enough. It looks for and loads from config/app.yml, and provides namespaced access:

App.config # => {"apis"=>{"flickr"=>{ ... }}

# Sugar is always sweeter:
App.config("apis", "flickr") # => App.config["apis"]["flickr"]

# Who doesn't like sugar?
App["apis", "flickr"]

# Sugar, sugar, sugar!
App.apis("flickr")

# Namespace again, if necessary, e.g., with "config/app/apis.yml":
App::Apis.flickr

So, how does App stand up against the self-proclaimed champ? Well, it’s

⅓ the size of AppConfig, so save yourself those last six keystrokes. It also starts you out with just one file: app.yml (no environmental waste!). (The code base? Yes, it’s slimmer, too.)
Less magical [pej.] on the surface. Method chaining should really only go so far, so we prefer App.apis("twitter") to the OpenStruct choo-choo that is AppConfig.apis.twitter.
More modular (when we want it to be). If your configuration starts to outgrow itself, branch it out.

So what’s the easiest way to get started? Using this template:

# App (http://github.com/stephencelis/app), for Rails:
#
# In existing projects:
#   % rake rails:template LOCATION=http://gist.github.com/97629.txt
#
# For new projects:
#   % rails newapp -m http://gist.github.com/97629.txt

unless File.read("config/environment.rb").include? "stephencelis-app"
  gem "stephencelis-app", :lib     => "app",
                          :source  => "http://gems.github.com",
                          :version => ">= 0.2.2"
end

unless File.exist? "config/app.yml"
  generate "app_config"
end

begin
  Gem.activate "stephencelis-app"
rescue Gem::LoadError
  rake "gems:install", :sudo => true
end

unless Dir["vendor/gems/stephencelis-app*"].any?
  if File.directory?("vendor/gems") && yes?("Unpack gem?")
    rake "gems:unpack", :sudo => true
  end
end

You can also install App as a plugin, or maintain its gem installation yourself: just take a look at the README on GitHub.

What’s the password…haddock?

2009-03-29T00:00:00-04:00

Haddock worked for Groucho, and it can work for you. It’s not the password, but it can help get you there.

What’s haddock? Haddock is a gem:

% sudo gem install haddock
Password:
Successfully installed haddock-0.2.0
1 gem installed
Installing ri documentation for haddock-0.2.0...
Installing RDoc documentation for haddock-0.2.0...

Haddock is based on one of Apple’s own hidden gems: Password Assistant’s memorable password generator. It uses something most password generators don’t use:

Actual words. And so does haddock.

So now that you have a haddock, what are you going to do? Let’s make some passwords with ha-gen.¹

% ha-gen
habit57/love
% ha-gen
hawk47{uncle
% ha-gen
Bim52`bummer

Ripe for mnemonic stories, every one of them! And secure! But we can be even more secure:

% ha-gen --length=16
knab7[bitterhead
% ha-gen -l 24
picklelike63%captainship
% ha-gen -l30
craniology3430{incompetentness

Beautiful! Work on your diction as you go! Security and self-improvement! I’m not sure about you, but I could make these all day long. Be warned, though. When you use haddock a lot, another Haddock may come to mind:

This utility has an even more colorful vocabulary than the Captain’s. It uses your UNIX word list (at /usr/share/dict/words or /usr/share/words), so anything therein is fair game. The occasional anatomical term may put off sensitive users, but you can always make haddock eat your own words, easily enough:

% ha-gen -f ~/Documents/awesome_words.txt
gnarly8;cool

In fact, if you’re on Windows, you’ll have to. But don’t worry, Kevin has you covered.

In the end, though, haddock is a library for your Ruby applications. Want to add some flair to your web app’s password reset codes? This will probably look familiar enough:

require "rubygems"
require "haddock"

Haddock::Password.generate # => "bowl9&bracky"

include Haddock            # (Make things easier on our fingers...)

Password.generate(30)      # => "Phlebotomus2473?nonconditioned"
Password.generate(8)       # => "amy7@rax"

# To use a custom (newline-delimited) word list:
#
#   Password.diction = "/path/to/words"

That’s all it takes to get up and running. Your users will appreciate the friendlier alternative to a cryptographic digest. I don’t care how cool your code golf is.

All right, all right, I care. That stuff is just too cool.

Yahoo! for the future

2009-03-09T00:00:00-04:00

Doug Crockford has it out for me! Less than a week after I submit to our friend HTML5, he declares war! Off with its <HEAD>, says he:

…the HTML5 project is misguided… It is trying to do too much without a clear mission that defines the problems it is solving. I think the project needs a reset.

Oh, say it isn’t so, Doug! This is the guy that named JSON and gave him a home; the guy that prescribed us minification. This guy figured out which parts of JavaScript are good. He risked his life for us and lived to tell the tale ($29.99 list).

Then again, Old Doug also wrote JSLint, and let’s not even get into that one. Let’s move on. That’s what he’d want us to do.

No need to be bitter. Douglas only wants the best for us. Really. It’s just tough love from a stolid, fatherly figure with salt ’n’ pepper whiskers and a gentle grin.

But we already have XHTML, you may be quick to say. Where strict is cool! So what’s the deal with 4.2? More of the same? This document offers some clues.

Where’s the glitz, though? The dazzle? What can an artist do without a canvas? We could have audio and video, and no plugin! You won’t miss my congratulatory advertisement this time. You deserve to know. And to know the joy of SQL, finally, in the browser. Forms with placeholders and validations built-in! Vectors! details! And the semantics, oh the semantics! What’s a poor old Google to do, parsing through divs and spans when it could have nav, article, and aside? Won’t somebody please think of the robots?

But let’s leave the HTML argument be, for now. We can at least agree that CSS is in a wonderful place. JSON’s little half nephew is doing all right.

This next one’s for you, Crock.¹ (Safari 4 or equivalent required; just hover over the image.)

Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!
Yahoo!

Yahoo!
Yahoo!
Yahoo!
Yahoo!

Now I just need an audience

2009-03-02T00:00:00-05:00

Warning! This Library Is Deprecated!

Please Please don't use this library anymore. It was a good run, though. We had some laughs and it was easy for the iPhone to hear them.

This code has been deprecated in favor of Apple's built-in solution, available since iOS 3.0: AVAudioRecorder.

Mobile Orchard published a nice tutorial.

Voice activation. Sounds cool, doesn’t it? And all the cool people are using it! Nintendo was on to something with their DS and its microphone: Wario's little games were no match for a little heavy breathing. With the iPhone, Smule is using it up a storm! And iSteam? Yes! These guys get it: people love doing stuff with their mouths! If there’s some kind of reward involved, well then, now you’re talking. Blowing out candles, kissing, outright yelling up a scene—these are the things of life, right?

Apple’s been a pretty good parent: keeping the sandbox clean, inviting us to use the cam’, the accelerwhometer, the GPS, all without making us do too many chores. C’mon, Apple, what do you have for the mic’? We wanna be cool kids!

What’s this? Audio Queue Services? Looks heavy. Lots in here. We just want to make a birthday cake app’ with a birthday cake and a bunch of trick candles. Maybe a library buddy that shushes you if you’re disrespectful around the ardent readers. Or a game with a swarm of bees and you get to puff smoke at them! Oh! And maybe something with our friend Phillip and you get to finally put him in his place. Take that, Phillip!

…So, in a line or two of code I can figure out where in the universe my iPhone is and make sure I’m not holding it upside-down again, but I can’t figure out how loud I’m talking? Well, the pleasantly-prefixed SCListener may be able to help.

SCListener is a simple little singleton with the bare bones of iPhone microphone impedimenta. Getting the levels is a mere matter of asking. Here’s a quick tour to get you started:

#import "SCListener.h" // Remember to link to AudioToolbox.framework.

// Start listening.
[[SCListener sharedListener] listen];

// Retrieve the average power.
[[SCListener sharedListener] averagePower];

// Retrieve the peak power.
[[SCListener sharedListener] peakPower];

// Hmm...we're using this guy a lot...
SCListener *listener = [SCListener sharedListener];

// We can temporarily stop returning levels
[listener pause];
[listener listen]; // Quick.

// Or free up resources when we're not listening for awhile.
[listener stop];
[listener listen]; // Slower.

// Advanced!:
//
// If you're using the average and the peak, fetch both at once.
if (![listener isListening]) // If listener has paused or stopped...
  return;                    // ...bail.

AudioQueueLevelMeterState *levels = [listener levels];
Float32 peak = levels[0].mPeakPower;
Float32 average = levels[0].mAveragePower;

SCListener is available on GitHub: .

Now run along and throw your microphoney app’ into the ring. I’m just wrapping up a voice-activated flashlight, myself.

What? The flashlight vogue is over? Please. No one should ever get tired of flashlights.

Capistrano Growl notifications

2008-11-06T00:00:00-05:00

It’s very easy to lose track of your deployment. A cap deploy and we’re on to other things. Time passes, our deploy failed, and we’ve forgotten all about it! Time to address that.

Global `cap` configuration

Rake has Sake and ~/.rake/*.rakefiles; Capistrano has ~/.caprc. C’mon, cap’n’, let’s get modular!

From now on, when we save a Ruby script into our ~/.recipes/ directory, its tasks will be available to Capistrano wherever cap is invoked.

Growling

For Growl to play nicely with Ruby, we’ll need Leopard’s standard Ruby installation or equivalent—with RubyGems, RubyCocoa: the works.

Wait…some of you don’t have Growl? Well get it; install it; love it. If you’re just downloading it now, be sure to install growlnotify alongside it.

An alternative to growlnotify is Meow, a delightful little gem. It makes growling with Ruby quite effortless:

sudo gem install meow

All that’s left is our little Capfile:

# ~/.recipes/growl.rb
set :stage, nil unless defined? stage

namespace :growl do
  task :notify do
    growl_send(ENV["GROWL_MESSAGE"] || "wants your attention")
  end

  task :alert do
    growl_send(ENV["GROWL_MESSAGE"] || "needs your attention", 2)
  end
end

after "deploy" do
  ENV["GROWL_MESSAGE"] = "deployed #{application} #{stage}"
  growl.notify
end

after "rollback" do
  ENV["GROWL_MESSAGE"] = "rolled back #{application} #{stage}"
  growl.alert
end

def growl_send(message, p = 1)
  require 'meow'
  icon = OSX::NSWorkspace.sharedWorkspace.iconForFile(`which cap`.chomp) 
  Meow.notify("cap", "Capistrano", message, :priority => p, :icon => icon)
rescue LoadError
  `growlnotify -ncap -p#{priority} -m #{message.inspect} Capistrano`
end

Next time your deploy wraps up, you’ll know about it.

Oh, and if it doesn’t go over so well, you’ll know about it.

The definitive Leopard Ruby build

2008-11-05T00:00:00-05:00

Dan Benjamin has provided comprehensive compilation instructions to the Mac community for awhile now, but the latest one just doesn’t quite do it. If we want a build that’s as solid as Leopard’s built-in Ruby, we need to patch it for RubyCocoa:

curl -O http://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p160.tar.gz
tar xzf ruby-1.8.7-p160.tar.gz
cd ruby-1.8.7-p160
curl http://gist.github.com/98109.txt | patch -p0
./configure --enable-shared --enable-pthread --enable-install-doc \
            CFLAGS=-D_XOPEN_SOURCE=1
make
sudo make install

You should be good to go.

If things hiccup on Readline…

…you’ll need Readline in your local path. To install it:

Change the Ruby configuration line appropriately:

Finally, RubyCocoa

To get RubyCocoa up and running again, just check out the source, and install:

And finally, make sure it all worked:

% irb
>> require "rubycocoa"
=> true

Phew! We can use autotest with Growl again!

ez does it, gemdoc

2008-10-24T00:00:00-04:00

Let’s get back to basics. Let’s finally give Zsh and Vim a royal go (we’ll try Emacs next week).

$ chsh -s /bin/zsh
Changing shell for stephen.
% alias mate=mvim

`ez`

The shell is a place where configuration may go over convention. Ryan Bates organizes things nicely, so we can fork from there, then customize. Our first addition: an important alias that will make our editing easier. Enter E.Z.:

This will give us a split editor, the top level browsing ~/.zsh/, the lower level editing ~/.zshrc; upon closing the files, it’ll source them back in.

`gemdoc`

We may miss our BASH gemdoc, but now we can rethink things:

# ~/.zsh/config
export GEMPATH=`gem env gemdir` # we should cache this call

# ~/.zsh/functions/gemdoc
open $(echo $GEMPATH/doc/$1*(om[1]))/rdoc/index.html

# ~/.zsh/functions/_gemdoc
#compdef gemdoc
_files -W $GEMPATH/doc

Ah, we can even be a bit cleaner with that fancy glob.

For more on my setup, see my dotfiles.

Rails controllers, views & variables

2008-09-06T00:00:00-04:00

In object-oriented programming, an object uses instance variables to store private information. If you want to access an object’s instance variables, those variables should only be accessible through instance methods. At least, this is the expectation.

So when one dives into Rails, they may find it quite confusing when an instance variable set in a controller is also available in the view. Convenient, sure…but it somehow doesn’t feel true to Ruby. The controller and view are different objects with their own scopes, right?

How hard is it to be a purist? How can we tell Action Controller to be a little more discreet?

# config/initializers/less_gossip.rb

# Stop sharing so much!
ActionController::Base.class_eval do
  def add_instance_variables_to_assigns() end
end

# Stop caring so much!
ActionView::Base.class_eval do
  def assign_variables_from_controller() end
end

Now the controller has some privacy. Rails won’t force it to tell all its secrets to the view. The controller still needs to do its job, though, which likely involves retrieving data and serving it to the view. So how to we mediate the flow of information without instance variables? The same way Ruby usually does: attribute readers.

Let’s say we have a CRUD controller for articles. ArticlesController#index would normally assign @articles, so let’s define a reader method, articles, instead.

# app/controllers/articles_controller.rb
def articles
  Article.all
end

Now we can call articles throughout the controller, and it will return what @articles previously would have. Rails is pretty good about caching database queries, but that doesn’t mean we shouldn’t memoize as a best practice for optimization:

def articles
  @articles ||= Article.all
end

Ah, instance variables used as they were meant to be used.

So what about @article? Doesn’t its value change depending on the action being called? We just have to be a little smarter. Several lines of @article = Article.find(params[:id]) wasn’t very DRY, anyhow.

def article
  @article ||= if params[:id]
    Article.find params[:id]
  else
    Article.new params[:article]
  end
end

There we go. We’re accessing variables through getters! When we’re in the view, we only need to call those methods on the controller, which is available through ActionView::Base#controller. Here’s an example:

<%# app/views/articles/index.html.erb%>
<%= render controller.articles %>

What? That’s pretty ugly? And what about the controller public instance methods? They should refer to actions?

I guess we can’t completely ignore Rails’ conventions. We’ll have to make those getters private. But how, now, can we deliver these methods to the view? Luckily, Rails makes this easy with helpers:

# app/controllers/articles_controller.rb
helper_method :articles, :article

Now it looks nicer in the view, if a bit plainer than the @ decorations we’re all used to:

<%# app/views/articles/index.html.erb%>
<%= render articles %>

There are, actually, a few benefits to all this maneuvering (beyond clarity for the classically-trained Rubyist):

Maintainability: Any before filter you used, in the past, to set instance variables, is now irrelevant. You no longer have to worry about scoping it with :only or :except, or updating it when you add, remove, or rename actions.
Cacheability: These methods will only run when they’re first called during a request. If they only appear in the view, and the view is cached, you won’t hit the database.¹

Here’s our completed code:

class ArticlesController < ActionController::Base

  helper_method :articles, :article

  # render index, show, new, edit

  def create
    article.save!
    redirect_to articles_path
  end

  def update
    article.update_attributes! params[:article]
    redirect_to articles_path
  end

  def destroy
    article.destroy
    redirect_to articles_path
  end

  private

  def articles
    @articles ||= Article.all
  end

  def article
    @article ||= if params[:id]
      Article.find params[:id]
    else
      Article.new params[:article]
    end
  end

end

¹ Mike Burrows points out that if ActiveRecord::RecordNotFound is raised in the template, you are given a 500 error in production. ActionController::Rescue normally handles the 404s, while Action View wraps exceptions in its own TemplateError (always 500), so—coupling aside—we just have to make the view more aware.

  # config/initializers/less_gossip.rb
  class ActionView::Template
    def render_template(view, local_assigns = {})
      render(view, local_assigns)
    rescue Exception => e
      raise e unless filename
      case e
      when ActiveRecord::RecordNotFound # Ah. Here we are.
        raise e
      when TemplateError
        e.sub_template_of(filename)
        raise e
      else
        raise TemplateError.new(self, view.assigns, e)
      end
    end
  end

Bashfully yours, Migrations w/o Migraines

2008-08-07T00:00:00-04:00

Let’s face it. The migration timestamps, nice for teams and conflicts, are a bit painful otherwise. You create a migration and want to open it quickly, but the tab-completion is awkward. Too many numbers (shared by too many files) gum up the whole process.

$ script/generate migration add_comments_count_to_blog_entry comments_count:integer
    create  db/migrate
    create  db/migrate/20080807210534_add_comments_count_to_blog_entry.rb
$ mate db→/m→igrate/2→0080→→
20080[...]
20080[...]
20080[...]
20080[...]
20080[...]
20080[...]
20080[...]
20080[...]
20080[...]
20080[...]
[...]
--More--
$ mate db/migrate/20080

And that’s just the beginning. Copypasta? Sure…but do I really have to take my fingers from the keyboard?

How about a better way, with ~/.bash_profile:

# ~/.bash_profile

sg() {
  local migration=`script/generate $@ | awk ' /db\/migrate\//{print $NF}'`
  if [ $migration ]; then $EDITOR $migration && rake db:migrate; fi
}
alias sgmo="sg model $@"
alias sgmi="sg migration $@"

Let’s try it out.

source ~/.bash_profile
sgmi add_comments_count_to_blog_entry comments_count:integer

A quick edit, save, close, and…

(in ~/Code/blog/trunk)
== 20080807210534 AddCommentsCountToBlogEntry: migrating ======================
-- add_column(:blog_entries, :comments_count, :integer, {:default=>0})
   -> 0.0360s
== 20080807210534 AddCommentsCountToBlogEntry: migrated (0.0360s) =============

Beautiful. Migration editing without migraines.

Bashfully yours, Gem Shortcuts

2008-06-12T00:00:00-04:00

To gain quick BASH access to your RDocs, add these lines to your ~/.bash_profile (or equivalent):¹

Let’s try it out…

source ~/.bash_profile
gemdoc hpricot

Yummy Hpricot docs, instantly.

It will open the latest version, but you can specify, and tab completion simplifies the task:

$ gemdoc P→arseTree-2.→→
ParseTree-2.1.1/  ParseTree-2.2.0/
$ gemdoc ParseTree-2.

Great. All bases covered. Modify slightly if you want to open gems in your favorite editor. Replace open with your favorite website-opening command if you’re not on OS X.

(A hat tip to Mislav for the dotfile inspiration.)

Introducing Timeframe

2008-04-21T00:00:00-04:00

Welcome to GitHub, little one. May you grow into something big and strong.

More information and demo.
MIT License, so do what you will.
I’m just sick of multiple date pickers on the same page.

Download: .

Time-sensitive asset serving

2008-04-12T00:00:00-04:00

I had a cron job regularly sending new files to an asset host via rsync. It reduced the load on the application server, but how could I ensure that new files were served properly before the asset server synchronized? Simply.