Luke laid down code for cards. I know I’m helping the enemy, but I’ve got to tweak it. His code is:

 
class CardController < ApplicationController
  def play
    play_sym = "play_#{@card}".intern # PH: this should be .to_sym
    self.send(play_sym)
    render :action => play_sym and return
  end
 
  def pocket
    pocket_sym = "pocket_#{@card}".intern
    self.send(pocket_sym)
  end # PH: no explicit render here? Feels like a paste error
 
  protected
 
  # plays
  def play_roland
    # Play the game to see what happens when you play the Roland card!
  end
 
  def play_water
    # Play the game to see what happens when you play the Water card!
  end
 
  # pockets
  def pocket_roland
    # Play the game to see what happens when you pocket the Roland card!
  end
 
  def pocket_water
    # Play the game to see what happens when you pocket the Water card!
  end
 
end

 
class CardController < ApplicationController
  # I'm guessing from usage above @card is just the name for a card as a string
  # and that it's loaded from the url by a filter, note that I use it differently.
  before_filter :load_card
  after_filter :default_render_card
  
  def play
    @card.play
  end
 
  def pocket
    @card.pocket
  end
 
  protected
 
  def load_card
    @name = params[:card]
    @card = "card/#{@name}".camelize.constantize
  end
 
  def default_render_card
    render :template => "cards/#{request.action}/#{@name}" unless performed?
  end
end
 
# add in config/application.rb:
module Oaqn
  class Application < Rails::Application
    config.autoload_paths += %W(#{config.root}/app/cards)
  end
end
 
# and then create app/cards/roland.rb:
module Card
  module Roland
    def pocket
      # code for pocketing
    end
 
    def play
      # code for playing
    end
  end
end

So now the cards each get a source file to themselves, templates have their own per-action dirs (better swapped to per-card dirs, if there are more actions), there’s less duplicated code, and it’s far easier to test these smaller pieces. The only thing missing from this example is the fact that Luke may have to pass some game state into the methods. As long as there’s not too much it’s probably worth being explicit about.

2011-07-09: Luke actually used this code and found it didn’t work as written. I found an explanation; either add ‘app’ to autoload_paths instead of ‘app/cards’, or drop the Card wrapper.

Meanwhile, in the past, Jim wrote some PHP, and I’m not touching that language.

No, in seriousness, Jim talked about why he has some identifiers surrounded by __ (which I’d called python poisoning). I haven’t dug into his code (again, PHP), but it looks like it might be an InBandSignal to reuse Events as framework steps.

And then he talks about session fixation attacks, which are have been protected against out-of-the-box on PHP with the session.use_only_cookies setting for a while. I was a bit confused, I’m pretty sure he’s actually describing session capture attacks. Oh, and there was some other stuff about writing code to store sessions in the database. If you’re curious, Jim, here’s the code for a Rails app to do that, which appears commented-out in the stock config file for your editing convenience:

 
  Oaqn::Application.config.session_store :active_record_store

It includes support out of the box for keeping sessions in cookies (encrypted, of course), your SQL database via ActiveRecord, or Memcached. I’m curious, how much of your budget did you spend storing sessions?

The standard improvement is to use fixtures, a file with some example data, that your tests can load by giving the name of a fixture. Here’s one of the fixtures for a gamer:

alice: # alice is heavily involved
  id: 1
  mail: alice@example.com
  handle: alice
  password: red queen
  teaser: Follow the white rabbit.
  profile: Not so plain, after all.
  homepage: http://www.example.com
  jabber: alice@example.org
  location_id: 3
  last_login: 2006-10-30 11:56:08
  created_at: 2006-10-30 11:56:08
  location_at: 2006-10-30 11:56:08
  tag_text: dnd, wod
  mail_on_message: true
  mail_on_nearby_discussion: true

This is straightforward, but location_id is the id of another fixture in another file. As you can imagine it’s pretty easy to get them out-of-sync and break some tests. I end up leaving little comments in the YAML to remind myself of the cross-reference.

It’s awfully tempting to reuse fixtures from test to test. Maybe Alice was written to test logging in with a username and password and next I’m writing the test of logging in with an email address and a password. I could copy and paste Alice to another fixture to reuse in that test, but as a programmer I have a pathological aversion to copy and paste. Alice is going to get reused (most of those fields are optional and were used by very different tests), and after this happens a few times it’s hard to change a fixture without breaking an unrelated test.

I’ve gotten a lot of use out of fixtures as I’ve developed the habit of testing all my code, but reuse has made my tests somewhat brittle. After a bit of research, I’ve moved over to using factories.

Here’s the factory for a gamer:

 
Factory.sequence :handle { |n| "Gamer_#{n}" }
 
Factory.define :gamer do |g|
  g.handle { Factory.next :handle }
  g.mail { |m| "#{m.handle}@example.com" }
  g.password 'secret'
end

Only the essential, required fields are listed. Using this simple template, the tests themselves specify the values of the fields they’ll be testing.

 
def test_login_with_valid_username_and_password
  gamer = Gamer.create :handle => 'Alice', :password => 'red queen'
  ...
end
def test_login_with_valid_email_and_password
  gamer = Gamer.create :mail => 'alice@example.com', :password => 'red queen'
  ...
end

Ideally, changing a fixture wouldn’t break any tests at all. And factory_girl (what I’m using for factories in Rails) makes associations easy:

 
Factory.define :post do |p|
  p.association :discussion, :factory => :discussion
  p.association :poster, :factory => :gamer
  p.created_at Time.now.utc
  p.body "Post Body"
end

Now my tests include the specific data they care about, making them easier to understand and improve. And they don’t interrelate, so they’re much more reliable. I do still use fixtures, but now they’re exclusively for tests that need to deal with real-world examples.

I have three smallish website projects I plan to finish in this time. They’re in various stages of completion now.

The first is a mailing list archive. I’ve been tinkering with it on and off for about 18 months, and it’s the closest to a finished state. I really enjoy reading mailing lists, but haven’t been impressed with any of the sites out there. Often each message is its own page and threads are broken up. So I’ve done a lot of work on threading above and beyond the basic In-Reply-To and Re: matching, and the site is designed to show a thread per-page with lots of keyboard controls to make it easy to skim. Depending on free time this weekend, I may actually launch this before I leave town.

Second is a site cataloging Ruby gems. When I was searching out Rails forums I realized there’s a related problem in finding libraries that I could address. I’ve done the work to collect basic info on gems, it remains to collect news and blog posts and combine it into a nice presentation.

The last small project is my RailsRumble project (which I didn’t finish): a site for collaboratively producing transcripts of conference presentations. I’ve let this one simmer in the back of my mind in the four months since that failure and I’ve given it a better name and planned which features to finish, redesign, or drop. It needs a few days of solid development, a graphic design, and some seed content.

I plan to finish and launch these three projects by the end of March, and I’ll post more as I work on them.

The commonality in these three projects is that once I’ve launched them they require minimal ongoing attention from me and can grow at their own paces. I’m doing them first because small and well-defined projects fit well with the interrupted and distracted time I’ll have. I’d also want to make sure I start out with some successes.

Next posts: NearbyGamers and The Big Project That I Really Need To Name Already.

 
#!/usr/bin/ruby
 
FILE_FORTUNE = '/path/to/.fortunerc'
FILE_USED = '/path/to/.used-fortunes'
TWITTER_USERNAME = 'username'
TWITTER_PASSWORD = 'seekrit password'
GAP = (2 * 60)..(26 * 60) # gap between tweets in minutes:
 
# A cron job runs the script every minute with the word 'cron' 
# as an argument. It exits immediately unless enough time has passed
exit if ARGV[0] == "cron" and Time.now < File.mtime(FILE_USED)
 
require 'rubygems'
require 'digest/sha1'
require 'twitter'
require 'yaml'
 
 
class Array
  def rand
    self[Kernel.rand(length)]
  end
end
 
class Range
  def rand
    Kernel.rand(last - first) + first
  end
end
 
class String
  def sha1
    Digest::SHA1.hexdigest(self)
  end
end
 
module YAML
  def self.save_file filename, obj
    File.open(filename, 'w') { |f| f.write(obj.to_yaml) }
  end
end
 
 
# load fortunes, loop to pick one randomly
fortune = nil
used = YAML::load_file(FILE_USED)
fortunes = open(FILE_FORTUNE).read.split("\n%\n")
loop do
  fortune = fortunes.rand
  break if fortune.length <= 140 and !used.include? fortune.sha1
end
 
# post it to Twitter
Twitter::Base.new(TWITTER_USERNAME, TWITTER_PASSWORD).post(fortune)
 
# save that this fortune was used
used[fortune.sha1] = Time.now
YAML::save_file(FILE_USED, used)
 
# set time of next tweet
next_tweet_at = Time.now + GAP.rand * 60
File.utime(next_tweet_at, next_tweet_at, FILE_USED)

A short, single-purpose script like this doesn’t cry out for seemingly-fancy techniques like adding to builtin classes. But when you get to the core of the script, it’s obvious. Instead of the noise of a procedural calls for randomness and generating sha1s, the intention is the implementation. The reusable bits of the code are already explicitly extracted, making them easier to reuse.

Now that I’ve been doing this sort of thing in Ruby for a while I keep wishing I could do it in Python. With open classes I can add to the Strings and Arrays that other code returns to mine. I can’t subclass objects I don’t instantiate, the best I could do is write a delegating wrapper class.

*** glibc detected *** /usr/bin/ruby: double free or corruption (out): 0x299b2b08 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7d40d65] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d44800] /usr/lib/libruby1.8.so.1.8[0xb7ed5d79] /usr/lib/libruby1.8.so.1.8(ruby_xmalloc+0x85)[0xb7ed60c5] /usr/lib/libruby1.8.so.1.8(rb_str_buf_new+0x50)[0xb7f25b80] /usr/lib/libruby1.8.so.1.8[0xb7ef157e] /usr/lib/libruby1.8.so.1.8[0xb7eb733a] /usr/lib/libruby1.8.so.1.8[0xb7ebee8e] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7ec78fc] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7eca68a] /usr/lib/libruby1.8.so.1.8(rb_yield+0x21)[0xb7ecbad1] /usr/lib/libruby1.8.so.1.8(rb_ary_each+0x31)[0xb7ea41a1] /usr/lib/libruby1.8.so.1.8[0xb7eb7345] /usr/lib/libruby1.8.so.1.8[0xb7ebee8e] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7ec953d] /usr/lib/libruby1.8.so.1.8[0xb7ec6d64] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7ec8d9f] /usr/lib/libruby1.8.so.1.8[0xb7eca68a] /usr/lib/libruby1.8.so.1.8[0xb7ec771d] /usr/lib/libruby1.8.so.1.8[0xb7ec87d3] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7ec8d9f] /usr/lib/libruby1.8.so.1.8[0xb7eca68a] /usr/lib/libruby1.8.so.1.8[0xb7ec771d] /usr/lib/libruby1.8.so.1.8[0xb7ec7d91] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec7aa4] /usr/lib/libruby1.8.so.1.8[0xb7ec8d9f] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec797e] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec766a] /usr/lib/libruby1.8.so.1.8[0xb7ec76ce] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec766a] /usr/lib/libruby1.8.so.1.8[0xb7ec76ce] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] /usr/lib/libruby1.8.so.1.8[0xb7ebfbc8] /usr/lib/libruby1.8.so.1.8[0xb7ec766a] /usr/lib/libruby1.8.so.1.8[0xb7ec76ce] /usr/lib/libruby1.8.so.1.8[0xb7ebf766] ======= Memory map: ======== 08048000-08049000 r-xp 00000000 08:03 1704787 /usr/bin/ruby1.8 08049000-0804a000 rw-p 00000000 08:03 1704787 /usr/bin/ruby1.8 0804a000-2af12000 rw-p 0804a000 00:00 0 [heap] b5f00000-b5f21000 rw-p b5f00000 00:00 0 b5f21000-b6000000 ---p b5f21000 00:00 0 b6055000-b605f000 r-xp 00000000 08:03 1802307 /lib/libgcc_s.so.1 b605f000-b6060000 rw-p 0000a000 08:03 1802307 /lib/libgcc_s.so.1 b6060000-b7626000 rw-p b6060000 00:00 0 b7626000-b765e000 r-xp 00000000 08:03 737293 /usr/lib/ruby/1.8/i486-linux/nkf.so b765e000-b7661000 rw-p 00037000 08:03 737293 /usr/lib/ruby/1.8/i486-linux/nkf.so b7661000-b7662000 rw-p b7661000 00:00 0 b7662000-b7675000 r-xp 00000000 08:03 737288 /usr/lib/ruby/1.8/i486-linux/dl.so b7675000-b7676000 rw-p 00012000 08:03 737288 /usr/lib/ruby/1.8/i486-linux/dl.so b7676000-b77a1000 r-xp 00000000 08:03 1671348 /usr/lib/i686/cmov/libcrypto.so.0.9.8 b77a1000-b77b6000 rw-p 0012a000 08:03 1671348 /usr/lib/i686/cmov/libcrypto.so.0.9.8 b77b6000-b77b9000 rw-p b77b6000 00:00 0 b77b9000-b77f6000 r-xp 00000000 08:03 1671350 /usr/lib/i686/cmov/libssl.so.0.9.8 b77f6000-b77fa000 rw-p 0003c000 08:03 1671350 /usr/lib/i686/cmov/libssl.so.0.9.8 b7804000-b7807000 r-xp 00000000 08:03 819234 /usr/lib/ruby/1.8/i486-linux/digest/sha1.so b7807000-b7808000 rw-p 00002000 08:03 819234 /usr/lib/ruby/1.8/i486-linux/digest/sha1.so b7808000-b780b000 r-xp 00000000 08:03 737287 /usr/lib/ruby/1.8/i486-linux/digest.so b780b000-b780c000 rw-p 00002000 08:03 737287 /usr/lib/ruby/1.8/i486-linux/digest.so b780c000-b7842000 r-xp 00000000 08:03 2297548 /usr/lib/ruby/1.8/i486-linux/openssl.so b7842000-b7844000 rw-p 00035000 08:03 2297548 /usr/lib/ruby/1.8/i486-linux/openssl.so b7844000-b7a45000 rw-p b7844000 00:00 0 b7a45000-b7a59000 r-xp 00000000 08:03 1640498 /usr/lib/libz.so.1.2.3.3 b7a59000-b7a5a000 rw-p 00013000 08:03 1640498 /usr/lib/libz.so.1.2.3.3 b7a5b000-b7a5c000 rw-p b7a5b000 00:00 0 b7a5c000-b7a60000 r-xp 00000000 08:03 737298 /usr/lib/ruby/1.8/i486-linux/strscan.so b7a60000-b7a61000 rw-p 00003000 08:03 737298 /usr/lib/ruby/1.8/i486-linux/strscan.so b7a61000-b7a6b000 r-xp 00000000 08:03 737296 /usr/lib/ruby/1.8/i486-linux/socket.so b7a6b000-b7a6c000 rw-p 00009000 08:03 737296 /usr/lib/ruby/1.8/i486-linux/socket.so b7a6c000-b7a74000 r-xp 00000000 08:03 737323 /usr/lib/ruby/1.8/i486-linux/zlib.so b7a74000-b7a75000 rw-p 00007000 08:03 737323 /usr/lib/ruby/1.8/i486-linux/zlib.so b7a75000-b7a8f000 r-xp 00000000 08:03 737299 /usr/lib/ruby/1.8/i486-linux/syck.so b7a8f000-b7a90000 rw-p 0001a000 08:03 737299 /usr/lib/ruby/1.8/i486-linux/syck.so b7a90000-b7cd7000 rw-p b7a90000 00:00 0 b7cd7000-b7e1b000 r-xp 00000000 08:03 1838871 /lib/tls/i686/cmov/libc-2.6.1.so b7e1b000-b7e1c000 r--p 00143000 08:03 1838871 /lib/tls/i686/cmov/libc-2.6.1.so b7e1c000-b7e1e000 rw-p 00144000 08:03 1838871 /lib/tls/i686/cmov/libc-2.6.1.so b7e1e000-b7e21000 rw-p b7e1e000 00:00 0 b7e21000-b7e44000 r-xp 00000000 08:03 1838875 /lib/tls/i686/cmov/libm-2.6.1.so b7e44000-b7e46000 rw-p 00023000 08:03 1838875 /lib/tls/i686/cmov/libm-2.6.1.so b7e46000-b7e4b000 r-xp 00000000 08:03 1838873 /lib/tls/i686/cmov/libcrypt-2.6.1.so b7e4b000-b7e4d000 rw-p 00004000 08:03 1838873 /lib/tls/i686/cmov/libcrypt-2.6.1.so b7e4d000-b7e74000 rw-p b7e4d000 00:00 0 b7e74000-b7e76000 r-xp 00000000 08:03 1838874 /lib/tls/i686/cmov/libdl-2.6.1.so b7e76000-b7e78000 rw-p 00001000 08:03 1838874 /lib/tls/i686/cmov/libdl-2.6.1.so b7e78000-b7e79000 rw-p b7e78000 00:00 0 b7e79000-b7e8d000 r-xp 00000000 08:03 1838885 /lib/tls/i686/cmov/libpthread-2.6.1.so b7e8d000-b7e8f000 rw-p 00013000 08:03 1838885 /lib/tls/i686/cmov/libpthread-2.6.1.so b7e8f000-b7e91000 rw-p b7e8f000 00:00 0 b7e91000-b7f4f000 r-xp 00000000 08:03 1755193 /usr/lib/libruby1.8.so.1.8.6 b7f4f000-b7f52000 rw-p 000bd000 08:03 1755193 /usr/lib/libruby1.8.so.1.8.6 b7f52000-b7f62000 rw-p b7f52000 00:00 0 b7f62000-b7f64000 r-xp 00000000 08:03 819232 /usr/lib/ruby/1.8/i486-linux/digest/md5.so b7f64000-b7f65000 rw-p 00001000 08:03 819232 /usr/lib/ruby/1.8/i486-linux/digest/md5.so b7f65000-b7f66000 r-xp 00000000 08:03 737291 /usr/lib/ruby/1.8/i486-linux/fcntl.so b7f66000-b7f67000 rw-p 00000000 08:03 737291 /usr/lib/ruby/1.8/i486-linux/fcntl.so b7f67000-b7f6b000 r-xp 00000000 08:03 737297 /usr/lib/ruby/1.8/i486-linux/stringio.so b7f6b000-b7f6c000 rw-p 00003000 08:03 737297 /usr/lib/ruby/1.8/i486-linux/stringio.so b7f6c000-b7f6e000 r-xp 00000000 08:03 737290 /usr/lib/ruby/1.8/i486-linux/etc.so b7f6e000-b7f6f000 rw-p 00001000 08:03 737290 /usr/lib/ruby/1.8/i486-linux/etc.so b7f6f000-b7f72000 r-xp 00000000 08:03 737301 /usr/lib/ruby/1.8/i486-linux/thread.so b7f72000-b7f73000 rw-p 00002000 08:03 737301 /usr/lib/ruby/1.8/i486-linux/thread.so b7f73000-b7f75000 rw-p b7f73000 00:00 0 b7f75000-b7f8f000 r-xp 00000000 08:03 1808831 /lib/ld-2.6.1.so b7f8f000-b7f91000 rw-p 00019000 08:03 1808831 /lib/ld-2.6.1.so bfef7000-bff1c000 rw-p bfef7000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] Aborted (core dumped)

The output of one of the four crashes I earned from the Ruby interpreter today. It’s likely the rubyzip library being flaky, but ouch. I’ve got some long jobs pushing around ~12G (uncompressed) for a project I’ll show off later this week and it’s hard to get finished when I have to babysit jobs.

I’m processing all the items in a big list, and part of that is performing some expensive calculation on an item attribute. There are only a few dozen values for the attribute, so I cache them:

 
results = {}
 
for item in really_big_list:
    if item.attribute in results:
        result = results[item.attribute]
    else:
        result = expensive_calculation(item.attribute)
    # ... do something useful with item and result

It’s simple and readable, but it’s also lengthy. If I’m doing several expensive calculations on different attributes (and I am), my actual work gets lost in the noise. So I defined a dictionary that can do the heavy operation and cache the result:

 
class LambdaDict(dict):
    def __init__(self, l):                                                                                                                       
        super(LambdaDict, self).__init__()
        self.l = l
 
    def __getitem__(self, key):                                                                                                                  
        if key in self:
            return self.get(key)
        else:
            self.__setitem__(key, self.l(key))
            return self.get(key)
 
# and now my code becomes
 
results = LambdaDict(lambda  key:expensive_calculation(key))
 
for item in really_big_list:
    result = results[item.attribute]
    # ... do something useful with item and result
 

That’s really nice, clean code that I’m satisfied with. The difference in Python and Ruby here is that Ruby hashes (the equivalent of dicts) include this behavior by default, just pass a block (lambda) when constructing the hash and it’ll be called for every missing key.

I’ll have the same behavior in Python or Ruby, it’s just that the default Python object doesn’t give me a handy method for building a dictionary that might perform some arbitrary expensive method on a simple lookup. Ruby is in favor of implicit magic, so it holds out the hook. This is the difference I was trying to get at: Python’s builtin objects have fewer methods and convenient hooks for me to do weird and useful things than Ruby’s, and Ruby will even let me tinker with them. Ruby has open classes, so I can extend both the builtin and defined classes with my own methods:

 
module Enumerable # included by Arrays and similar objects
  def sum
    inject(0) { |x, y| x + y }
  end
end

This adds a sum() method every Array in my program, whether I construct it (like I created my own results dict) or get it from some library code. In Python I’d have to define my own Array type and I’d be out of luck if I’m getting back arrays from a library. Monkey patching is Python’s (deliberately clunky) name for adding a method to a single object at runtime. I’d have to monkey patch every object as it’s returned from the library rather than just being able to declare that every object of that class should have my method.

If this is the first time you’ve seen open classes: yes, when I first saw it I felt exactly the same way you do. Dangerous unreliable hackery, a recipe for disaster. But I’ve seen a lot of useful things happen in Rails because of it, and my Ruby projects have benefited from being able to add a method to an existing library’s objects, to overwrite (or just chain my code before or after) another method.

It’s something of a last resort that lets me build the cleanest object system I can as I interface with builtin objects and library code. I don’t have any utility methods floating around or have to tweak each object as I get it back from an API call. As I cook, Ruby’s metaprogramming is the garnish that finishes the dish. I called Python academically inconvenient because it feels like there’s an academic designer at my shoulder saying, “No, you don’t want to do that, it’d be messy and might be be abused. Pedagogically unsound.” I love that Python pushes me to build an explicit and obvious code, but I find myself wanting to tuck in one little bit of magic to make the code perfect.

Updated to Rails 2.0.1

• rm’d lib/slash_urls.rb: Rails switched from ; to / to separate actions
• rm’d lib/resource_requirements.rb: now included in ActiveResources
• rm’d app/helpers/tags_helper.rb and gamers_helper.rb that had old controller names and were unused anyways
• app/controllers/gamers_controller.rb: documented and fixed raw post variable extraction
• updated post_path linkers in many views, controllers, and tests
• renamed discussion_anchor_post_path to anchor_discussion_post_path to match the new ordering for nested resource urls
• fix tag sorting on tag index
• move tags from /tags/Board+Games to /tags/Board_Games, as Rails fixed the bug that encoded ‘ ‘ as ‘+’ in non-get variable parts of the URL

The Details

The first two files I deleted were my patches to URL generation that Rails now includes. The next two helper files I never used, but had had old (singular noun) names.

The bit about documentation: the way to get at raw post variables changed, so I tweaked code and left myself a reminder of why I’m doing it (I had to look at the changelog, which means it wasn’t self-evident).

Nested resources (I have nested map.resources :discussions { |d| d.resources :posts }) changed from discussion_edit_post_url to edit_discussion_post_url, so there was a bunch of places to change that. The next change about anchor is me following this convention with my own convenience method.

Tag sorting on the index page was a bug that Snarky pointed out to me. When I made some performance tweaks to that page I forgot to keep sorting tags as they came out of the database. This arguably should’ve been a revision of its own as it’s unrelated to the upgrade, but it was an easy one-line bugfix so I let it in.

Last, I renamed the tag pages. The tag model’s to_param just returns self.name and Rails would turn “Board Games” into “Board+Games”. It’s common but technically incorrect, as + only means space in encoded GET/POST variables. The proper encoding of “Board%20Games” was really noisy, so I took a page from Wikipedia’s pagebook and use underscores instead, like “Board_Games”. Was one line in the to_param and one line in the controller’s load_tag before_filter, a dozen lines of tweaking old tests, and seven lines of new tests. Eeeeeasy.

The Verdict

Tests, tests, tests. If I didn’t have a solid test suite, I’d be noticing bugs two months from now in the least-frequently-exercised bits of code. Not only would I not have remembered to test some of the functionality, I wouldn’t have remembered the corner cases — or maybe I’d just have gotten bored of clicking through pages over and over and ignored the corner cases.

None of these were hard fixes and none were frustrating. I’d probably have finished even sooner if I hadn’t also been poking lolcats and chatting with friends. And now I have a big list of shiny new Rails 2.0 features I can put to work in NearbyGamers.

Create or edit your .gemrc to read:

gemhome: /home/<i>your username</i>/.gems
gempath:
- /home/<i>your username</i>/.gems
- /usr/lib/ruby/gems/1.8

Next, set up your login environment. Add these lines to the end of your .bashrc, .bash_profile, or .profile (whichever file you happen to already have — if you use another shell, you should already know what file is the equivalent).

 
export PATH=~/bin:~/.gems/bin:$PATH
export GEM_HOME=/home/<i>your username</i>/.gems
export GEM_PATH=/home/<i>your username</i>/.gems:/usr/lib/ruby/gems1.8

Last, add the following to your .ssh/environment so that gems work properly when you’re executing commands over ssh (for example, with capistrano).

 
PATH=~/bin:~/.gems/bin:/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin
GEM_HOME=/home/<i>your username</i>/.gems
GEM_PATH=/home/<i>your username</i>/.gems:/usr/lib/ruby/gems1.8

You’ll need to log out and back in to update your login environment, and then you’ll be able to run gem normally. All the files get stored in the directory ~/.gems if you want to look around.

I’m now a big fan of Mocha like I am of Rails. Ruby has a way of allowing coders to write magically polished libraries.

I’m writing some code (“Fetcher”) to talk to a POP3 server, fetch mail, and pass it off to another process. One of the tests deals with what happens when the POP3 server is down or otherwise unreachable.

 
def test_setup_server_down
  pop3 = Mock.new
  pop3.expect(:new, [MAIL_SERVER, MAIL_POP3_PORT]){ raise Timeout::Error.new("execution expired") }
  f = Fetcher.new(pop3)
  # further assertions that f acts correctly
end

This says that the Mock object expects a call to the new method with the given arguments, and when the call happens it runs the block. The block could return anything, but in this case it raises the same error as Net::Pop3 does when it can’t contact the server. After that the test can go on to make whatever assertions it needs to verify that the exception was handled properly.

The Mock object has a list of calls it expects to see and keeps a list of how it’s been called (yes, this could just be one list with an index but I thought it was mentally simpler this way). The test sets up what calls it should expect to see with what arguments (or blank for any) and block to run (or blank for none). When a method is called on the mock object, method_missing logs the call and executes the given block (raising a fuss if the call didn’t match what it expected).

 
class Mock
  attr_reader :calls, :called
 
  # the stub arg makes it just record all calls
  def initialize
    @calls = []
    @called = []
  end
 
  # Pass nil for args to ignore the actual args in the call.
  # Proc is optional; default is empty proc returning nil.
  def expect(method, *args, &proc)
    @calls << {:method => method, :args => args.first, :proc => (proc or Proc.new{})}
  end
 
  def method_missing(method, *args)
    @called << {:method => method, :args => args}
 
    expect = @calls.shift
    raise "Unexpected mock call #{method.to_s}(#{args.join(', ')})" if expect.nil?
    raise "Wrong mock call #{method.to_s}(#{args.join(', ')}); expected #{expect[:method]}(#{expect[:args].join(', ')})" if method != expect[:method] or (expect[:args] != nil and args != expect[:args])
    expect[:proc].call(*args)
  end
end

It’s a straightforward little object, and I also added some code to raise a fuss if expected calls weren’t made. This does have the downside that any tests defining their own teardown need to call super.

 
class Mock
  def fail_if_not_empty
    # Empty the call stack so that this obj doesn't throw errors for
    # every later test between now and this object getting gc'd
    calls, @calls = @calls, []
    raise "Mock calls uncalled: n" + calls.collect { |call| "#{call[:method]}(#{call[:args]} { #{call[:proc] })" }.join(" ") unless calls.empty?
  end
end
 
class Test::Unit::TestCase
  def teardown
    finish_mocks
  end
 
  def finish_mocks
    ObjectSpace.each_object(Mock) do |m|
      m.fail_if_not_empty
    end
  end
end

This has been a handy piece of code to test the code I’ve written in the last two weeks, but it’s not good enough. I have to use a technique called dependency injection to test Fetcher.new, where the outside code passes it a POP3 object instead of its initialize just using Net::POP3. Useful for testing, but my code is badly repetitive when all the instantiation calls have to do this exact same setup. (As an aside, Jacob Proffitt recently started an interesting conversation on dependency injection, took criticism, and responded. Good reading.)

I was pondering how to extend the Mock object to let me mock class methods (eg a call to Net::POP3.new) when I realized I’d gone as far as I should down the do-it-yourself road. I’d heard of Mocha and it took me all of ten minutes to think to look at its cheat sheet where that’s the first example.

After spending two hours or so writing and tweaking this code, the best thing for it is to be thrown away. I’ve learned about mocking by doing it and I’m better-prepared to understand someone else’s larger and better library.

Now it’s time to treat it as real code, which means getting it under test. Tests are especially useful for ensuring tricky edge cases like malformed input don’t quietly break during other changes. When I started writing unit tests for the sorter I wanted fixtures similar to the Rails fixtures so I could write:

 
require File.dirname(__FILE__) + '/../test_helper'
require 'message'
 
class MessageTest < Test::Unit::TestCase
  fixtures :message
 
  def test_initialization
    f = Message.new message(:good)
    # assert the object was parsed correctly, etc.
  end
end

The basic usage is fixtures :type to load the data and create the named function (in this case, message) for fetching data. First, I wrote some YAML fixtures for my data and put them in test/fixtures/message.yaml. You can see the :good key in use here:

good: |
  [the body of a good message here]
missing_header: |
  [more text]
bad_checksum: |
  [more text]

Because I’m parsing textfiles my fixtures look pretty simple, but the YAML library for Ruby makes serialization of any very easy.

So here’s the code I put in test/test_helper.rb to set this up. I really like the [list].flatten.each idiom so the call from the unit test class can cleanly pass one or more types, eg: fixtures :message and fixtures :message, :user.

 
class Test::Unit::TestCase
  @@fixtures = {}
  def self.fixtures list
    [list].flatten.each do |fixture|
      self.class_eval do
        # add a method name for this fixture type
        define_method(fixture) do |item|
          # load and cache the YAML
          @@fixtures[fixture] ||= YAML::load_file("test/fixtures/#{fixture.to_s}.yaml")
          @@fixtures[fixture][item.to_s]
        end
      end
    end
  end
end

(Note to Rails coders: I deliberately left out the pluralization, I like having the File class in file.rb with the fixtures in text/fixtures/file.rb and the database table named file and so on. I don’t mind Rails’ convention of pluralizing to “files” in the latter two examples, but I’d rather have a single identifier.)

Last night at the Rudolph Hering Society meeting Ian Bicking and Atul Varma explained mocking to me. I wrote a (very) little Ruby this morning to do mocking and I’ll post that in a day or two when I’m sure I didn’t do it too badly.

human-readable

I should get some idea of what the discussion’s about when I hover over a link

permanent

bookmarks, incoming links, and search engines all need reliable URLs

editable

If a discussion drifts, it needs a new subject, which means it needs a new URL

opaque

I’d rather not roll out the carpet for someone to scrape all the discussions

After a bit of pondering, I decided that URLs should look like this:

http://nearbygamers.com/discussions/{slug}-{post count}-{subject}

slug

An unchanging random 5-character string.

post count

The number of posts in this discussion, so that when you look at the discussions index you know at a glance if you’ve read a thread because your browser colors visited links. I snagged this off the Joel.

subject

Just the alphanumerics, dash-separated, updated as the subject is edited

So two parts (post count and subject) on a discussion can change, and the controller uses the slug to load the discussion and redirect to the correct URL if either has changed. Bookmarks and search engines can update, and outside links never stop working.

The Code

First, a little snippet of code to generate slugs lives in lib/slug.rb:

 
def random_slug(length=5)
  chars = ("a".."z").to_a + ("A".."Z").to_a + ("1".."9").to_a
  Array.new(length, '').collect{chars[rand(chars.size)]}.join
end

The Discussion model uses this to set a slug on itself if it doesn’t have one yet, and then uses that slug to generate URLs (note that I remove multiple and leading/trailing hyphens from the subjects):

 
require 'slug'
 
class Discussion < ActiveRecord::Base
  def to_param
    "#{slug}-#{posts.count}-#{subject.gsub(/[^[:alnum:]]+/i, '-').gsub(/-+/, '-').gsub(/^-|-$/, '')}"
  end
 
  protected
  def before_validation
    if self.slug.empty?
      begin
        self.slug = random_slug
      end while(Discussion.count(:conditions => ['slug = ?', self.slug]) > 0)
    end
  end
end

Finally, the DiscussionsController loads discussion objects, throws 404 errors, and redirects appropriately:

 
class DiscussionsController < ApplicationController
  before_filter :load_discussion, :except => [ :index ]
 
  private
  def load_discussion
    slug = params[:id].split('-').first if params[:id]
    @discussion = Discussion.find_by_slug(slug) if slug
    raise ::ActionController::RoutingError, "Recognition failed for #{request.path}" if @discussion.nil?
    redirect_to discussion_path(@discussion) and return if @discussion.to_param != params[:id]
  end

In the <head> of your app/views/layouts/application.rhtml call the auto_discovery_link_tag to print the tags:

 
  <%- @feeds.each do |feed| -%>
    <%= auto_discovery_link_tag(:atom, *feed) %>
  <%- end -%>

In app/controllers/application.rb:

 
  def initialize
    @feeds = []
  end
 
  def add_feed title, options={}
    @feeds << [ { 
      :controller => self.controller_name, 
      :action => self.action_name, 
      :format => 'atom' 
    }.update(options), { :title => title } ] 
  end

And you’re all set up. Where you want an action to present feeds, call add_feed. After title, it takes options for url construction.

 
  add_feed 'New discussions'
  add_feed 'New posts', :action => 'posts', :sort_by => 'new'

It defaults to the current action with a format of ‘atom’ so you can add feed code to your respond_to block. I’ll post again soon with code integrate resource_feeder to do this.

Hey, of course that’s easier to read. It’s also dead easy to add to your existing tests thanks to a gem by Pat Eyler, whether you call then with rake test, rake test:units, or ruby test/functional/application_controller_test.rb.

 
$ sudo gem install redgreen

Edit your test/test_helper.rb and add require 'redgreen' after the other requires, and you’re done. If you run your tests, you’ll see something like:

Passes are green, fails are red, errors are yellow. Here’s hoping you just see lots of green.

And rspec looks like good stuff, I’m going to add it to my test suite for NearbyGamers. The ability to test controllers without testing views (and vice-versa) will be a win.

Basically it’s the mashup of a wiki and Google Maps, and I plan to add forums (there are very few things gamers like more than arguing online). I’ve been hacking at it on and off for a couple months now, and it’s finally worth talking about. NG is my first large Rails project, and it’s been a lot of fun. Almost all the time the code is quite dense and beautiful, but several times I’ve worked up some fairly ugly hackish code I’m not particularly happy with. And then a few days later an nice, friendly little solution will pop into my head, and it’s easy to hack in because I have comprehensive tests. (Having tests has really saved my life. I’ll be posting more about it, but for now I’ll just say that I couldn’t have built NG without automated tests.)

Some of the early beta testers are computer game fans, so there’s a fair number of computer games listed on NearbyGamers right now — heck, World of Warcraft is the most popular tag. I don’t see what folks will get out of it, but I’d rather build a pretty open system and let folks find new uses.

So check it out, let me know what you think. I’ve got a todo list online for the curious, and I’m always taking suggestions.

The W3C Validator complained that I didn’t have the rows and cols attributes on my <textarea> tags. My code for them looked like:

 
<%= text_area_tag :message, params[:message] %>

And I don’t want to add the :size option because I use CSS to style all of them, it’d be confusing to see an unused size there. So I extended the text_area_tag method in my app/helpers/application_helper.rb to fill in a default:

 
module ApplicationHelper
  def text_area_tag(name, content=nil, options={})
    super(name, content, { :size => "40x10" }.update(options))
  end
end

And it was that easy to start having valid tags. I’ll be posting more Rails snippets and tips as I work on my project, and I’ll definitely announce here when it’s ready for wide release.

(This snippet owes thanks to ‘leethal’ in #rubyonrails on irc.freenode.net for straightening out how I was trying to override the method.)

I like to break down stylesheets so there’s a site-wide stylesheet with global stylings like fonts, the site’s template, and common elements. This is the file that metastasizes on you.

My solution is to break down stylesheets by controller and action, and Rails makes this quite easy:

 
# app/views/layout/application.rb
<%= stylesheet_link_tag *(['global'] + @stylesheets) %>

 
# app/controllers/application.rb
class ApplicationController < ActionController::Base
  before_filter :add_stylesheets
 
  def initialize
    @stylesheets = []
  end
 
  def add_stylesheets
    ["#{controller_name}/_controller", "#{controller_name}/#{action_name}"].each do |stylesheet|
      @stylesheets << stylesheet if File.exists? "#{Dir.pwd}/stylesheets/#{stylesheet}.css"
    end
  end
end

This code automatically loads stylesheets for the controller and the action if they exist. The subdivision allows you to make them as compact and specific as possible. If a partial needs its own code, write at the top:

 
<% @styleshets << "controller/_partial_name" %>

Nice and tidy.

Source: Pretty much everyone the first time they hear of DSLs.

Answer: No, a DSL is much more than a library, and I have an example that won’t make you say, “Well, sure, if you’re doing something that esoteric…”

My example of a domain-specific language is strings. No, seriously. Let’s figure out the length of a string in x86 assembly:

 
strlen:
	push	edi
	sub	ecx, ecx
	mov	edi, [esp+8]
	not	ecx
	sub	al, al
	cld
repne	scasb
	not	ecx
	pop	edi
	lea	eax, [ecx-1]
	ret

Computer memory is one big linear stream of bytes we can scan through, looking for the null that terminates our string. Boy, is that some fast code — we might even call it efficient, if we ignore the fact that we’ll reach the eventual heat death of the universe before we finish our web 2.0 app.

So we move up in abstraction to C, which has arrays. And you can pretend a string is an array and walk it looking for that null terminator:

 
static int my_strlen(const char *c) {
    int l = 0;
    while (*c++) l++;
    return l;
}

This code is basically the same as in assembly, but it must be nicer to read because it uses all that stylish punctuation. Well, it’s not really nicer, maybe a string isn’t really just an array. So let’s look at Python:

 
len("Hello, world!")

Now that’s downright human-readable. And I’ll admit I’m fudging here by just calling the built-in len() instead of writing one, but it just works and there’s none of this messing around with null bytes.

Well, maybe there’s messing around with null bytes. I don’t have to know how Python implements len() and, more importantly, I don’t have to pretend a string is only an array or a small bit of sequentially-addressed memory.

To continue the example let’s look at regular expressions, a powerful way to search strings. We’ll write a pirate detector in Python:

 
import re
matches = re.search("ar+g+h", "Oim a poirate, arrrgh!")
if matches:
    print "There must be a pirate, I heard someone say '%s'." % matches.group()
else:
    print "No pirates detected."

This is important code, as pirates hide all over the web. But it’s pretty clunky, we have to import a library and call functions and evaluating responses and save objects… It’d sure be handy if regular expressions were part of the language like in Ruby:

 
if "Oim a poirate, arrrgh!" =~ /ar+g+h/ then
  puts "There must be a pirate, I heard someone say '#{$&}'."
else
  puts "No pirates detected."
end

This code is even nicer, our regexp is a first-class type and tightly integrated into the language. The increase in stylish puncutation might make for a higher learning curve, but we can express ourselves much more naturally.

A DSL is all about moving up in abstraction until your code directly reflects the high-level concepts you’re working in. You don’t have to peer through a haze of bits and pointers, your actions become synonymous with your intentions.

 
"3 4\n5 6\n7 8".each do |line|
  v1, v2 = line.split
  print Integer(v1) + Integer(v2), " "
end

The book is just explaining to Perl coders that you have to call Integer() to convert strings to ints, but I see an interesting opportunity to restructure the code.

 
"3 4\n5 6\n7 8".collect do |line|
  line.split
end.each do |a, b|
  print Integer(a) + Integer(b), " "
end

My brain is nagging me that there’s a fundamental concept at work in this change, but I can’t quite put my finger on it. It’s not just that I’m building an array in the middle or that it evaluates differently (after producing identical output), it’s that it looks something like nested fuction calls. It feels like a more a functional style of programming, but that’s not quite all.

I’m compelled to write this as a block yielding to a block, though it doesn’t compile:

 
"3 4\n5 6\n7 8".collect { |line| yield line.split } { |a, b| print Integer(a) + Integer(b), " " }

Any thoughts? Am I just being weird, or can anyone put better words to it?