Jake Scruggs

Word on the street is that Lone Star Ruby Conf was one of the best regional conferences last year, so I'm pretty excited to be presenting at the 2008 edition. It's happening Sept 4-6th in Austin, TX and speakers include: Matz, Evan Phoenix, Jim Weirich, The Rails Envy Guys, and too many other luminaries to name. I'll be giving a talk entitled " Using Metrics to Take a Hard Look at Your Code " which is a distilation of my thinking over the past year about how to use numbers not as a hammer with which to beat people, but as a tool to improve your code. Registration just opened up today, but space is limited so go sign up soon.

Recently I spent some time away from RSpec and I did miss it, but one thing especially liked about the testing framework I lived in for 10 months was that it had two ways to test anything you liked: One that hit the database and one that did not. We used UnitRecord to disconnect unit tests from the database (I should mention that we defined unit tests as tests that didn't hit the db and functional tests as those that did). So the vast majority of our tests didn't really need to hit the db and ran very fast. Sometimes we wanted or needed to hit the db and we did (only occasionally in model tests, more often in controller tests, and we kept logic out of the view and only tested views at the Selenium level). It was pretty cool and I'd like to thank the team who set it up before I got there. There's been a lot of talk about whether model, view, or controller tests should hit the db but I've found that there's enough exceptions that it's worth just saying that...

I've been on a few projects where I've had to mess with breadcrumbs and they tend to be much more trouble than they're worth. It all starts simply enough: put the users path through the app on the page. Which isn't too hard. Then the bugs come. Like: "This page is linked to from page A but it really is more of a child of page B so the breadcrumbs should show page B and not A even if they come from A" Or: "When I come to page X from the search on the front page it should have breadcrumbs with Y and Z because that's really what it's under." And: "Page L is listed under K but should be under M (followed a few days later by) Page L is listed under M but should be under K" Oh, you want a hierarchy. Which is hard. First: There's now a new job to be filled: Taxonomist. Somebody is going to have to figure out where all the pages in the app fit in some sort of tree. And this list must be maintained. Second: There must be...

So I've been making do with lame-o 'pre' tags for my code snippets and my blog looks, well, lame. But the various alternatives for highlighting ruby either didn't work for Blogger or smacked of effort (and you know how I feel about effort). Well, recently I joined Obtiva and I was being all nosy looking at my new co-worker's blogs, when I found Tyler Jennings post about creating Spotlight . Take some ruby code, paste it into the text box, press a button, and you get some html which you copy and past into your blog. You'll have to include the default css in your css file the first time, but that's not too hard. Output looks like this: 1 class Echo < ActionMailer :: Base 2 def copy formatted_message, incident_id 3 users_with_echo_emails = User .find( :all , 4 :conditions => " echo_email is not NULL " ) 5 users_with_echo_emails.reject! {|user| !user.receive_echo?} 6 recipi...

So today, for something like the fifth time, I sat down in front of a TextMate installation that didn't have saving set up the way I like it: Auto save on loss of focus and when running a test (or spec). And, for the fifth time, I had to dig around the internet for the answer. So, as a public service to my future self: Save files when focus is lost: http://macromates.com/textmate/manual/saving_files TextMate --> Preferences --> Advanced --> Saving Save all files when running a test (or spec): http://macromates.com/textmate/manual/commands for specs: Bundles --> Bundle Editor --> Edit Commands --> Rspec --> Run Single Example Bundles --> Bundle Editor --> Edit Commands --> Rspec --> Run Examples for tests: Bundles --> Bundle Editor --> Edit Commands --> Ruby --> Run Bundles --> Bundle Editor --> Edit Commands --> Rspec --> Run Focused Unit Test Change the save drop down to "All Files in Project" Hope this helps, f...

Sometimes a class does too much. It's used everywhere, does everything, knows all about the nasty internals of all the other classes, and every time you change anything in the application it has to change. Or maybe you have a class that everyone loves to refactor because it's so bad. One developer changes it to be better, then another changes it to be a different kind of better, and this keeps happening without it ever getting any easier to use. There's a lot of bad reasons why a class might change all the time so I added a churn report capability to metric_fu version 0.6.0. Now you can use metric_fu to create a report like this: By issuing this command: rake metrics:churn And use the results to find classes that might have problems. It uses 'svn log' to create this report so currently you need to be using subversion. (If anyone out there want to contribute some code to get it working with git, lemme know.) The default is to start counting changes fro...

Every time I create a new rails project I usually put off writing tasks to analyze the code's quality 'cause it takes time and time is, you know, finite. So I've decided to extract some code into a rails plugin which I call metric_fu. It's a bunch of rake tasks that produce reports on code coverage (using Rcov ), cyclomatic complexity (using Saikuro ), flog scores (using Flog ), and rails stats (using 'rake stats'). It knows if it's being run inside a CruiseControl.rb build and puts the output in the Custom Build Artifacts folder so when you view a build you see this: The coverage report is your standard rcov report: Flog output is thrown into an html file: At the end metric_fu calculates the average flog score per method: You might want to check out my previous posts on what to do with a Flog report: The Method Hit List and When You Should Ignore Metrics Saikuro's output is the same as always: (I changed the warning and error levels for this pic -...