Thanks to those that hung out with me and helped me code these features (if I remember correctly, @rektide, @getify, @vinylfox)…and thanks to Track B for allowing non-mind-melting sessions coughsproutcorecough to be scheduled after a long night of pirate cruise swashbuckling!

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.

UPDATE February 10: Confirmed! I’ve been asked to be a Technical Reviewer, and I’ve already received 3 chapters to review! This is going to be a great refresh for what I think is the best entry-level Ext JS book.

Pat started off discussing “Design for Use“. Then Shea told us all about “Practical Ext JS Debugging“.

My talk is titled “Five Tips to Improve Your Ext JS Application”. I briefly touch on five distinct strategies to use to make your code more maintainable and reusable. Below the slides and video is a short discussion of each topic:

Jonathan Julian at the Northern Virginia Ext JS meetup at Three Pillar Global on 1/19/10 from Jay Garcia on Vimeo.

Define your own components

Explicitly define your own “classes” as you build your UI. This will allow your code to be more reusable, testable, and maintainable. It’s really easy to do, and along with namespacing your files and only defining one component per file, this approach will lead to amazingly clear directory structure.

Use an event manager

Sometimes also known as an “event broker”, this is a simple object used to centralize all events. The example in the presentation is the “simplest event manager you can build with Ext JS”. I like to use at least one in every project to simplify the coding when someone inevitably asks, “can you make it do X every time the user does Y?”

Fire an event on the MyApp.eventManager

Override the framework properly

Anytime you need to “hack” the framework, do your work in a special file (or dir): call it “overrides”. Then when you test your upgrade to the next version of Ext JS, all the integration points to inspect are in one place. I also included my idea of a standard directory layout. I think it works well with the idea of “Namespace Segmentation” as discussed in Chapter 16 of Ext JS in Action.

Remember, it’s still a web app

Write good JavaScript code. Use JSLint. Read The Good Parts and Even Faster Websites.

Prefer an Ext JS SPA to a classic “web app”

This is a tricky one. If you have the choice, build your application in two tiers – Ext JS, and web service. They don’t even have to share the same endpoint! A cleaner design emerges when you separate the concept of the Ui and the data. If you work on a project that already muddles the two with server-side script tags and generation of Ext JS configs with “helpers”, then make it a goal to write all new code in the two-tier style. Put your Ext JS code in .js files. And only communicate with the server via JSONStores and Ajax requests.

The winner_picker UI.

The Winner Picker App

Shea brought a few copies of Learning Ext JS, and Jay brought a few vouchers for an early access copy of Ext JS in Action. We needed a way to give them away – so, I dreamed up a simple app to randomly choose an attendee. To make it fun, I wanted to have a slick animation to randomly highlight attendees names for a few seconds before the choice is shown.

In less than an hour or so, here’s the Ext JS app I made: it’s a grid with an Array Store (attendees were entered manually), and one button that kicks off the process. And the silly animation: every 10ms, a grid row is selected at random and highlighted. The delay is slowly ramped down for effect. After a few seconds, the last random choice is made, and a message box is shown with the winner’s name. The code is on github, and I encourage you to fork the project and improve it, for no other reason than practice (basic knowledge of git is easy to get). The Five Tips can be applied to this tiny project just as well as they can to your large enterprise project!

Conclusion

I think it was a successful event, and I hope to be involved in the future. There were a handful of intense discussions afterwards – it’s good to be a part of a passionate community! If you are in the Baltimore area, come on out to our JavaScript meetup and hang out with us on the first Wednesday of every month. We meet at the Beehive in Canton. If you are in NOVA and want to help build the Ext JS meetup scene there, get in contact with Pat (@sheridap) or Jay (@tdgi).

I’d love to hear what you think about the Five Tips. Feel free to comment here, or on the slideshare page!