Hanging out with friends

We always have a strong contingent of Bmore on Rails folks at RubyNation. This weekend I twice received unsolicited praise that the Bmore on Rails group was “friendly and cohesive” and “one of the more fun local groups”. I’m paraphrasing, but it was awesome to hear that others see us this way. It’s true!

Making new friends

I can’t even count how many colleagues I’ve met at previous RubyNations! I don’t feel like I met too many new folks this year, but it’s still a big part of any local conference to me. If you met me (or even if you didn’t), make sure to keep in touch on twitter!

The Talks

I was lucky, I had already seen three of the sessions at Bmore on Rails in the last few months (“Fat Models Aren’t Enough” by Jeff Casimir, “Confident Code” by Avdi Grimm, and “KnowSQL: Database Tricks to Make Your Life Easier” by Nick Gauthier). This made it easy for me to see a couple of new talks.

“Git: It’s All About the Trees, Baby” by Scott Chacon

Scott obviously knows git inside and out. The details are complex, and I’m mystified about it on a regular basis, even though I’ve been using it for over 3 years. I love how Scott slows down to ask, “Does that make sense?” after every difficult concept. I took feverish notes and re-read them a few times – after some digestion, yes, Scott, now it does make sense. I think. slides

“Make Awesome Command Line Applications in Ruby” by David Copeland

For some reason, this topic speaks to me. Maybe it was all the shell scripts I wrote early in my career, or my love for the “UNIX way” of building large systems from many small tools. This was one of those talks that probably snuck under the radar, but those who were there know that they took away a ton of knowledge. I’m looking forward to David’s upcoming PragProg book on the subject! slides

“Search-Friendly Web Development” by Luigi Montanez

It must be tough to be the first session of day 2 of a conference (wait, it is). I wonder how many people were scared off by the thought of this being an “SEO” talk? Well, it was. And it was excellent. To web developers, SEO doesn’t have to be much more than checking off a few boxes. Really – it’s not crazy difficult. Luigi laid out a great plan to help your site be more successful: by optimizing crawling, indexing and ranking. I’ve been forced to learn a ton about this subject while working on replyz.com – we have a footprint of close to 10 million urls, so managing searchability and the sitemaps has been one of my jobs for close to a year. Great job, Luigi! slides

“The JavaScript Renaissance” by Chris Williams

Chris is a showman. Did he really hand out 200 pirate hats? When his speakers weren’t loud enough, did he really voice-over the Numb3rs episode where they explain IRC? And did he really convince a room full of Rubyists that their favorite language has strong competition from other programming languages? Yep.

“Must. Try. Harder.” by Keavy McMinn

Every conference needs at least one inspirational talk. And this one fit the bill perfectly. Keavy’s even-paced delivery and detailed descriptions of the agonies of triathlon training provided a great analogy to our software development careers. The video of the harrowing descent left the room silent for a full minute and a half. Well done!

Jeff Casimir setting up his gear to take headshots

Jeff is the coolest. He gives a brief lightning talk imploring everyone to use their face as their avatar, not a cartoon or a logo. Then he invites everyone to step out into the lobby where he has set up a temporary studio – complete with a backdrop and two remote flashes. Fifty people stepped up and got their photo taken, and Jeff posted the results to flickr the next morning. The next morning. Seriously, this guy is awesome. By the way, are you looking for Ruby or Rails training? Check out Jumpstart Lab. (Also, why are so many folks afraid to step in front of a camera? You know we all can see you right now, right?)

“Your code is awesome. Your copy sucks.”

I love lightning talks – you never know what you’re gonna get, and the investment is low (5 minutes). This year my favorite was about copy writing (that’s the stuff between the tags that the user sees). Andrea from corgibytes let the uber-techie, male-dominated audience know that the words you write matter. I play the role of copy writer for a few minutes (!) every week, and I appreciate raising awareness about this under-appreciated skill.

The Hacking

There was considerably less code hacking this year – but we still fit some in. Paul Barry wrote a Ruby chat server in the few minutes leading up to Nick Gauthier’s talk. And I told Andy Atkinson my idea for listing members on bmoreonrails.org, and he ran with it and started the feature! (hopefully we’ll have members listed on the site this week)

The Party

Github sponsored the drinks, Living Social sponsored the food. And it was at a Westin. Do I need to say more? If you were there, I’d love to hear your thoughts on the mini-burgers (I thought they were the coolest things ever).

My Conclusion

It was another fun local conference. Congrats to Gray Herter and David Keener and David Bock, and everyone else who organizes RubyNation every year. Keep in mind that these were my favorite parts of RubyNation – yours will most likely be different. What did you enjoy most about the conference? What did I miss?

In the “old days”, you’d override to_json in your model class to provide a JSON implementation of your model. Then in your controller, render :json => @model would work perfectly. And some folks would even redundantly code render :json => @model.to_json, and that would work too.

to_json even had some great options for ActiveRecord objects! You could tell the method to only render certain attributes, or to include associations or method calls!

render :json => 
  @user.to_json(:only => [:email], :include => [:addresses])

Life was good. But things start to fall apart when you want to do something a little out of the ordinary. Like return JSON with the model as part of a bigger structure.

render :json => { :success => true, 
  :user => @user.to_json(:only => [:email]) }

Oops. {\"user\":{\"email\":\"me@example.com\","success":true}has the JSON characters escaped, which is not what we want. So what do we do? We hack around it:

render :json => { :success => true, 
  :user => { :email => @user.email } }

But this doesn’t scale – we have to explicitly create the JSON by hand in the controller. What if we need 5 or more attributes? Yuck!

Enter ActiveSupport 2.3.3. Now the creation of the json is separate from the rendering of the json. as_json is used to create the structure of the JSON as a Hash, and the rendering of that hash into a JSON string is left up to ActiveSupport::json.encode. You should never use to_json to create a representation, only to consume the representation.

def as_json(options={})
  { :email => self.email }
end

Anytime to_json is called on an object, as_json is invoked to create the data structure, and then that hash is encoded as a JSON string using ActiveSupport::json.encode. This happens for all types: Object, Numeric, Date, String, etc (see active_support/json).

ActiveRecord objects behave the same way. There is a default as_json implementation that creates a Hash that includes all the model’s attributes. You should override as_json in your Model to create the JSON structure you want. as_json, just like the old to_json, takes an option hash where you can specify attributes and methods to include declaratively.

def as_json(options={})
  super(:only => [:email, :avatar], :include =>[:addresses])
end

Your controller code to display one model should always look like this:

render :json => @user

And if you have to do anything out of the ordinary, call as_json passing your options.

render :json => { :success => true, 
  :user => @user.as_json(:only => [:email]) }

The moral of the story is: In controllers, do not call to_json directly, allow render to do that for you. If you need to tweak the JSON output, override as_json in your model, or call as_json directly.

Fix your code now to use as_json – it will be one less thing to worry about when you migrate to Rails 3.

This post was inspired by the investigation I went into while exploring the answer to this question on Stack Overflow.

Hey Brian Morearty – Rails was never Javaficated to begin with. So the answer is yes.

We decided that delayed_job is an easy and solid way to get background tasks running in your Rails app, but if you are a massive site that needs a heavy-duty and configurable solution, then Resque may be what you need. Resque’s complexity makes this a non-trivial decision! Start with delayed_job since it’s so quick to implement, and you can always choose another solution later.

Want to get delayed_job running in your app in 10 minutes? Follow the steps in Delayed Gratification with Rails.

Just drop that into an file in config/initializers, restart, and get styling!