The Mechanical Turk

A business blog may not be the best forum for this, but I don’t have another outlet.

A dear friend from my days at New College, Craig Allen, died on Saturday, 17 November 2007. There will not be a funeral, at the behest of his family.

Craig was an extraordinarily gifted individual, painfully intelligent with an incredibly caustic wit—best when turned on someone else. He greatly enjoyed music & movies, but his dearest loves were his two children, whom he idolised.

He worked as a lawyer for the National Science Foundation investigating fraud & criminal activity. While working there he developed two rare illnesses, neurosarcoidosis & pulmonary sarcoidosis. The struggle against these put an intolerable strain on him & his marriage, more so because he was inaccurately diagnosed for a considerable period of time. While fighting the pain of these illnesses, he became addicted to a cocktail of drugs.

He was fighting his addiction & was trying to pick up the pieces of his life in Florida when he lost his battle. My last message from him was written the day before he died. He was upbeat, more so than I have heard in a long time.

He leaves behind his two children, Gabriel & Jackson. He was 37 years old. He was a dear friend.

Craig Allen (right), in happier days

If you're using response_for, then you might want to grab response_for_resources_controller

It simply replaces the default action modules with ones that use the response_for idiom.

This means that you can override what an action does without overriding how it responds. For example, I want a standard REST controller, that sets a protected attribute, user, on create.

class PostsController < ApplicationController
  resources_controller_for :posts

  def create
    self.resource = new_resource
    resource.user = current_user
    save_resource
  end # the standard response_for :create is used
end

If you don't know what response_for does, it lets you declaratively set the respond_to of an action. For example: if you want to override some aspect of the response, here I just want to change the flash message on successful create:

class LoginsController < ApplicationController
  resources_controller_for :logins

  response_for :create do |format|
    format.html { flash[:notice = "You have logged in" } if resource_saved?
  end
end

miscellany

I added save_resource and resource_saved? to rc, as a way of sharing the result of the save outside the scope of the action. Previously I've done this with valid?, but realised that this might hit the database unnecessarily in some circumstances. You can use either idiom.

If you’re running the newly-released Mac OS X 10.4.11 update & are having lots of crashes in Safari, then the likely culprit is going to be items in your ~/Library/InputManagers/ path. Some popular Input Managers include:

• Application enhancer SIMBL
• Safari enhancer Saft
• X/HTML validator SafariTidy
• TextMate bundle “Edit in TextMate”
• The Safari plugin for the password manager 1Password

SafariTidy was the culprit for me. The developer, Kasper Nauwelaerts, has upgraded this to 0.2.4. I’ve not yet been able to successfully install the update, however—Safari just isn’t recognising its existence.

Input Managers act as a patch to the applications for which they’re intended, and as such are unsupported—even actively discouraged—by Apple, because they can patch applications in dangerous ways. Those of us who rely upon such items—as I am to Safari Tidy, so I can validate my work on-the-fly—are in something of a quandary. As Daring Fireball’s John Gruber implied regarding input managers and unsupported software, this situation isn’t going to get better but worse as time passes.

SafariTidy’s useful validation features: how can it be made a better OS X citizen?

Because the use of the InputManager system is so bad, I’m left wondering what’s the best recourse. Tidy is really useful & there are extensions for Firefox, but none are to my mind as elegant as SafariTidy. I’m left hoping that Kasper will port his plugin to a different architecture…

Update: I just got some tips from Kasper & some very good news:

…You should put [SafariTidy] in the SIMBL plugins folder, which usually resides in ~/Library/Application Support/SIMBL/Plugins/. Please remove all traces in any InputManagers folder you put the bundle, as this plugin isn't technically an InputManager (anymore).

Three cheers for Kasper! I’ll be donating to him right now.

Book cover design is close to my heart—if you’re an avid reader, it’s nice to have a really attractive cover to the book you’re reading. Joseph Sullivan of Book Design Review publishes his favourite book cover designs of 2007.

From his list, my favourites are “Small Crimes in an Age of Abundance” (above, designed by David Drummond), “Six Degrees” (designer unknown), “One Perfect Day” (designed by Evan Gaffney), & “Brave New World” (designed by Greg Kulick). Of course I’m also very fond of “Simple Sentences”, but since I designed it I might be biased!

Super-Special Audio/Triplet Edition!

Spotty Interpol croonster Paul Banks

Largely-forgotten Guns 'n' Roses excrescence
Axl Rose, and

Earsplitting lollapalooza Ethel Merman?

There’s an interesting article in Design Observer about the fairly recent trend in ugly design—nasty colour combinations, stretched type & a lot of other characteristics considered no-nos of good design.

The development of this style—perhaps we should call it “anti-design”, even though its proponents claim it’s the hardest work they’ve ever done—seems to be a reaction to the prevalence of overly-clean (and potentially overly restrictive) design as covered in the documentary Helvetica.

Michael Bierut makes a good point about negative reactions to the design:

If you’re familiar with art and design, you know the perils of condemning the shock of the new. After all, no one wants to risk being one of the bourgoisie sneering at the unveiling of Les Mademoiselles D’Avignon (sic) or booing at the debut of Le Sacre du Printemps.

I’ve always disliked people who try to paint critics with such a brush—it’s a response calculated just to shut you up, not to provoke any debate. But it’s one thing to be provocative in your work & quite another to be heedless to anything that’s actually attractive.

Time will tell whether this new trend—redolent of the early days of PageMaker & Quark design with its “ransom letter” font choice & squeezed typography—will actually last. I can’t help but wonder why we’re caught in this same spiral of reaction & counter-reaction: restrictive design vs. unfettered, even unschooled, design. We’re stuck learning & un-learning the same lessons: we’re fighting old men’s wars. After all, it’d be nice to create something new, wouldn’t it?

Gotta love that warbly voice-over.

I'm pretty sure that I, or at least friends of mine, had at least half of these items when I was an impressionable youth—it all seems so familiar.

But you have to wonder why the humans just keep getting caught. Is this fun?

After a long gestation period, we’re now unveiling the new look—and engine—for the Mechanical Turk.

The look

The basis for the new look is of course our corporate site with a few tweaks. The masthead is based upon the back of our business cards—we are very fond of our bonsai logo.

We also took the opportunity to widen the display from our corporate look—there’s a lot of evidence that shows 1,024 x 768 pixels is now the most common resolution. In due time our corporate site will also reflect this wider presentation—which might be good, because we know the site is a bit text-heavy. Perhaps the change will make this appear less of a problem!

The engine

Previously, we had used the Typo engine for our blog. It’s lightweight & has some nice features, but despite using the most recent release, we found it to be very unstable. For instance, if I discovered, after posting, that I had made a typo (ha ha) & I corrected it, Typo’s lighty processes would eat up all the resources on the server, grinding everything to a halt. After restarting lighty processes four times in a day, we just decided that enough was enough & that we needed to switch.

But to what? If you want to run a blog on Ruby on Rails, it appears that there are three contenders: the aforementioned Typo, SimpleLog & Mephisto. While SimpleLog looks really nice, it appears that it does not have a big developer community. Mephisto does, even though there are a few worries about its future development. Apparently there is now a core team for Mephisto, so perhaps it’s got a new lease on life. Time will tell. In the meantime, Ian has tinkered under Mephisto’s hood & when he has a moment (ha ha, aren’t we funny?), perhaps he’ll write a bit about what he’s done. We are considering releasing some Mephisto plugins as well—again, in time.

The name?

As noted in the comments to my second post on the blog, we are considering a new name. We’re coming around to a name revolving around “falling leaves”—suggested by the image of the bonsai on the masthead. It’s also somewhat evocative of the nature of blog posts—posts fall when they’re ready and… OK, I’ll shut up already.

Finally, I’d like to publicly thank Ian for taking time out of his horrendously busy schedule to help get the new blog engine running so smoothly.

We have a client that is part of a large institution (both shall remain nameless to protect them). Like many in such cases, they’ve had a CMS thrust upon them. I won’t name the CMS, but you might be able to figure it out from this screenshot:

Behold in all its horror!

Look at this from a user’s perspective. OK, we’ve got a nested system of some sort. What are the radio buttons for? We can also delete “publication details” (notice the wastebasket at the right). Below the wastebasket is a tickbox. What does it do? And do you dare click it? How about the “temporary save” button—why is this not automatic, as in online apps such as GMail & Basecamp?

Let’s look at another example:

“Once more”? “Switch”? WTF?

This second screenshot comes from further down the page, from a list of publications. Clicking the “Switch” button lets you move the publication up or down the list; when you do this, the page reloads. It would reload every time you moved the position of the item (average page refresh time: 30 seconds).

Now imagine that you’re re-organising a list of, say, 20 publications so that the most recent publications come first in the list—a not uncommon task. Imagine that, previously, the publications were listed in order of publications (i.e., that the oldest one was first). To just move the latest publication, you’d have the page refresh 20 times. After each refresh, you’d have to scroll down the page to find the publication again so you could move it up one more position. Imagine that you have to re-order several pages’ worth of publications: now do it a million times!

After doing this for a couple of hours, finally imagine saying “Fuck it, it’s not worth the effort”. You have now reached the position of my client—and, indeed, the position of many people who have had CMSs thrust upon them.

A lot of things have gone wrong here. At my bitchiest I’d say that these screenshots showed the unholy marriage of Windows 1.0-style software design with all the flair of a Linux user interface. How did it come to this? Why was this software chosen? How do you get out of this situation?

I don’t have an answer to that last question, unfortunately—large institutions make their decisions on behalf of all departments & it takes years to move such a big ship. But I know how others can avoid this.

Let’s gain some perspective: CMSs became a big thing before the dot-com bubble burst in the early 2000s. They were designed for the browsers of the day—Internet Explorer 4 & 5, perhaps even Netscape 4. Any web developer will tell you that these browsers are pretty limited—and that support of legacy browsers quickly reduces the options you have to design an intuitive interface, progressive enhancement techniques notwithstanding. So, CMSs were designed in an era when you couldn’t have asynchronously-updatable data on a page—yes, we’re talking AJAX here. In other words, many CMSs come from a less technologically-advanced world.

Mixed in with this is the glacier-like pace of large organisations in their technological adoption. Years ago I worked for a university & saw first-hand why the technological decision-making process took years: often for legitimate reasons. For example, if you are running a corporation with 10,000 computers, it takes a long time to produce all the tests necessary to ensure that you’re not going to bring down the entire corporate system in your enthusiasm to adopt new technology. Accordingly, many corporations start looking at tech products & it can take years for them to reach their decisions. (NB: many corporations are a lot better at making swifter decisions now, but it’s a rare academic institution that has matched this quicker pace.)

So let’s recap: many CMSs were originally built in a time when dinosaurs walked the earth & this is when large corporations might have begun eyeballing their products. Years go by, the corporation makes its (now dodgy) choice & then the corporations’ employees are stuck with the result for years to come—perhaps simply to justify a decision that cost millions of pounds even when that decision clearly was a bad one.

A major part of the problem is the decision-making process: after a certain cut-off point, no other options may be admitted. This is unfortunate (to say the least) because in the meantime blogging software has emerged not just as a niche player but as a robust solution—which solves many of the problems that CMSs were supposed to tackle. Publication control & template-based “unified” branding cross-site are allied with a significantly better interface. Moreover, many blogs allow for “static” pages (in this context, pages note defined by the date of the post but by their content). And while blogs may not automatically provide all the semantics required for, say, publications, most blogging software allows you to delve into markup to address specific concerns—or have plugins that would address the concern—or (as a last resort), you can tag content according to its semantic meaning. It’s a very good solution that solves 90% of the problems which CMSs were to address.

Now this doesn’t leave our clients in a good place—they still have to use a terrible CMS. My question is: why hasn’t the CMS vendor updated the working of its CMS? At the very least AJAX-based tools to move publications (as in the example way above) would ease so much of the pain. A less charitable person than myself would conclude that they don’t care that their software is so broken, so there is little impetus to fix it. A more charitable conclusion would be that they don’t realise that the software is broken. Perhaps when clients don’t renew their licenses they’ll wake up.

If you've ever subclassed a controller to deal with a particular MIME type, say FBML, you will have had the painful experience of having to copy and paste all of your contoller's actions, adding, or replacing the fbml blocks into the code.

This doesn't feel right - and it isn't. If you have to change some controller logic - you have to remember to change it in all these subclassed controllers.

Enter response_for (rdoc here).

response_for lets you declaratively specify how your actions should respond to particular Mime types. This helps particularly when your action's logic is not simple (like a CRUD action - but it still helps there). Here's an example I just made up:

class ReportController < ApplicationController
  # this puppy gets some models to collaborate to form a report
  def report
    @report = {}
    @report[:invoiced] = Customer.find_invoiced
    @report[:outstanding] = @report[:invoiced].select {|c| c.latest_invoice.outstanding? }
      
    respond_to do |format|
      format.html 
      format.xml { # some funky xml stuff here }
    end
  end
end

Let's say I wanted to make FBML responding version of this controller, normally, I'd have to copy/paste this action and add the fbml responses. With response_for, I do this:

  class FacebookReportController < ReportController
  response_for :report do |format|
    format.fbml { # my funky fbml stuff here, accessing @report}
  end
end

So, down the line, if I change the way my @report object is generated, I don't have to change my subclassed controllers.

Another example: create

You can choose to replace the respond_to block of the action as well. This means that common actions can be written, and the response can be adjusted according to your needs (resources_controller comes to mind).

Here's a standard create action:

class ForumsController < ApplicationController
  def create
    @forum = Forum.new(params[:forum])
    @forum.save
      
    respond_to do |format|
      if @forum.valid?
        flash[:notice] = 'Forum was successfully created.'
        format.html { redirect_to(@forum) }
        format.xml  { render :xml => @forum, :status => :created, :location => @forum }
      else
        format.html { render :action => "new" }
        format.xml  { render :xml => @forum.errors, :status => :unprocessable_entity }
      end
    end
  end
end

Let's say you want to create an FBML only version of this:

class FacebookForumsController < ForumsController
  response_for :create, :replace => true do |format|
    if @forum.valid?
      format.fbml { # funky fbml stuff for valid record }
    else
      format.fbml { # and for an invalid record}
    end
  end
end

One last example

For many actions, you just want to tell your action to respond to particular MIME type and a template does the rest:

class FacebookUsersController < UsersController
  response_for :index, :show, :types => [:fbml]
  end

You don't need to have a respond_to block defined in your actions - the parent controller could look like:

class UsersController < ApplicationController
  def index
    @users = User.find :all
  end
  
  def show
    @user = User.find params[:id]
  end
end

resources_controller + response_for

For those users of resources_controller, response_for gives you an easy way of adding responses on an ad-hoc basis (like if only one or two of your actions need to be RSS feeds or summat)

This is the first release...

and I welcome any bug reports

Steve Ballmer, chair-throwing CEO of Microsoft and

The Creature from Mel Brooks’
“Young Frankenstein”?

Update: Well, this is turning into something of a meme. One of the comments in the Fake Steve Jobs blog has a link to this awesome video:

I am very impressed.

Jason Lee of Big First Name just posted his experiences of using resources_controller on the google group.

He writes:

I've just converted one my existing apps ( http://big.first.name ) to using the resources_controller plugin and thought I'd share some results with the group...
before RC, the output of "rake stats"...

+---------------+-------+-------+---------+---------
| Name          | Lines | LOC   | Classes | Methods 
| Controllers   |  1785 |  1324 |      20 |     112 

after RC conversion (with only minor refactoring)...

+---------------+-------+-------+---------+---------
| Name          | Lines | LOC   | Classes | Methods 
| Controllers   |   877 |   655 |      20 |      45

That's 50% less code and 60% less methods. I've still got some chunky controller code lying around but overall I'm very happy with the result.

That's cool!

I gave a talk about resources_controller at LRUG which was great fun.

Thanks to everyone for listening and for the feedback. Skills Matter are apparently going to post a video of the presentation at some point. In the meantime, the slides are here.

I've been chatting to a few people at RailsConfEuropoe about resources_controller, so I thought I'd say a few words about waht it's key features are, and about RC at RailsConfEuropoe in general.

Key features

There's a few plugins out there that try and solve the same sort of problem - DRY up RESTful controllers. I believe that RC's standout features can be seen when considering how to write controller for a polymorhpic has_many relationship.

Polymorphic Tags

So you want to tag a bunch of models, and so you sure the :polymorphic has_many assoc, and make a Tag model with belongs_to :taggable, :polymorphic => true.

You want tags to be nested under a bunch of different resources like this:

  map.resources :users do |user|
   user.resources :tags, :controller => 'user_tags'
  end

  map.resources :posts do |post|
   post.resources :tags, :controller => 'post_tags'
  end

Standardly, you'd then have to write two controllers: UserTagsController, and PostTagsController, and map the above two nested routes to those different controllers. These would be essentially the same functionality except:

• they would load different models in before filters: @user in one and @post in the other,
• they get the post from different collections (@tag = @user.tags.find(params[:tags_id]) vs @tag = @post.tags.find(params[:tags_id])),
• they redirect to different routes on completion of certain actions user_tags_path and post_tags_path in the other.

To do this, even with plugins to dry everything up, you still need to create two (or three, or four) controllers for tags - all doing essentially the same thing.

it gets worse. You'll need a bunch of different views - because they all need to link to urls relative to the enclosing resource. Suddenly you've got a lot of really similar code - or some really ungly hacks in your views.

(and all of this gets much worse if you have deeply nested routes)

Polymorphic tags with resources_controller

resources_controller (used in the default way) inspects the route that was used to invoke the controller. From this, it:

• loads all of the enclosing resources,
• uses the immediately enclosing resource as the resource service (the object that we send find and new to to - in the case of /posts it would be the Post class, in the case of /post/1/tags it would be the @post.tags association),
• does some method missing magic so that you can refer to all named routes relative to the current resource

All this means you just need to write one controller, and one set of views for Tags

Here's some sample code

  class TagsController < ApplicationCntroller
    resources_controller_for :tags
  end

in show.html.erb:

  <%= link_to 'tags', resources_path %>

The above will be user_tags_path(@user) in one case and post_tags_path(@post) in another.

It gets better, you can refer to the enclosing resource as well:

  <%= link_to "back to #{enclosing_resource_name.humanize}", enclosing_resource_path %>

And if you have routes like /users/1/posts/2/tags, and /posts/1/tags, the you can use the same view for posts:

  <%= link_to 'tags', resource_tags_path %> # in /users/1/posts/2/tags will be:
                                            # user_post_tags_path(@user, @post)
                                            
  <%= link_to 'tags', resource_tags_path %> # in /posts/2/tags will be:
                                            # post_tags_path(@post)

That's just some of the features, I'd love to get feedback, patches, bug reports, etc. There are links to RC via svn, and rdoc on our plugins page

BoF and RejectConf

Man, I've got a lot to learn about presentations...

I gave a BoF at RailsConfEurope07 session on resources_controller - I was expecting about 10 people and a round table discussion on taking the pain out of RESTful controllers. About 50 or 60 people turned up so we ended up all crowded round a couple of laptops. But everyone was friendly and there was no heckling. Paolo, who gave the incredibly entertaining talk on widgets, took some photos

There was, however, plenty of heckling at the RejectConf talk. The format was 5 minutes of slides, 20 seconds automatic countdown for each one. I wrote the presentation during the day, and ran through it with my wife before hand. It sucked - way too much info. So I cut it down.

However, I was first up, and gave the audience the choice of the insane, or sane, talk, and they chose insane. I tried to get across about 1/2 an hour's worth of stuff in 5 minutes, and the audience looked as though they were in a wind tunnel. It was a great icebreaker for the other speakers though. I'll post the slides here in due course.

RejectConf was simply awesome by the way. The berlin ruby user group rocks.

It’s hardly a controversial position, but I don’t like spam. I really hate it, actually. Past email addresses eventually got so clogged that I had shut shut them down & create news just to regain sanity in my life. This approach is perhaps best called the “Slash and Burn” method.

But… you can’t deny that spam has come up with some wonderful things. Well, specifically, one: the spurious names that are appended to the “from” header. They consist of a combination of a couple of words taken randomly from the dictionary & a “middle initial”, all intended to bypass your spam filters. These random couplings sometimes beget glorious results:

• Double O Tedious (Irish, perhaps?)
• Urinate G. Coordinator (this almost sounds like a job title)
• Omens H. Absolutism
• Gunshots I. Senatorial (I’ve received this one many times over the years—perhaps these aren’t as random as I thought)
• Religiously H. Panacea (interesting combination there)
• Stultifies H. Putrescence
• Chuvash B. Residue
• Powering H. Kahlua (for the adolescent alcoholic)