Rails Conf 2009 Third Day of Sessions

Last night I chose quantity over quality and ate at a Brazilian steak house. Good times.


Webrat: Rails Acceptance Testing Evolved Bryan Helmkamp (weplay)

Bryan started out his presentation by handing out Tylenol for those who went out last night and Budwiser for those who didn't. The crowd was appreciative.

Bryan show some typical Rails integration testing (simulating clicking through the app without opening up the browser) and compared it to the same test in Webrat. The difference between the integration test and the webrat enabled test was pretty dramatic. The Webrat test was much cleaner and easier to read.

Webrat parses the returned html with Nokogiri (which he highly recommends) and so can do some pretty interesting stuff. click_link, fill_in, check (and uncheck), choose, select, attach_file, and click_button all have a simple syntax.

Webrat automatically is checking for the success of the request so you don't have to assert success everywhere. It also verifies that form fields are there when you try to fill them in. Nice.

There is a Selenium adapter for Webrat so that you can flip your tests over from simulating the browser to actually firing up a browser and clicking through.

good talk.



When to Tell Your Kids About Client Caching Matthew Deiters (Inc.)

This was another talk that had a lot of good content but went pretty fast, so the following are excerpts I managed get into TextMate:

Why should you care about client (browser) caching? Well, 80% of the total time to pull up a webpage is spent on the wire or the client side.

Entity Tags:
When configured, the server sends an E-Tag to client (browser). Then the next time they look for it the browser sends the E-tag back and if the server determines nothing has changed then it send the super small "304 Not Modified" and browser re-renders the page super fast.

Rails can calculate the hash of a page and compare the last time sent to the current and if there is no change then "304 Not Modified"

Don't use etags on static content -- you can set up your apache config to not look again for 10 years.

use commit times for the cache buster
image.jpg?3123123 <- not just the time but use the commit time of the file

To stop ajax from being cached (which can cause problems):
(try not to use method post -- it generates 2 requests)
Use HTTP-Headers => http://github.com/dancroak/no_cache helps you do this

Less requests are better so combine/minifi/compress your javascript and css files for fewer asset requests. There's a lot of tools to do this.

bundle_fu (http://code.google.com/p/bundle-fu/) is one of them.

Let Google host your javascript. Google hosts most popular javascript frameworks so you can rely on them to serve up these assets for you. include_google_js does this for you (http://github.com/chriswarren/include_google_js)



Automated Code Quality Checking In Ruby And Rails Marty Andrews (Cogent Consulting Pty Ltd)

This was the other code metrics talk at Rails Conf. Turns out Marty Andrews is also a former ThoughtWorker. He was (and still is) in Australia during my time at ThoughtWorks so we just met at Rails Conf. Nice guy.

There was a fair amount of overlap between our talks so I'll limit my comments to things that were not mentioned in my talk.

Static analysis is when you analyze the code without running it. No app runtime required.

Feedback for your developers is key to continual improvement.

Marty is a big fan of failing the build on poor Flog, Flay, and Roodi results. I've resisted putting that functionality into metric_fu in the past because I wanted metric_fu to be more about collecting data than judgment. But maybe I was wrong. I opened up a new thread for discussion of this on the metric_fu Google group (http://groups.google.com/group/metric_fu). If you have an opinion on this please comment on the thread.

He showed a bunch of examples of poor Flog/Flay/Reek/Roodi results from the Rails source code -- Not to bash on Rails but to say that even awesome developers we all respect can check in some problematic stuff. We could all use some watching over.

Marty also has a tendency to call "metric_fu" "metrics_fu." Which is funny to me.



All right then, I gotta go catch a flight so this is where Rails Conf 2009 ends for me. Hope you enjoyed these write-ups.

Comments

Edward Spencer said…
Thanks for the interesting writeups and for bringing Rails Conf to we unwashed masses.
Marty Andrews said…
lol - I didn't realise I was saying 'metrics-fu'. Thanks for letting me know.

Popular posts from this blog

What's a Good Flog Score?

Point Inside a Polygon in Ruby

SICP Wasn’t Written for You