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.

What I plan:

Performance Improvements

Despite what I did in November, some parts are still laggy; on the Internet if it isn’t instant, it’s slow. I’m aware of FireRuns Manage and NewRelic’s RPM for production performance monitoring. I’ll almost certainly end up with Manage (30-day trial) because RPM’s trial (30 minutes of data, useless for a small/young/low-traffic site) is so weak, but I’d really appreciate comments if anyone knows of other good tools.

News Aggregation

There are a lot of tabletop gaming/board game/RPG blogs and hand-edited news sites, and I think NearbyGamers would do well to aggregate those similar to Reddit/Digg. It’d bring gamers back to the site more regularly (rather than the common ‘signup, leave for a few months until someone new messages you’) and drive discussion, which is the best way to meet folks.

Groups

One of the biggest uses of the discussion forum is folks trying to organize gaming groups. Now that I’ve seen this happen a few times, I can build proper support for groups: a marker on the map, a dedicated forum per group, and advertising open slots for gamers, to start. Then there’s the next obvious feature for them:

Events

With or without a group, it should be possible to display upcoming events on the maps. List date and time, attendance information, link to a homepage if one exists, maybe have a dedicated forum.

Stores

It would also be good to list gaming stores on the map, which are oddly often difficult to find. This especially relates to the previous; I’d love to see what events my local stores have on their calendars. I also think gaming stores are nicer for browsing than websites, I’ve found so many interesting random games at stores that I wouldn’t have glanced at online. I’d like NearbyGamers to help stores stay in business and grow because they incubate local gaming communities.

After I finish with the small projects, I think these features will probably take me a solid month to implement. NearbyGamers is developing a regular community, and I have a responsibility to help it thrive. What I’ll do afterwards is its own couple hundred words for tomorrow.

Next: The Startup Project That Lacks Even a Working Title

Why is my bug not fixed ? why is the UI still so unpleasant ? why is performance still poor ? why does it consume more memory than necessary ? why is it getting slower to start ? why ? why ? – the answer lies with developers: Will you help us make OpenOffice.org better ?

Meeks identifies the lack of growth in the community as the core problem and his suggestions for improving the software product are about redesigning the community to be more responsive to developers, to welcome newbies better, and to simplify the act of contributing. Notably, he doesn’t suggest a single technical change for improving bugs, the UI, performance, or other features.

Maybe this is a better example than mine of Django and Rails: developers don’t tend to get irrationally competitive about office productivity suites and stop listening like they do web frameworks. (This is part of why OOo is in more trouble than Django.) The point is the same, though: a healthy, active community is the only guarantee of a an open source project’s viability. Community determines whether a project keeps up with its competition and redefines the limits of its field, or maintains the status quo, or becomes unreliable and unusable.

Communities need to be active to continue improving the project, deal with bugs and changes to their ecosystem. If no one is interested enough to talk about the project, none of that will happen. Newcomers need to meet experienced users to be sold on why to use the software, to get help as they learn their way around, to maybe be drawn into contributing to the project itself.

Some communities are maladjusted. They self-defeat (see the section on Bion’s support groups), they lack plans or goals, they abuse newbies to keep from growing or changing, they’re more interested in bringing something down or defending turf than building up their own project. Some successful projects start with a grudge to pick, but most that do so fail to develop their own identify, and you can hear that in a cacophony of blame and flames in their social spaces.

Productivity is the best way to tell if a community is well. Even if it doesn’t have regular releases, it needs explicit plans on a reasonable schedule to meet measurable goals. Good software is produced by careful and deliberate iteration.

All well and good, but what about the slugfest between Django and Rails? When do we get to the part where I reveal myself as an irrational, deceptive propagandist because I say anything nice about the project you don’t prefer? Better question: why is there so much vitrol between the two?

The two are far more alike than dissimilar: extracted from projects that were created in similar dynamic languages from late 2003 through 2004, their core functionality was routing URLs to templates rendered with data retrieved with an ORM.

The biggest early difference is in these two contemporaneous blog posts: Django releases, Rails turns 1. Django was wrongly seen as a Python copy of Rails on its release, though it’s just a case of convergent evolution: to solve similar problems they developed along the same lines.

If success is binary, both Rails and Django are successes. They’re strong, reliable tools for building websites quickly. They are their respective languages’ leading web frameworks. Speaking personally, I enjoy working daily in both.

If success is relative, Rails is far more successful than Django. By any measure I can take, the Rails community is at least ten times larger. For example, Indeed has more jobs and Google Trends shows more searches:

And yesterday I posted about the difference in books with a ridiculous title. The difference between eight books and dozens can’t be explained away by Python being simpler, the Django docs being better, or Rails being more of a moving target (all true); none of them would stop publishers from trying to profit from an audience. The jobs, the searches, the books: they’re imprecise metrics that all point the same direction.

Rewind. Rails and Django were roughly technologically equivalent. They were both once a little flaky and incomplete and Definitely Didn’t Scale. But with the aid of good marketing, Rails turned its earlier release into a lead in in the developer market and created a vibrant, growing community (even if that community acts out a self-parody roughly annually).

Rails has had more resources in the form of bloggers, coders, writers, trainers, and users, and it’s used them to push in far more directions than Django has. Rails has explored dead ends like components, built plugins and changed course to use better integration with its package manager, and soon the entire Merb sort-of-fork project is merging into Rails with the results of its successful experiments.

Django hasn’t moved nearly as fast, it hasn’t had the resources to make as many mistakes to learn from. The Django community is recovering from an 18 month gap between feature releases (0.96 on March 23, 2007 and 1.0 on September 3, 2008). 1.0 included a lot of great features and improvements, but it was a long, quiet year-and-half getting there while Rails was continuing to iterate.

It’s not a question comparing 1.0 minus .96 against 2.2 minus 1.2.3. It’s about activity and momentum, Django lost it while Rails has used the network effect to grow the most active web development community to build better software. Count the amount of blog posts, consultancies, newbies, rants, silliness, projects, and weaknesses addressed instead of books and see how Rails has succeeded. It is its own ecosystem instead of only being part of the web.

The difference in relative success is that Django’s still a useful tool for building good websites. Meanwhile, Rails has Changed The Web, influencing graphic design, pushing collaboration, proving the value of Javascript toolkits, driving the adoption of distributed version control. I’m not claiming Rails is singlehandedly responsible for these trends, I’m saying it’s been a dominant force in these advancements of the web.

The Django and Rails communities fight so much and so rudely because they’re too similar not to. Projects survive and thrive because they have attention from developers, and developers don’t often pick up two tools to do the same job (usually it’s one tool for every job). Community is the lifeblood of every open source project and the world of difference between Django and Rails is evidence.

Rails

In Conclusion

The difference speaks for itself. I’ll write about why this matters tomorrow.

(Yeah, I used the Fancy Link Builder I posted yesterday about. It was infuriating to use, it has whiz-bang Javascript to open a product detail lightbox that served only to make it nearly impossible to copy cover images. New theory: the creators of the Fancy Link Builder are moles from offline bookstores who have infiltrated Amazon to destroy it from within.)

Poor scheduling

Couldn’t stay up because work is demanding in the election season, so working late would mean I’d limp through the next week of important coverage. More than that, though, was a bad mistake in scheduling a social outing. I didn’t figure in some of travel time and the friend driving wanted to spend a lot more time out, so instead of having a nice morning out I got home at 7 PM tired and in a foul mood. I was able to relax a bit and get some code done, but it cut my available time by more than half.

Too many new toys

I knew I hadn’t played with encoding video before, so I asked an expert for some tips and tinkered around breaking test videos down into short, easily-transcribed segments. Not coincidentally, this is basically the only feature that works. I started with bort to get a lot of basic functionality quickly, but I had no experience with most of the plugins it provided (and those I otherwise planned to use).

aasm

Differences between acts_as_state_machine (which I started with) and aasm (the successor that bort ships).

haml

Translating scaffolding from erb to haml and a (still-unsolved) bug that causes it to render content twice on one page. (And I’ve even used haml before.)

open_id_authentication/restful_authentication

I wanted users to be able to contribute anonymously or use OpenID to receive credit for their contributions without having to set up an account, and the plugins came configured for conventional user accounts.

resource_this

I had to fix a templating bug, and there’s a fair amount of magic to learn to work with.

rspec

Scaffolded tests needed slow, tedious tweaks to work with resource_this. I think I like the idea of rspec more than the implementation.

paperclip

Sorting out finicky path/url issues, and I couldn’t find a way to mock validates_attachment_presence so several models went unspeced..

Each of these issues ate 30-60m, and there went the time to build. Some plugins (acts_as_versioned, footnotes, random_finders) just worked great, but none was really related to core functionality. Speaking of which:

Core featureset too big

The line between nothing and application includes site graphic design, listing conferences, uploading presentation videos, splitting videos into segments, adding transcripts, viewing all of the these, editing transcripts… I had a lot of features listed as optional, but there was still a long set of base features and each uncovered another one of those frustrations.

No teammates

It would’ve helped a lot to have someone to work with. Not just because it would have taken less time to finish the core features, but for the enjoyment of teamwork and to complement my weaknesses.

All told

I’m glad I spent time I spent hanging out in #railsrumble or on the RailsRumble present.ly. Even if it didn’t directly result in items checked off the todo list, it’s been a fun community to be in, and I was glad to help folks out. I’m eager to see what other people came up with.

I didn’t enter RailsRumble to win, I entered for the excuse to create what I thought was an interesting small project. I’ll pick ConfReader back up in a little while, probably after the election. I still think it’s too good an idea not to build, but I’m a bit tired right now.

I’ve watched a lot of video from conferences in the last month or two, and they really frustrated me. Video is slow and linear — I could read five presentations instead of watching one and wondering if it’s going to be worth the time it takes. I really appreciate all the presentations, I just get impatient trying to find out if I’m going to enjoy one, or waiting for the speaker to make their next interesting point. And it’s hard to share them — “Hey, skim this web page” is a lot easier than “Hey, commit to watching this hour”.

My app is going make it easy for folks to collaboratively transcribe presentations so anyone can read them alongside the slides. It’ll break up video into short pieces so people can help transcribe in a few minutes’ spare time rather than a big hours-long investment. If the presenter has put their slides online, they’ll be integrated with the text. If you’re a expert with Flash video and want to join in, I could use a hand — otherwise, that part of the app will probably just be very plain, a video with a timeline control at the bottom rather than something specialized for transcription.

If this sounds like a useful site, I’d really appreciate a few minutes of your help late Saturday or early Sunday. Teams can only be 4 people, but I got the OK to allow the public to work on content on the site during the contest so it doesn’t have to launch empty. Just watch this blog (or mail me if you’d like me to remind you) this weekend for the call to come start using the site. Even a few minutes would be a big help.

In the explanation of named routes, there’s a series of examples demonstrating the increasing amounts of syntactic sugar Rails provides:

 
# The most explicit way, before you define the named route:
<%= link_to "Auction for #{h(auction.item.description)}",
    :controller => "auctions",
    :action     => "show",
    :id         => auction.id %>
 
# The first use of the named route, no need to specify controller or action:
<%= link_to "Auction for #{h(auction.item.description)}", auction_path(:id => auction.id) %>
 
# If you just have an :id argument to fill in, you can just pass the value:
<%= link_to "Auction for #{h(auction.item.description)}", auction_path(auction.id) %>
 
# And you could just pass the object and Rails will get its id:
<%= link_to "Auction for #{h(auction.item.description)}", auction_path(auction) %>

In Rails it’s just syntactic sugar, but the underlying mechanism here is type coercion. Instead of thinking of a URL having the type ‘string’, think of it having the type ‘URL’. (Here’s where all the Haskell guys are saying “Uh, it does already.” and rolling their eyes. You already get it, so this post is not for you.) The syntactic sugar is quietly converting an auction object into a url object (or part of one, really).

In Rails you can define a to_param method on your object that’s called by url_for (the method underlying link_to), and the name gives away that you’re converting type like the to_i, to_s, to_f methods you already know from Ruby’s builtin types.

The reverse is less seamless. There is no Model.from_param. Rails’ routing unpacks the URL into variables for the code you write in your controller to find the object(s). In a RESTful style, it seems odd that Rails doesn’t default to doing something like @model_name = Model.find(params[:id]) if you don’t define your own load_object before_filter.

I’ve been thinking a lot about REST lately. The URL of a resource is that resource converted to a URL type. A view presenting an object could be considered converting it to an HTML type. Controllers and actions… I can’t quite see putting them into my models, but they seem much less distinct to me than they did a few hours ago.

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.

By default Rails logs all accesses and errors to production.log, but I decided to save errors to individual files to save the hassle of trying to sift them out of that haystack. I considered logging them to a database table, mailing them, or providing an RSS feed but in the end decided to punt on it. Every added bit of complexity in rescue_error_in_public is another opportunity for something else to go wrong and the error to be lost. It’s easy to write a cron job or other service to pick them up from files and do something useful with them.

Save this file as lib/handle_errors.rb:

 
module ActionController
module Rescue
  def rescue_action_in_public(exception)
    case exception
      when ::ActionController::RoutingError, ::ActionController::UnknownAction
        render_text(IO.read(File.join(RAILS_ROOT, 'public', '404.html')), "404 Not Found")
      else
        render_text(IO.read(File.join(RAILS_ROOT, 'public', '500.html')), "500 Internal Error")
        if defined? ERROR_PATH
          File.open(File.join(ERROR_PATH, Time.now.strftime("exception_%Y-%m-%d_%H:%M:%S_#{rand(99999)}")), 'w') do |file|
            try_printing(file, "request") { file.print "Request to #{request.request_uri} from #{request.remote_ip}nn" }
            try_printing(file, "params") { file.print "Params #{params.to_yaml}nn" }
            try_printing(file, "exception") { file.print(
              "#{exception.class} (#{exception.message}):n    " +
              clean_backtrace(exception).join("n    ") +
              "nn"
            ) }
            try_printing(file, "session") { file.print "Session #{session.to_yaml}nn" }
          end
        end
    end
  end
 
#  def rescue_action_locally(exception)
#    rescue_action_in_public(exception)
#  end
 
  def try_printing file, title
    begin
      yield
    rescue Exception => exception
      file.print "Failed to print #{title}: #{exception.class} (#{exception.message})nn"
    end
  end
end
end

Edit your config/environments.rb to require 'handle_errors' and, in your specific config/environment files, add ERROR_PATH = '/path/to/save'. You can see this working in development by uncommenting the rescue_action_locally.

Security note: If you're dealing with credit cards or other sensitive financial or personal data, you'll want to scrub that from params and session before logging.

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

On Sunday I updated gamers and tags to use ActiveResource. It wasn’t hard, mostly just renames (the ‘view’ action became ‘show’, for example) and removing url_for hashes (:controller => 'gamers', :action => 'view', :handle => @gamer.handle) with much nicer named routes (gamer_path(@gamer)). A gripe I have about ActiveResource is that it has poor URLs, with internal record IDs leaking out. I’ve had nice URLs (/gamers/Harkins and /tags/RPGs) for gamers and tags and I wanted to keep them.

Joshua Schacter gave a presentation on building and growing del.icio.us that included the gems (among many other gems):

• Dont expose your unique id’s to the outside world (php?id=1 etc.) people can scrape through everything very easily. This is why del.icio.us uses MD5 hashes of links instead.
• URLs are prime real estate – respect them

It turns out this is not just possible but easy, though I blew an hour or so finding it (Rails docs still need love). In my Gamer and Tag objects, I just define a to_param method and the URL builder picks it up:

 
class Gamer < ActiveRecord::Base
  def to_param
    self.handle
  end
end
class Tag < ActiveRecord::Base
  def to_param
    self.name
  end
end
 
# and over in config/routes.rb I do the usual:
map.resources :gamers
map.resources :tags, :memger => { :history => :get, :variantes => :get }
# and now gamer_path(@gamer) and tag_path(@tag) work in my views

My controller looks like:

 
class GamersController < ApplicationController
  before_filter :load_gamer, :except => [ :index ]
 
  # The regular index, show, edit, and update actions here
 
  private
  def load_gamer
    @gamer = Gamer.find_by_handle(params[:id], :include => [:location, :tags])
    raise ::ActionController::RoutingError, "Recognition failed for #{request.path}" if @gamer.nil?
    # canonicalize case
    redirect_to gamer_path(@gamer) and return if @gamer.handle != params[:id]
  end

And every action that needs it has the @gamer object loaded from the URL param, with 404 errors handled and mistaken case fixed. There’s a patch that will let you rename the :id parameter. I can’t say I mind if it’s not accepted; I don’t mind calling it :id instead of :handle or :name because I think of it as the public id of the object.

Come back Thursday, I’ll tell you how I made my discussion URLs even more useful.

If you want to get ready now, grab slash_urls.rb and drop it in your lib directory. At the top of your config/routes.rb, add the line:

 
require 'slash_urls'

And now all my URLs on NearbyGamers use slashes instead of semicolons. I only had one or two actions on my ActiveResource routes besides the built-in CRUD, so I’m not worried about doing a 301 redirects.

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.

Rails is growing inwards and upwards, not just outwards. They’re finding better, terser, more Rails-ish ways to express things. They’re not piling on features, they’re condensing. I’ve mentioned that this is what coding in Rails continually feels like: sometimes it just feels off even though it works and is nicer than other languages, and soon I realize a beautiful Right Way to do it.

Where Rails gained new features, the developers have redesigned functionality to make me think, “Wow, of course, that’s obviously much nicer” and it does more because it’s better-designed. Let me give you an example using assert_tag.

I’ve got tests that render pages and make sure they contain certain bits of HTML. One test used to be:

 
assert_tag :tag => "div",
           :attributes => { :id => 'notice' },
           :child => {
             :tag => "div",
             :content => text
           }

And now it reads:

 
assert_select "div#notice > div", text

They rebuilt the assertion to use CSS selectors (with a few clever additions). Suddently the code is simpler, more idiomatic, and more featureful. And that’s just what coding Rails feels like.

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.

For an app I’m working on I actually had to care where a variable comes from, so I dug for a while to find out how to access the raw hashes. It ain’t pretty, but here it is in case anyone else ends up needing it:

 
get = CGIMethods.parse_query_paremeters(@request.query_string)
post = CGIMethods.parse_query_parameters(@request.raw_post) 
# you'd think you could use @request.query_parameters and
# @request.request_parameters, but they're update()d by route vars
route = @request.path_parameters

(Also, don’t ask about this in #rubyonrails — you’ll just get lectured on how you don’t really want to access the hashes, how you should rename all your variables and URLs, and how it simply isn’t possible. This will be very frustrating and totally unproductive.)

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.)