Rails Performance, Code Metrics, and Locking Down your Application: Tips & Tricks from Windy City Rails 2008

Josh Symonds, Wednesday, September 24, 2008 @ 3:27 pm

Windy City Rails was the best Rails conference I've ever been to, which is easy for me to say since it was my first actual Rails conference. But even speaking from a fairly uninformed point of view I found it very full of quality. In case you didn't know, it was created by ChicagoRuby, sponsored by Pathfinder (us) among others, and you can find tons more details if you're interested at http://windycityrails.org/. Anyway, it was this last Saturday the 20th, and after four days of digestion I am prepared to deliver some of the highlights:

DHH on Rails Performance and Winning in the Website Business

DHH did a pretty neat 30 minute Q&A session towards the beginning of the day. I'd never actually met (or seen) the guy who initially spawned the framework from which I make my day-to-day livelihood. He's very personable, awfully loud, thoroughly opinionated, and quite brilliant, just like Rails. It is my career goal to be cool enough that I can show up at a conference dedicated to software I created, with no speech in hand and no real plan, but still wing a Q&A session that ends up being one of the conference highlights, because DHH did just that.

One of the questions he answered was about the speed of the Rails framework, which got him off on a really interesting diatribe on how Rails is A) fairly speedy at doing its thing and B) not usually the problem when there are throughput difficulties on a server. Rails only takes up about 10-20% of the time a request is being processed by the server. Seriously, the biggest improvement DHH said 37signals implemented in BaseCamp was telling the server to check the browser's etags. Very handy headers that have been part of the HTTP spec for generations (like HTTP_IF_MODIFIED_SINCE) can provide huge speed improvements if implemented correctly, and that's something usually done by Apache and not Rails at all. But that said in Edge Rails we now have a request.fresh? method that lets us quickly return head :not_modified. We don't even have to hit the database. How cool!

Remember to gzip files you're sending around, and minify JS, and all that other good stuff. Seriously. The tool yslow (which I knew about before the talk because I'm a great web developer) is completely invaluable for boosting the performance of your apps. Use it. Love it.

After DHH finished his talk, there was a small collection of people out in the hallway sponging around him, and being a mindless sheep I stuck around too and learned that DHH has a secret hatred of migrations. They're really great to build iteratively and allow seamless database support, but he was definitely of the opinion that they should be thrown away with great regularity and replaced with the overall schema. Certainly they were never intended for use in production environments (which should be obvious from the existence of the rake db:schema:load task).

And finally, I spoke with him myself, which was kind of awkward since I had absolutely nothing to say. I mean, after you thank him for creating the thing that makes you money, what conversational gambits are left? Discussions of the weather? I ended kind of lamely and ended up kicking myself through the rest of the conference for it. Next time, I'm going to have some emergency questions prepared in case I get a one-on-one with him or another luminary of he Rails world.

What I took away most from his talk was something just of general inspiration and not Rails-related at all, though. In answering someone's question about how to succeed in creating web applications, he stated two things: A) be marginally better than your competition, and B) have greater longevity. Seriously, if you're only 2% better, you'll win in the long run because most companies die and your competitor's will before yours, if you play your cards right. Ultimately, he stated that having a market of millions is nearly impossible; be satisfied with thousands, or even a few dozen thousands.

Think about this: a mere 2,000 customers paying $40 a month leaves your company with a revenue stream approaching a million dollars. That is certainly nothing to sneeze at, and only goes to show that web business models do not require 100,000 users before they become profitable. A lot of people fall into the trap of believing that they'll be the next Google or YouTube and their company will have a market capitalization of a billion dollars overnight. It won't happen. It's more likely you'll win the lottery. Aim modestly, and your chances of success increase exponentially.

Jake Scruggs and Code Metrics that Matter

Of course, our own John McCaffery delivered an immensely popular talk about JavaScript testing, highlighting JavaScript-unfriendly browsers like everyone's favorite Internet Explorer. But since I had heard it already, I went to Jake Scruggs' presentation, 'Using Metrics to Take a Hard Look at Your Code.'

Everyone knows the big code metric: code coverage. It's kind of the old standby of the code numbers world. But Jake Scruggs was pretty dismissive towards it, which is perfectly correct of him. Rcov in particular is not a complicated tool; it checks code coverage only by seeing that particular lines are called. It does not check complicated conditional logic, nor does it check for weird failing cases, and it doesn't tell you when your methods are crazy and overwrought. It is a good metric because you want tests, but it is not a good metric because it doesn't really tell you how good your code actually is.

For that, he recommended a tool I had never heard of: flog. Flog determines the complexity of your methods and lets you know when your code should be refactored into more sensible, bite-sized chunks. This isn't to say that you can't have a hundred-line-long method; but testing is easier and more sensible when code is atomic, and flog really encourages refactoring with an eyes towards atomization.

Also he talked about Saikuro, which is a cyclomatic complexity analyzer. In human speak that means it counts the number of branches in your code for you, which is probably as many tests as that method should have. If you have 5 paths through a method, you want to test them all, am I right? Even if Rcov, the lying but wonderful tool it is, says you have 100% coverage, you almost certainly don't unless you have those 5 paths as 5 different tests.

Anyway I'm totally giving his talk short shrift. It was really fascinating and you can read more about the individual bits of it on his blog.

Locking Down Rails with Aaron Bedra

Aaron Bedra gave a really cool talk on Rails security. Really I don't think developers pay enough attention to this (and I am just as guilty as the rest of us). We take for granted the amazing tools Rails provides to protect against malicious users. SQL injection is rendered useless by sensible finders, cross-site request forgery is foiled by authenticity tokens, and the small little h tag nullifies most cross-site scripting attacks. These are so easy to use and require so little thought on our part that we don't test them, which is clearly the wrong thing to do.

So Aaron suggested a cool new tool that I intend to use from now on called tarantula. Tarantula by default crawls your app and puts bad form data into it to see if your application bombs out. That's fun but kind of yawn-inducing (you're testing your model validations already, right?). Where it gets really cool is that you can set it to perform XSS, CSRF, and SQL injection attacks on your site.

You might get lots and lots of failures.

In that case, it's best to install a plugin that helps audit your code. I recommend xss_sniper, which wraps all of your strings and texts in little h tags so you don't need to remember to whitelist them yourself. But Aaron also suggested SafeERB and xss_shield. Check 'em out and install one! It can't hurt to secure your app even more.

Noel Rappin's Test Last Development

Our very own Noel Rappin also gave a really cool talk on some common pitfalls in test driven development. I'll be brutally honest here. For all my strengths, I am not the best test driven developer in existence. It is hard work to remember to be test driven, especially when you tell yourself, "Oh, I'll just whip this up really quickly and get to the tests later." Good self-auditing techniques are completely required to keep on the testing straight and narrow... and it's very, very easy to stumble.

Noel talked a lot about those stumbles and what they show us about test driven development. I'll leave it for him to discuss the details since I hate stealing others' thunder, and anyway if I tried I certainly wouldn't cover the topic nearly as well as him. Suffice it to say that all of us have been guilty of stumbling into potholes on the road to completely test driven development, and that actually analyzing those roadbumps helps us figure out when some can actually be useful, and how to avoid them in the future.

So, all in all, Windy City Rails rocked! The energy level was high, the food was completely bearable, there were lots of people there, a fair amount of swag was given away (but in a grotesque oversight I did not win any), and here's my strange anecdote from the conference: I was standing in line for lunch and the guy behind me struck up a conversation with me. He said that he's a .Net developer and doesn't know the first thing about Rails. He just wants to learn more about our development processes and what we're doing.

How cool is that?

Related posts:

1. Windy City Rails
2. Web 2.0 Expo: Behavior-Driven Development with Rails and RSpec
3. Rails Testing Frequently Asked Questions — The Non-Code Version
4. Thanksgiving 2008: What We’re Thankful For (In Rails)
5. RailsConf 2008: A Belated Look Back

Comments (3)

Software Development

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. [...] that Jason mentioned that resonated with me the most were closely in line with what I liked about DHH’s Q&A session at last week’s WindyCityRails conference in Chicago. I think a big part of 37Signals success is due [...]

   Pingback by Pathfinder Development » “Build half a product, not a half-assed product” - tips on clarity and focus from Jason Fried of 37Signals, Wednesday, September 24, 2008 @ 4:10 pm

2. 

   Thanks for the overview, Josh. It was a great event and we hope to do it again next year! And thanks for coming… o yeah, and for being a sponsor

   Comment by Matt Polito, Thursday, September 25, 2008 @ 9:09 am

3. [...] Pathfinder Development » Rails Performance, Code Metrics, and Locking Down your Application: Tips &… [...]

   Pingback by เร็วส์ หกสิบหก » นั่งเทียนเขียนข่าว#12, Thursday, October 2, 2008 @ 4:29 pm

Leave a comment