Highlights of rubyconf

So here is my rubyconf recap, in no particular order:

As always, I enjoyed tenderloves presentation. He's always hilarious, and this year was no exception. This year he really hit the technical material hard and did an excellent job. It was all about the performance tuning and eventual rewrite of Arel. It was a practical deep dive into how to improve the performance of your ruby code. Awesome stuff, definitely worth catching on confreaks.

I was also inspired by DHH's talk. He was basically talk about why he loved ruby. I really liked his thoughts about rejecting the "best tool for the job" idea as if we choose a programming language based on a feature matrix. For me it was the same: ruby code made me happy. What got me inspired though, is that I feel a lot of the same kind of almost giddy happiness about my coffeescript code.

So I've spent time trying to learn write the best javascript I can. It's certainly got some nice features and is not as terrible as people make it out to be. I can write code that I'm pleased with, and gets the job done. But the fact is, I didn't choose the language, the browsers did. With coffeescript on the other hand, all the most annoying things about javascript are just gone. The code I've written (not enough yet, mind you) comes out just so sparse, elegant, and communicative that it makes me feel all warm and fuzzy. It really is much like how I first felt (and still feel) about ruby.

I gave a very lame 3 minute lightning talk on coffeescript on Sunday, and got to talk to a few other people that seem as excited about it as I am. It also felt very reassuring to talk to DHH and one of the other 37 signals guys, Sam Stephenson, about their use of it and how impressed we both are with backbone.js as well. It's still early time here but I can't wait to see how things develop. It's exciting.

Another session I really enjoyed was the redcar session. I was already geeked about redcar before, but after seeing Dan crank out a plugin live in a few minutes I got excited and have been coding on it ever since in my spare hacking moments. I managed to fix a bug (turns out it only happened because I was a version of date with Safari) and then coded up a plugin for the feature I wanted the most, running a single test by name based on where the cursor is. It only talk an hour or two while waiting for a flight. I don't think I've ever had an editor where coding in it was actually FUN. It's quite empowering. There's still lots and lots to do. Hope I can keep finding some spare to time to hack. It's also worth noting that I've been productively using redcar for real coding for all of this week. Rubymine, I loved you for a time, but in the end the performance woes made you too frustrating. Best wishes and fond regards, we wrote some lovely codes together.

And of course, the Polite Programmers session. There were definitely some issues. The banter back and forth didn't seem to work as well as I hoped. Jim left me my openings, I just got nervous and had trouble coming up with natural sounding responses. But we got lots of positive reviews, and it's always a privilege to present and learn from Jim. Ed did a fine job as Mr. Manners as well, what with his inimitable cultured accent and all :)

Can't wait for next year!

JSpec tests running in CI

A lot of people, myself included, have been TDDing our javascript for awhile but it seems like it's still fairly rare for the tests to be run in the CI build. I've taken some time today to get our existing suite of JSpec tests to run in our CI server (Hudson in our case) and thought I would share what I did. My general approach should be useful regardless of which CI server you are using.

It's actually fairly simple: I'm using the capybara selenium driver to run the JSpec tests and grab the results from the DOM when they finish. Here's the testcase:

I define an array of all my jspec tests, loop over them, munge them into a legal test method name and define a method that delegates to run_jspec. run_spec opens a file url (had to go underneath capy here so its a little icky) and then waits for the .failures div to appear. It should be noted that capybara will wait for an element to appear when you call page.has_css?

From here, running it under CI is trivial. In fact I didn't have to do anything at all, the tests was found by rake test:integrations and ran (and passed!) in the next build. Most of the heavy lifting is done by capybara and selenium-webdriver.

Obviously there is a lot that could be done to improve this code. I could grab the jspec file from a FileList, and grab some better failure messages from the DOM. I could also probably write a custom JSpec formatter to make this easier on myself even. I'm thinking if there is interest I could finish this up and turn it into a gem. Please comment if you'd use such a thing.

Also, one more thing you will need is the JSpec runner file that can run a single test. I did that like so:

Enjoy!