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?

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!

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!

To run jslint as a rake task in your Rails project, you’ll only need a few things:

• the Java runtime
• Rhino, the java-based javascript runtime environment
• jslint itself
• a rake task to invoke it

So let’s get it set up. First, the java. Drop into a shell on your development system (or build system, wherever you want to run jslint), and make sure you have access to the java runtimes (run java -v, or which java). If not, go get it. Don’t be afraid, it’s easy.

Next you’ll need Rhino, the javascript execution environment. There are many js implementations (spidermonkey/treemonkey, v8, etc), but Rhino is the one that Crockford chose when he wrote the extension to jsunit that loads a file to be parsed. Its a jar file, go get it and put it into your project as vendor/rhino.jar.

Now you need Crockford’s jslint code. There are two parts: one is jslint.js, and the other is the Rhino extension (rhino.js). We will need both of these, and I’ve found it’s easiest when they are combined into one. Concatenate rhino.js to the bottom of jslint.js and save as vendor/jslint.js.

Hey, we’re almost there! Now you just have to add the rake task to your project.

Drop this gist into an existing Rakefile, or rake task. If you don’t have any rake tasks, then simply save this as lib/tasks/jslint.rake. Rake will find it in your project automatically. Run rake -T to confirm.

A short explanation: it finds all the js files you want to inspect, and runs jslint on them one at a time, printing out failures. Line 6 is the key line – you can change two parts of this to suit your project. First, the list of files to check is created using a Dir glob. My example gets all .js files under /public recursively (*). Then the second part of that line is used to reject js files you DO NOT want to inspect. Frameworks, 3rd party code, for example (although it can be fun to run jslint on your framework code to see their level of quality). This example excludes the ExtJS installation.

Now youre ready to run

rake jslint

and enjoy the benefits of quality-checking your JavaScript code! And since you’ve just built a rake task that returns 0 or 1, it can be easily integrated into you automated or continuous build process. Heh heh – now the build will fail and everyone will know who doesn’t use triple-effing-equals! (see slide 13 of Naked JavaScript)

Enjoy command-line jslint. And if you develop using TextMate, I highly recommend integrating jslint into that as well.

(I’ve been thinking and talking about this for too long. Inspiration to finally get command-line jslint set up came from reading this stackoverflow earlier today.)