something learned

Ack.tmbundle: a faster "Find in Project" for TextMate

Tue, 3 Jun 2008 15:19:39 EDT

Recently one of my ENTP colleagues switched me on to ack as an excellent replacement for find+grep. Being a dyed in the wool TextMate user, the first thing that popped into my head was “I need an ‘Ack in Project’ TextMate plugin”.

Unfortunately the only advertised plugin I could find was 404’ing on me. Did I do the simple thing and notify the author about the dead link? Nope. I wrote my own plugin instead.

In hindsight I have to ask… what on earth was I thinking?

Whatever. I wrote the plugin and (if I do say so myself) it’s pretty damn good.

Here’s some installation instructions for getting it from my github repository:


cd ~/Library/Application\ Support/TextMate/Bundles
git clone git://github.com/protocool/ack-tmbundle.git Ack.tmbundle

I’ve also thrown together a little (silent and slightly crappy) screencast showing it in action.

Enjoy.

Edit:

I’ve updated the wiki to include some information on getting ack to recognize new file types using Henrik’s haml comment as an example.

Giant Robots Giving Me Flashbacks.

Mon, 7 Jan 2008 18:00:12 EST

This morning I checked my feed reader and was instantly transported back to 1992, when I was working for a small independent software vendor.

So please indulge me while I tell you a little bit about the company, what I learned, and what brought it all rushing back.

The (un-named) Company

At its peak I believe there were close to 200 people actively developing, porting and translating the company’s software. The remaining 300 people (including me) did support, sales and training.

The product itself was enormous and ran on hundreds of versions and flavors of Unix. In fact, the company was so good at development and porting that they often entertained visitors from other independent software vendors who were desperate to learn how to do it well.

Even though my job allowed me to do some development and customization work, my primary role was a post-sales support engineer. I was desperate to be a ‘proper’ software developer so I enthusiastically attended any “brown bag lunch” talks that had to do with core product development.

Two of those talks, given one week after the other, are still fresh in my mind 15 years later.

Week 1

The first was a talk given by the company’s Chief Architect on the topic of “Object Orientation and C++”.

Now, I had no formal development training and this was my first ‘real’ industry job so I have no idea how popular “Object Orientation” was at the time for the industry as a whole. Of course, today it’s pedestrian. But at the time, in that room, it was revolutionary.

Inheritance, public, private… my head was spinning. It wasn’t just a new syntax, it was a different way of approaching the problem.

In my beginner’s mind, there was just no contest between K&R C and C++. I instinctively understood object-oriented code – it was virtually self-documenting.

This talk was very well received and I can remember ranting to a colleague: “It just makes sense! If you want to talk to a printer you just create a Printer object. Here’s the functions you can call, here’s the stuff you can’t touch.”

Week 2

The very next week, the lead software developer for the company gave a talk on “Object Orientation, C++ and [Company Name]”.

Boy was I stoked. I expected to learn about how the propellerheads were going to retool everything (back then I didn’t know how frightful that idea is) for C++.

The talk was shocking and confusing. For a solid hour he ripped into the ideas that had been presented in the previous week, knocking them down one by one.

I can paraphrase his talk like this:

There is nothing that C++ offers that well-written K&R C doesn’t offer.

If you name your structs, variables and methods correctly then your intentions will be communicated just as effectively as using C++ syntax.

If you want to bind functions to data then put function pointers in structs.

Any programmer worth his salt will have a solid set of practices for software development based on K&R C and there is no point moving to a new language for features that you either don’t need or already have available.

Move along, nothing to see here.

He didn’t say “it’s not a good fit for this company”, or “yeah, we should look at in more depth when C++ is more pervasive”. He said “it simply has no merit”.

This talk was also very well received and again I can remember ranting to a colleage: “What is wrong with these guys? Can’t they see how much simpler Object Orientation is?”

Week N

A few years later the company did move to C++ for a completely new generation of their main product offering.

They attempted the “big rewrite”, expecting to recapture the features and lessons learned from years of work on a mature codebase and reproduce it in C++ (with a six month deadline).

I’ll never know whether they would have survived the schedule slippages and cost overruns on that project. They bet the farm on Unix and almost overnight they lost their market, and all prospect for growth, to Microsoft Windows and Office.

By 2000 most of the company’s assets had been sold off and the only mention of [Company Name] on the web was someone offering support contracts for the now-dead software.

A Little Perspective a Lot of Years Later

Aside from getting to witness first-hand the dangers of “the big rewrite” very early in my career, the most indelible marks were left by those talks back in 1992 and by the efforts to knock down C++ and “Object Orientation”.

It took me a long time to understand the negative reaction.

It would be a disservice to say that the lead developer “just didn’t get it”. He was a gifted developer, able to slice through tricky problems like butter. I admired his code for its clarity and succinctness and I read as much of it as I could. When I did, I always learned something valuable.

So why did I, a complete newb with hardly any experience at all, see something beautiful in Object Orientation, while he could not?

Because I was a complete newb, with hardly any experience at all – that’s why. Writing code was a struggle for me and I had to work hard to translate my mental-models into code. Anything that made that easier was a godsend.

The lead developer, on the other hand, was fully tooled-up. Expressing his intentions in code was simple and natural in K&R C. He didn’t need any new language constructs or syntax to help him conceptualize solutions. I can understand why he felt that C++ had nothing new to offer him.

But I think on the day he gave his talk he missed something important. It’s all just syntax and language constructs. Whether you can do something with tool X or language Y doesn’t address whether it’s natural to do so.

Saying “there is nothing that C++ offers that well-written K&R C doesn’t offer” isn’t the point. Sure you can put pointers to functions in a struct, but how much more natural does it feel to just define a method for an object? When you’re staring at a blank screen and about to start coding, does the syntax implicitly nudge you in the right general direction?

If you were a beginner, would this new syntax seem natural to you? Would it speak to you?

Even with 15 years of hindsight I’m not sure I know how I would have convinced him to disregard his hard-won K&R skills and techniques and to evaluate “Object Orientation” and C++ with a beginner’s mind.

I think I struggle with it because he was right to reject C++ for the company at that time, but the reasons he gave (that you could achieve the same thing in K&R C) were wrong.

So why the flashback today?

Over on the Giant Robots blog there is a discussion going on about BDD. It’s entitled “Not Worth It”. The names may have changed but it’s the same debate I witnessed in 1992.

And all I can think to do, when presented with guys that are fully tooled-up with TDD and Test::Unit skills and just see BDD and RSpec as (paraphrasing) “just another syntax to achieve the same results” is to say “let me tell you about a couple of ‘brown bag lunch’ talks I attended back when I first started out”.

What's new (and disappointing) in edge-rails

Thu, 7 Jun 2007 01:24:56 EDT

Recently a changeset (6591) made its way into Rails’ trunk. A few people are blogging about how cool it is but I’m going to blog about why it’s bad.

So I tied an onion on my belt…

It actually all started with an earlier changeset (6588) which, in my opinion, made url helpers for nested resources just a twinge uglier. What 6588 does is clean up syntax in routes.rb:

# Before 6588
map.resources :houses do |house|
  house.resources :walls
end

# After 6588   
map.resources :houses, :has_many => :walls

No argument here – that’s a great idea. However, such a change poses a problem with polymorphic resources. For the uninitiated, the term “polymorphic resource” generally refers to a resource that appears in multiple routes.

When you re-use the same resource in multiple routes you have to disambiguate the url helpers using a :name_prefix argument.

# Before 6588
map.resources :houses do |house|
  house.resources :walls, :name_prefix => 'house_'
end

map.resources :outbuildings do |outbuilding|
  outbuilding.resources :walls, :name_prefix => 'outbuilding_'
end

So now you can call either house_wall_path(@house, @wall) or outbuilding_wall_path(@outbuilding, @wall).

Unfortunately there’s no easy way to get the shiny new :has_many syntax in routes.rb while still expressing the name_prefix. Changeset 6588 solves that by introducing some extra behavior.

Now, all your nested routes are automatically disambiguated with an implicit :name_prefix (unless you override it using the old-style block syntax and set :name_prefix to nil). Leaving you with:

# After 6588   
map.resources :houses, :has_many => :walls
map.resources :outbuildings, :has_many => :walls

Polymorphic goodness right? No, as it happens.

... as was the fashion at the time.

The problem here is that auto-name_prefix is imposing a rather significant tax.

For now let’s (conveniently) ignore the possibility of polymorphic resources. After all, I know that I have far fewer polymorphic resources in my routes.rb than I have simple plain-jane nested resources – I suspect that’s true for a lot of people.

Returning to the original example:

# Before 6588
map.resources :houses do |house|
  house.resources :walls
end
# wall_path(@house, @wall) #=> /houses/5/walls/6

# After 6588   
map.resources :houses, :has_many => :walls
# house_wall_path(@house, @wall) #=> /houses/5/walls/6

Did you see how the url helper for my wall just got longer? Maybe I’m the exception but I spend a lot more time typing out url helpers than I do typing out routes. And because I have far more non-polymorphic resources than polymorphic ones, I don’t need all this automatic url helper disambiguation.

The implicit :name_prefix is just adding cruft to plain old nested resources.

Now, to take the ferry cost a nickel…

It’s around about now that the resources should never be nested more than 1 level deep cargo-cult will see how I’m passing both @house and @wall in my arguments and start to get itchy trigger fingers.

Personally I think it’s a shame that “the amount of nesting you need is proportional to the ideas you’re expressing” isn’t nearly as catchy as “never more than 1 level deep” but there you go.

But what’s interesting is that the “1-layer” folks are doing something that looks like a polymorphic resource (the relationship being modeled isn’t polymorphic, the controller is just being re-used). Assume we just have :houses (and no :outbuildings):

# 1-layer person says:
map.resources :houses, :has_many => :walls
map.resources :walls, :has_many => :windows
map.resources :windows

# instead of just:
map.resources :houses do |house|
  house.resources :walls, :has_many => :windows
end

All of a sudden the url helpers for :walls and :windows need to be disambiguated.

From what I can tell, the benefits for the “1-layer” folks are a) shorter urls (regardless of how expressive they are?) and b) they avoid having to supply ‘parents’ in the arguments for the deeply nested url helpers.

And while I can’t help with short urls, some time ago I created a plugin from which I created a patch that makes a deeply-nested window_path(@house, @wall, @window) callable as window_path(@window). No need to explicitly supply parents, they will be inferred if you choose not to supply them.

By the way, if you think the above “1-layer” style is just fine, consider that a logged-in user only has permission to view or edit the data for their associated houses. So User.has_many :houses. What does the code look like in windows_controller.rb when ensuring the user should be looking at window 13 for example?

See, I’m not blindly a “1-layer” guy so I’d always have the house_id in the url – and my controllers would just do a current_user.houses.find(params[:house_id]). Pretty straight-forward in my opinion.

and in those days, nickels had pictures of bumblebees on ‘em…

So back to yesterday’s changeset (6591). This changes the guts of Rails’ polymorphic_url() method in ways that, on the surface, look pretty cool.

Again, for the uninitiated, polymorphic_url() is a method that used to be part of the simply_helpful plugin and has recently been factored into Rails’ trunk.

The reason why polymorphic_url() is cool is because it decides what url helper to invoke based on the class of the argument you pass and in the case of ActiveRecord objects, whether the object is a new_record? or not.

By the way, polymorphic_url() isn’t really about polymorphic resources, it’s more about “I have an object, call the relevant url helper please”.

polymorphic_url Something.new #=> somethings_path() #=> /somethings
polymorphic_url Something.find(:first) #=> something_path(your_first_record) #=> /somethings/1

Layered on top of that behavior, are url_for() and form_for(). The form_for() helper is especially handy because it will either use :get or :post as the method for your form depending on whether the object is a new_record? or not.

Now you can use just one form for your new and existing records.

form_for Something.new #=> /somethings, :method => :post
form_for Something.find(1) #=> /somethings/1, :method => :put

All very cool. What’s the problem then?

‘Give me five bees for a quarter,’ you’d say.

The problem is that deep in the bowels of polymorphic_url a new feature has arrived with changeset 6591. Now you can pass an array to form_for (you couldn’t before) to signify that you have a nested object. Under the hood, polymorphic_url will call the correct url helper according to current Rails convention.

# routes.rb
map.resources :houses, :has_many => :walls

# In a view:
form_for [@house, Wall.new] #=> house_walls_path(), :method => :post
form_for [@house, Wall.find(1) #=> house_wall_path(1), :method => :put

Again, in isolation that looks fine but note that it assumes the implicit :name_prefix values for my url helper names which, as I’ve already stated, are just noise when you’re not dealing with polymorphic resources.

So if I want to use form_for (specifically to have the benefit of the new_record? checking) while passing the parents as arguments, I have no choice but to use the name-prefixed form of url helpers – and that affects me whenever I just need a url.

Or I could take the stance that others are taking:

”Yeah, url helpers sure got ugly because of the auto-name_prefix thing but now just call url_for([@house, @wall]) and it’s much clearer”

Except it’s not.

It’s opaque.
And it’s incomplete (how about a url to preview a new record?).
And the interface has that leaky bolted-on feeling (wrapping your objects in an Array to overcome the method signature of url_for? That’s cheap).
Did I mention opaque?

Now where were we? Oh yeah…

What we have is a situation where truly-polymorphic resources (where the resource can have different parent types), of which I personally have comparatively few, and pseudo-polymorphic resources (as created by the “1-layer” folks), of which I have even fewer, are making life harder for non-polymorphic nested resources.

Perhaps I’m in the minority but I believe the auto-name_prefix feature that was introduced in 6588 should be killed-off before any more leaky layers are added on top of it.

And polymorphic resources should be treated as an edge-case. It should be “if you need it, put in the work” rather than “if you don’t need it, put in the work”.

Prior to changeset 6588, url helpers were clearer, simpler, and involved fewer keystrokes for the vast majority of cases.

The important thing was that I had an onion on my belt

Finally, if you do need polymorphic resources, your clue is in the name.

POLYMORPHIC. Using a monomorph (the same controller) to model something polymorphic seems a little bone-headed don’t you think?

The caboose sample app (blog entry) has an example of how I believe you should model polymorphic resources. resource_fu wires it all together but it has moved on a bit since then (and still lacks full documentation) so the sample-app is a bit out-of-date. When I get time I’ll correct both of those issues.

How To: Uncountable Names in RESTful Routes

Mon, 19 Mar 2007 00:03:23 EST

A couple of times I’ve noticed people saying that uncountable names (like sheep and fish) can’t be used with resource routes in Rails. Well, they can.

# in config/routes.rb
map.resources :fish

In the above example there is a conflict between the generated url helpers for the ‘fish’ collection and the generated url helpers for members of the ‘fish’ collection. Because ‘fish’ is uncountable, both are called fish_path or fish_url. And because of the way routes and url helpers are created in a map.resources call, the member url helpers override the collection ones.

So using the above example, calling fish_path() raises an error like:

ActionController::RoutingError: fish_url failed to generate from {:controller=>"fish", :action=>"show"} - you may have ambiguous routes, or you may need to supply additional parameters for this route. content_url has the following required parameters: ["fish", :id] - are they all satisifed?

Thankfully that’s not the end of it. You just have to add a :singular argument when defining your resources:

# in config/routes.rb
map.resources :fish, :singular => :fish_instance

# in your code
fish_path() #=> /fish
new_fish_instance_path() #=> /fish/new
fish_instance_path(1) #=> /fish/1
edit_fish_instance_path(1) #=> /fish/1;edit

That’s all.

New Plugin: xls_fixtures

Tue, 17 Oct 2006 13:54:46 EDT

Here’s a little something I whipped up that’s proved useful.

Yaml is a pretty good format for storing fixture data but it can be a real pain to set up a bunch of fixtures with repeating or incrementing data. There’s a much better tool out there for that – Excel.

One way you can ease the pain of generating reams of fixture data is to build it all up in Excel and export your spreadsheets as csv files and tell Rails to use csv fixtures. Unfortunately I couldn’t find a way to have a moniker (my name for the non-indented line in your yaml fixtures) in the csv files so that I could refer to fixtures by name in my tests.

So what I’ve done is to write a little plugin and rake task that converts xls files into yaml fixtures. See:

http://svn.protocool.com/public/plugins/trunk/xls_fixtures/

Note that it requires the ‘parseexcel’ gem (as in “gem install parseexcel”) and you need to arrange your rows and columns as per the README file in the plugin.

Pastie: It's "italics good"

Tue, 25 Jul 2006 13:25:42 EDT

You come across interesting stuff by browsing pastie but this tops them all.

http://pastie.caboo.se/5900/wrap

A little (more) syntactic sugar in Rails

Mon, 12 Jun 2006 13:48:56 EDT

This little extension to Ruby’s Array class is making the rounds:


class Array
  def sum
    inject(0) { |m, v| m + v }
  end
end

# Use it thusly:
[1,2,3,4,5].sum # => 15

Nice. But what if we want to sum a member of each array element, such as the ‘price_cents’ attribute on a bunch of ActiveRecord objects?


@order.line_items.collect {|x| x.price_cents}.sum
# or (my preference) using Symbol's to_proc method:
@order.line_items.collect(&:price_cents).sum

Even with the sugar that Symbol#to_proc adds, it’s just a bit… well, blech. We can do better:


class Array
  def sum
    if block_given?
      inject(0) { |m, v| m + yield(v) }
    else
      inject(0) { |m, v| m + v }
    end
  end
end

# Now we can say:
@order.line_items.sum(&:price_cents)

That’s just so much clearer.

Update: a recent changeset in the rails trunk adds a ‘sum’ method to Enumerable. It’s different from what I present above in that it only works with a block – which is okay for me because that’s my main usage pattern anyhow.

A Rails tale of caution: functional tests hanging with controllers in subdirectories

Tue, 30 May 2006 19:27:05 EDT

This afternoon I was hit by a real headscratcher – documented here for future googlers looking for information on: functional tests hanging controllers subdirectories :-)

I added in some tests for controllers that were in a subdirectory (as in “./script/generate controller boo/hoo“) and suddenly rake started hanging.

I could run individual functional tests just fine but as a suite – forget it.

The source of the problem turned out to be twofold:

in test_helper.rb we alias the get and post test methods so that we can optionally capture all of our output and run it through a validator.
the require line that ./script/generate creates for loading test_helper.rb in your functional tests is relative to the current file’s directory. For functional tests in subdirectories you get a require argument ending with ”/../../test_helper” rather than the one ending with ”/../test_helper” as you do in top-level functional tests.

Even though those two different require lines point to the same file, from require’s perspective they are different – so the file is loaded twice.

And that’s a big no-no if you are doing a simple method alias without checks against doing it twice.

The bulletproof solution is to have tests use File.expand_path() on the argument to require. But if the generators keep spitting it out as they do now it’s one of those “pushing water uphill” situations. I smell a patch.

For now, I’m just wrapping my alias calls with a check of self.instance_methods to make sure the alias hasn’t already been done.

Living under a rock? Google and Sketchup

Sun, 28 May 2006 21:16:40 EDT

A few years back, while I was building my house, I downloaded a demo copy of Sketchup to help visualize how everything would look. It’s a fantastic tool for 3D design, one of those rare pieces of software that just makes sense.

Unfortunately it’s also software that costs about $500 USD and as much as I wanted to, I simply couldn’t justify the expense. My love affair with Sketchup was doomed to be just a few short weeks as the demo period quickly slipped away.

Sketchup did leave me with a legacy though: Ruby. It ships with a ruby interpreter and has hooks to extend the software with Ruby scripts. Had I not seen the Ruby/Sketchup integration I probably wouldn’t have given Rails a second look when I stumbled across it a year and a half (gosh!) ago.

Okay, that’s enough nostalgia. The real point here isn’t whether I owe a debt of gratitude to a 3D modeling program for more than a year of fun, full-time work with Rails…

The real point here is that Google bought Sketchup and they are releasing cut-down free versions. I think that’s pretty big news and I have absolutely no idea how I missed it.

They’ve already released the free version for PC and apparently a free version for OS X is in the works as well.

I am so chuffed about this. It’s going to make designing my kids’ backyard playstructure a breeze.

Snippet: using 'inherited' to set filters in controllers

Fri, 26 May 2006 18:51:37 EDT

One of my apps has a set of controllers in an ’/admin’ directory. They all must have a :login_required before_filter and they all must define an authorized? method that checks if the current user is an administrator.

For a couple of reasons the idea of having a special “AdminController” which everything under ’/admin’ would inherit from (and that set up the filter and authorized? method) kind of irked me.

First, there was the name clash – AdminController becomes ‘admin’ in routes and that clashes with my directory called ‘admin’, so I’d have to choose a name like “AdminBaseController” or some-such. Blech.

Second, I just didn’t like the extra file for the base controller. Call me picky, I can take it.

What I wanted was a way to say “if the controller is in the /admin directory then it needs this filter and this method”.

Class#inherited to the rescue. Here’s what I put in /app/controllers/application.rb:

# For all controllers in the 'Admin' namespace we set
# the login_required before_filter and define an authorized?
# method that checks user.is_administrator? 
def self.inherited(subclass)
  # call super first - otherwise any before_filters we add are lost
  super
  if subclass.name.split('::').first == 'Admin'
    subclass.before_filter :login_required
    subclass.send(:define_method, :authorized?, Proc.new {|user| user.is_administrator?})
    subclass.send(:protected, :authorized?)
  end
end

This is fine for my present needs. If controllers under /admin start to need any more shared behavior I’ll just bite the bullet and do the AdminBaseController thing – but for now this is clean and works.