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...