I only found a little bit of info when googling for this, so hopefully this helps.

Grease Your Suite by Nick Gauthier: Nick killed it with his presentation on how he used all sorts of optimizations to get his project’s test suite from 13 minutes down to less than 30 seconds. Wow! Presentation style was fun and playful, while still being hardcore and informative (optimizing the filesystem? whoa). I’m really glad this talk was inserted, and wished more people could have seen it.

Pure RSpec by John Larkowski: This talk was all about rspec syntax, and how to make your tests read better. I really dig this type of talk, since I always come away with a dozen new tips to integrate into my code right away.

Git Guts by Jeff Kunkle: Oh man, Jeff unleashed all the crazy details about internal git objects and trees within the first 3 minutes. This was not just a discussion of the basic git commands! This was all about how git works under the covers. Not surprisingly, there were plenty of questions and discussions at the end. Maybe git workflow with branches and merging and rebasing is something we should talk about publicly more often.

Looking Inside Your Ruby Implementation by Russ Olsen: “How many of you are comfortable with C programming?” Russ asked. Heh. He went on to take us on a tour of the C code behind puts. Then he took us through the jRuby implementation too! Unique and informative.

Garbage Collection and the Ruby Heap by Joe Damato and Aman Gupta: I heard this described this as “if you work with Ruby, you gotta go to this one”. It reminded me of a talk I saw at JavaOne way back when about the Java gc. Very detailed.

Sadly, I lollygagged back from lunch on Friday and missed John Trupiano presenting I Don’t Trust Your Code which contains excellent details about how gem maintainers should structure, build, and manage public gems. Excellent advice! This presentation, as well as a few others this weekend, were built with showoff. It’s easy to use:

gem install showoff
git clone git://github.com/jtrupiano/i_dont_trust_your_code.git
cd i_dont_trust_your_code
showoff serve

Now open a browser to http://localhost:9090, and right-arrow through the slides!

How to Teach Anything to Anyone, Even Your Dev Team by Jeff Casimir: Jeff says he wishes he could speak like Dave Thomas…I say, I wish I could speak like Jeff. This was a non-technical and inspirational presentation of some of the basic concepts of teaching. Using books, graphs, and statistics, Jeff took us through the various ways people learn, especially highlighting the “gradual release of responsibility principle”. If I had to pick a favorite talk from the weekend, this would be it. “I do, we do, you do”, Jeff.

Blocks, Procs and Lambdas, Oh My! Functional Programming in Ruby by Paul Barry: Out of my colleagues, Paul holds the title of “The Language Mayor”. During this talk, he showed us some “functional” programming constructs and how they can be applied to Ruby as well as other languages such as Clojure. Rich with syntax and details.

Rails in the Large by Neal Ford: Other than using rock/paper/scissors to solve office dilemmas, Neal also seems to work on one of the hugest Rails projects around. 11 pairs of programmers!?! It sounds insane, and it probably is. Wow. Great insights from an “enterprise” team, including PMs, BAs, UAT, and coffee delivery services.

But, as always, the real value of these local conferences is with the people who attend, and some of the most fun was not sitting and listening, but sitting and conversing and working and learning. I spent some time building an interactive Google map into a project @jtrupiano is working on. I hung out with @nerded and learned why I should be using gitx more often. Over a beer at the RuBy-B-Q, I caught up with @abatalion and met @marchdoe, then Paul and I owned the foosball table. I learned how @bryanl likes to set up maintenance contracts with his clients, and we both agreed that there is plenty of work in the mid-atlantic region right now for all of us. I met @greggpollack for the first time. I talked natural database id’s with @avdi. I think I convinced @stevenhaddox that he can make it to more bmoreonrails meetings if he brings his family! I got to meet @mbleigh and learned about his Rack-based authentication system for twitter/oauth/facebook/etc called OmniAuth. Over beers in the hotel bar, I hacked on the new bmoreonrails website, adding live tweets and a member roster. And the ride up and back from Baltimore with @pjb3 was chock-filled with fun talk about rspec, rss readers, and rails!

Hopefully, I’ll have a similar experience this coming week at JSConf, as well as at Railsconf this June!

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.