has_many :through

Shifting to the client again

2012-03-15T16:33:00-07:00

This is my take on the current shift to rich, in-browser JavaScript apps.

Looking back over a few decades, this is the progression of how applications have been built:

mainframes and dumb terminals
minicomputers and smart terminals
networked workstations
workstations and shared code/data repositories
web apps and static HTML
web services and rich browser apps

Translation: The main body of the application code lives on the:

server
server + client
client
server + client
server
server + client

The server/client pendulum swings back and forth. The next logical step is apps that run on the client using standard services. Just give it a few more years...

Modularized Association Methods in Rails 3.2

2012-01-20T11:03:07-08:00

Happy Friday! It's Rails 3.2 day! The official release announcement mentions a few of the big changes, but I'd like to take a moment to highlight a relatively small change I was responsible for, one that I hope may make your life a little easier.

From the ActiveRecord CHANGELOG:

Generated association methods are created within a separate module to allow overriding and
composition using `super`. For a class named `MyModel`, the module is named
`MyModel::GeneratedFeatureMethods`. It is included into the model class immediately after
the `generated_attributes_methods` module defined in ActiveModel, so association methods
override attribute methods of the same name. *Josh Susser*

The point of this change is to allow more flexibility in working with associations in your model classes. When you define an association, ActiveRecord automagically generates some methods for you to work with the association. For example, a has_many :patches association generates the methods patches and patches= (and a few others).

Previously, those association methods were inserted directly into your model class. This change moves those methods into their own module which is then included in your model class. Your model gets the same methods through inheritance, but also gets to override those methods and still call them using super. Let's take a look at two ways this makes things easier for you.

Sometimes you want to replace the standard generated association methods. That's always been easy to do simply by defining new methods in your model class. The only wrinkle was that you had to make sure you defined your method after you set up the association, or calling has_many would overwrite your method, since last writer wins. That was usually not a problem, but sometimes plugins or other monkey patching extensions could add an association after your model's class was defined, which wouldn't give you a chance to add your method afterwards. With this change, you don't have to worry about those order dependencies anymore. Since those methods are generated in their own module, the order doesn't matter. This is a pretty small issue all told and I doubt it affected many people, but it's still worth mentioning.

The real reason for this change is being able to compose your own methods with the standard generated methods. Before this change, you'd have to use alias_method_chain or some other fancy footwork to layer your own logic on top of the standard association functionality. Either that or you'd have to somehow duplicate the standard behavior in your own method. Ick. Now you can compose methods using inheritance and super, the way Alan Kay intended you to. Here's the example from the docs:

class Car < ActiveRecord::Base
  belongs_to :owner
  belongs_to :old_owner

  def owner=(new_owner)
    self.old_owner = self.owner
    super
  end
end

If you're familiar with ActiveRecord it's probably fairly obvious what's going on there, but I'll spell it out for the new kids. When you define the belongs_to :owner association, that generates a standard owner= method, and puts it in the module named Car::GeneratedFeatureMethods, which is the closest ancestor of class Car. If you're curious what this looks like, fire up the rails console and type Car.ancestors to see the class's inheritance chain. (Or use your own app and model, since that will be much easier than making up a new app just to see that one thing.)

In this Car class, you can see that changing owners keeps track of the old owner, so the new owner knows who to call when he can't figure out how to open the trunk. The generated owner= method does a fair amount of stuff including managing counter caches, running callbacks, setting inverse associations, etc. Skipping that could break a number of things, so after saving the old owner, you also want to run the generated method. Since it's in a module that Car inherits from, you only have to call super to get that to run. No muss, no fuss!

One more step towards simpler OOP in Rails! Thanks to my fellow Ruby Rogues Avdi Grimm and James Edward Gray II for complaining about the old state of things enough to motivate me to finally go fix this.

Yak Shaving

2012-01-04T08:23:22-08:00

As coders, most of us are not only familiar with the term yak shaving, but spend many of our days doing nothing but. I often struggle to explain to non-technical folks what I actually spend my time doing when I'm working and what it feels like. This is the most accessible explanation I can come up with.

Say you want to go see a movie with your friend Joe. You can't get away with leaving the house when the kitchen is such a mess, so you have to load and run the dishwasher before you go. Unfortunately you're out of detergent, which means you have to run to the store to pick some up. You want to ride your bike or it will take too long to get to the store. But your bike's front tire is kind of low, so you have to pump it up first. However, your roommate borrowed your tire pump and you don't know where it is, so you have to go find your roommate and ask him about it. He's over at a neighbor's place having band practice, but it's just a short walk. When you get there they are in the middle of practice so you have to wait for a few minutes. The only place to sit is on that ratty old sofa, right next to the drummer's sister, Monica, who will only let you sit there on the condition you smoke a joint with her. But before you can do that you have to dig around in the seat cushions to find the lighter she just realized she lost. You manage to find the lighter, and before too long you are smoking out with Monica. The band finishes the number and your roommate comes over to see what's up. You take another hit off the joint and say "Hey, we should order a pizza."

I heard you liked files

2011-12-01T21:35:41-08:00

I was going to try and be clever and do a funny riff on this whole subject, but I just can't manage it. Here's the thing. Makefile was a dumb name for a file when Stuart Feldman wrote the make utility in 1977, but you have to forgive him because file systems were quite limited back then and filenames could only be a few characters long. The pattern was <filename.ext> - 8 chars for the name, 3 for the extension. I guess config.make wouldn't fit, config.mak looked weird, so Makefile it was.

Now we have no excuse. At all.

I respect and adore Jim Weirich, but I hope he feels at least a little shame for inflicting "Rakefile" on us all. That name choice seems to have set the stage for a proliferation of copycats. Now we have an ever-growing assortment of files that helpfully tell us they are files right there in the file name. Because something siting in a directory in the file system might be something else, like maybe a turnip or a bad hair day. Capfile, Gemfile, Assetfile, Vagrantfile, Guardfile...

You may ask: What's the problem? Why should anyone care about a cute little naming convention that continues a tradition going back over 30 years?

It may not be a huge deal, but there are a couple issues with this. All of these file formats are actually a variation on a well-accepted language: Ruby. But with a name that omits the standard .rb extension, language-aware tools have no chance to help us out. Syntax highlighting? Nope. Will awk search those files for you? No way. Will RubyMine figure out the structure of the code in those files? Forget it. OK, you can add those files to all your tools' configurations, then you're good to go. Until someone creates a new Crapfile and you have to go through and update all those configurations again.

Just because your configuration file's contents are written in a DSL does not mean you should pretend it's not Ruby anymore.

I urge every maintainer of a project that uses a name like Crapfile for the configuration file to move toward using a name that is compatible with language-aware tools. If you can't think of a name yourself, allow me to suggest this:

filename.sub(/file$/, '_config.rb').downcase

UPDATE: It has been pointed out to me that RubyMine actually does a pretty good job of dealing with these file names. Not perfect, but pretty good. Anyway, I don't want to come off as bashing RubyMine (I'm spending more time with it now and it's starting to grow on me), so substitute vim or emacs or TextMate or your most-hated editor instead.

Refactoring: be eager, not reckless

2011-10-19T09:54:46-07:00

The illustrious Chris Eppstein recently tweeted:

If some code should be refactored, stop what you are doing and refactor it.

I was about to respond, but realized I had more to say than would fit in a tweet. (Waiting for someone to fix that problem!) (Then I got distracted and didn't finish this article for a few days, oops.)

Now, Chris is really smart and probably doesn't mean exactly what he said, but it's easy to misinterpret his advice. I'll agree with him that you should be eager to refactor code when you discover the need. Don't let that technical debt accrue interest longer than necessary! However, you shouldn't be reckless about it.

Please keep this in mind:

Don't do a refactoring in the middle of making another change.

If you are working on a story and in the middle of making a code change when you discover the need to refactor something, make a note of it (I usually create a chore in Pivotal Tracker) and forget about it until you're done with the change in progress. After you complete the change, come back and do the refactoring. Make sure all tests are green before starting to refactor, and are green when done. The refactoring change should be a separate commit in git (separate checkin in SVN, etc).

OK, I'm pragmatic and realize that that approach doesn't work all the time, but it's a good ideal to shoot for. I considered discussing cases where it would be OK to refactor something in the middle of another change, but on second thought I think I'll leave that be for now. You'll learn that for yourself better than by following someone else's advice on the subject.

Fifteen Protips for Conference Speakers

2011-07-18T13:26:39-07:00

Do you dream of someday speaking at a technical conference? Have you spoken at a conference but felt like your journey to the podium wasn't as smooth as it might have been? Well here are a couple tips to make things go smoothly and endear you to your conference organizers.

I'm writing this from the perspective of a conference organizer where my main focus is the technical program. I've run into a lot of these issues when putting together Golden Gate Ruby Conference, and also seen things from the other side when speaking at other conferences.

A lot of this list is about not being a problem for the conference organizers. I hope that doesn't come off as too negative, but I figure most speakers don't realize the potential impact of seemingly little things. Making things easier for the organizers makes for a better conference for everyone, and your presentation will be even more awesome.

Respect your conference organizer's time. Organizing a conference is far more work than you realize, and for small, regional conferences it's usually volunteer work. Managing the program is extra fun because dealing with a bunch of speakers makes herding cats look as easy as napping on the beach. There are speakers I'll never have speak at my conference again because they are too hard to manage, even though they are awesome on stage. A good organizer will respect your time, and you should do the same in return.
Respond to all emails promptly. Read the whole email, and answer every question asked of you. This may seem like kid's stuff, but you'd be amazed at how many times I email a speaker and they never reply, reply without answering important questions, or miss the point of the email entirely. Then I have to send another email or two. Multiply that by a dozen or two speakers and you can see how that can create a lot of extra work. (also see #1)
Get a good headshot. Any conference will probably want a photo of you for the website. Some confs want "professional" (i.e. boring) photos, while others like shots that show more personality, so maybe you want to have more than one handy. Either way, you want a photo that shows your face well.
Have someone else write your bio. Most confs want a short bio of you for the website/program. Most people hate writing those things about themselves, so get someone who knows you to write one for you. Remember, this isn't a resume to get a job. The point is to tell people why they should care about what you have to say.
Don't announce that you are speaking until after the conference does. Alright, some conferences won't care about this at all, but most will want to manage their own publicity and control the timing of announcements. And sometimes speakers aren't all informed at the same time whether their talk was accepted, so making your own announcement can confuse things.
Do announce you are speaking! Once you know it's cool to announce, do it! Conferences love the publicity, and you will too. Tweet it, blog it, Facebook it...
Proactively communicate any special requirements you may have for your talk, scheduling, etc. It's usually simple to deal with requests if they come early enough, but can be impossible if they come the day of the conference. Things that might require special attention:
- you can only speak on one of the days of a two-day conference
- you need an uncommon connector for your laptop
- you need the house lighting dimmed during your talk
- you will have extra people on stage who also need microphones
- you need a table on stage with power strips for your science experiment
- you need a wireless microphone so you can stroll around the audience
- you need a bar stool because you can't stand for 45 minutes
- you need wheelchair access to the stage
- your talk requires network access
- you need a lot of network bandwidth for your talk
Prepare your talk in advance. You don't want to be that guy who gets up on stage and says, "Sorry I didn't have time to prepare my talk, so I'm just winging it." Hundreds of people are giving you their valuable time to see your talk. The least you can do is respect them enough to prepare in advance. You're also better off preparing your talk before the conference starts. Take it from someone who spent most of a RailsConf working on his talk instead of seeing other talks and enjoying the conference.
Have awesome, readable slides. You can read up on how to make readable, attention-grabbing slides that effectively support your presentation. Please do. You can start with Shane Becker's Better Presentation Slides lightning talk from GoGaRuCo 2010 (at the 45:05 timecode).
Send your slides to the organizer. PDF is usually a good common denominator format, but including the original helps if your presentation has builds, video, etc. Sending multiple formats is great to cover all your bases. Some confs ask for your slides in advance, but that seems far less common these days when you don't have an A/V team running your slides for you, so don't forget to email your slides when you're done with your talk. Even if you are posting your own slides online, send the PDF/originals to the conf as well so they don't have to find them online to get them.
Practice your talk. Run through it several times. Do it facing yourself in a mirror. If you can video yourself and watch it, that's really helpful too. If you don't have a lot of experience speaking, try out your talk with coworkers or friends who can give good feedback. And don't be afraid to modify your talk based on feedback - that's why they do previews for theatrical productions.
Get some sleep. Don't stay up to all hours partying the night before your talk. Nobody wants to be that guy who drunkenly fell off a fire escape and has to wear giant sunglasses to hide the black eye. You want to show up on time, rested, and raring to go.
Don't flake out. There's nothing worse than not showing up. Canceling at the last minute is nearly as bad. If you think it's likely you'll have to cancel, don't commit to doing it. If something comes up and you can't make it, let the conference know as soon as you can.
Look your best. For many conferences (GoGaRuCo included) wearing jeans and a geek t-shirt is great, while others want something a bit more formal. But even if you just do jeans and a t-shirt, you want something that you feel great wearing. A good rule of thumb is to dress one level up from how you'd dress as an attendee. Also, take off your conference badge when on stage - it's distracting and looks bad.
Have fun! Odds are you aren't getting paid to speak, so you might as well enjoy yourself! Seriously, you'll do a better job and be a more effective speaker if you are enjoying what you're doing.

just a thought

2011-07-06T11:37:57-07:00

We live our modern, high-tech lives immersed in a sea of devices and systems powered at least in part by open source software. It's amazing how much of our lifestyle we owe to the generosity of geeks. I wonder how many non-technical folks appreciate that.

Slightly more readable Ruby

2011-06-19T23:00:02-07:00

A simple coding style for slightly more readable Ruby: symbols as flag arguments.

Use a symbol with a meaningful name instead of true. This makes it clear what you're doing and is just as terse. For example:

def run(log_it = false)
  log_action if log_it
  run_action
end

command.run(true)           # mysterious use of `true`
command.run(:with_logging)  # obvious

The second call to #run is functionally equivalent to the first, because every symbol is a truthy value. But it's a lot easier to read the code with the symbol and understand what the argument means.

The other common pattern I see in Rails is to use an options hash. That call would look like

command.run(:with_logging => true)

If you have a bunch of options, that's fine. When it's just a single optional flag, I prefer passing a symbol with a meaningful name.

GoGaRuCo 2011 CFP

2011-06-13T16:31:15-07:00

And now for some Golden Gate RubyConf news. Yes, we are hard at work getting ready for GoGaRuCo 2011. If you haven't heard yet, the dates are September 16-17, and we'll be back in the same wonderful venue we had last year, UCSF Mission Bay. One of the changes we're making this year is that we are moving away from a fully curated program and are doing an open Call For Proposals for talks.

The CFP has been open for a little while and has about a week left. However, it looks like I haven't done a good enough job publicizing the CFP, since we haven't gotten the number of proposals we wanted to see. As this is my first time running a CFP, it's a learning experience (organizing a conference is full of those!), and I think I was a little weak on promoting the CFP. So this week I'm going to turn up the volume on CFP publicity, and I'm also extending the deadline by a week to give some extra time for people just hearing about it. The new deadline is midnight Pacific time on Saturday, June 25.

Want to submit a talk proposal? Use the online form.

And a bit of guidance about talk content... Remember that nearly all our attendees use Ruby daily, so talks should be for an audience of intermediate or advanced Rubyists. Non-Ruby topics are acceptable if they are somehow related to Ruby, or just seriously awesome. A 100% JavaScript talk is unlikely to be accepted, but a talk about testing JavaScript in your Rails app would be fine. We'd love to see some talks on using new features in Rails 3 and 3.1, experience reports about how you kicked ass in your Ruby project, integrating with other languages, new tools and libraries, working with the Ruby ecosystem, and how you changed the world using Ruby. Or just blow our minds with something amazing.

Also, help promoting this CFP would be greatly appreciated. If you know someone you'd like to see speak, please pass along the announcement and encourage them to submit a proposal.

By the way, RubyThere.org has a list of open CFPs for a good number of Ruby conferences. If you run a conference, please add your CFP to the list. If you're a potential speaker, check it out and submit some proposals!

And finally, if you need any encouragement to speak at GoGaRuCo, let me just say that we love our speakers. Speakers get to attend for free, get some special swag (last year we had hoodies), and get wined and dined at our speaker appreciation dinner. We also give you a Speaker Alumni discount to attend GoGaRuCo in future years, so you can keep coming back a bit more easily.

Go now and propose!

Limitless Strings for PostgreSQL

2011-06-01T22:45:25-07:00

We all love ActiveRecord migrations and the sexy DSL for declaring fields. OK, I don't know if you do, but I sure do. But life isn't perfect (don't get me started), and there's various details that make using the migration DSL a bit of a pain.

The one thing that has annoyed me for ages is how string (VARCHAR) fields are handled for PostgreSQL. While the standard for SQL requires you specify a limit for the length, PostgreSQL is more flexible. From the PostgreSQL docs at http://www.postgresql.org/docs/current/static/datatype-character.html:

If character varying is used without length specifier, the type accepts strings of any size. The latter is a PostgreSQL extension.

Unless your string field needs a limited length for semantics (like a SSN or ZIP code), it's better not to specify a limit for VARCHAR fields.

The problem is that ActiveRecord follows the SQL standard and insists on a limit of 255 if none is specified. So if you define a field thusly:

create_table "users" do |t|
  t.string "name"
end

That is equivalent to

CREATE TABLE users (
  name character varying(255)
);

OK, you think, I know what to do. I'll specify a limit of nil!

create_table "users" do |t|
  t.string "name", :limit => nil
end

But no, that doesn't work. A nil limit is ignored and the default 255 is used anyway. There's a tiny patch for that I might pursue, but in the mean time there is a pretty simple workaround.

Drop these lines into application.rb (assuming you are on Rails 3.0 or greater) within the Application class definition:

initializer "postgresql.no_default_string_limit" do
  ActiveSupport.on_load(:active_record) do
    ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES[:string].delete(:limit)
  end
end

That removes the default limit for string fields. Problem solved. And that's even nicer than saying :limit => nil anyway.

And also, this is pretty cool. I got to use one of those fancy ActiveSupport initializer hooks. Let me explain in case you haven't used one before. What that's doing is waiting until the active_record library is done loading, then running some code to act on the initialized library. That ensures that the default value is removed after it's been created, but before anyone gets a chance to use it.