Archives

my economics final by “diabetesisfun”

So, if you’re lucky, you’ve mostly missed another Internet pile-up about unit tests and so on, this one started by Joel Spolsky and some comments he made on his podcast.

I’ve already written a little bit about what Joel said, and I don’t want to rehash that. But I have seen a recurring theme in arguments that testing is overrated — namely that the testing that those people are writing about doesn’t seem to be related to the testing that I actually do.

I’m going to put the summary up front:

• “Unit Testing” and “Test Driven Development” are not identical concepts
• It would seem, on the available evidence, that those of use who are TDD or BDD backers haven’t done a great job of explaining this.
• TDD has code quality benefits that are completely separate from whatever function it has as a code verification engine.
• It would seem, on the available evidence, that those of use who are TDD or BDD backers have done a really poor job of explaining this.

Rack’s official Logo

One of the signature changes of the Rails 2.3 release is a complete reworking of the Rails internals to be Rack compatible.

If the people I talk to about Rails are any indication, then reaction to this move has ranged all the way from “Wow, that’s really cool” to “I have no idea what you are talking about”.

Here’s a quick look at what Rack is, and what it brings to Rails. I freely admit that I’m only starting to explore this stuff myself, but it’s already starting to change the way I’m thinking about structuring new Rails applications.

What is Rack?

This week marked the release of Ruby on Rails 2.3 RC 1.

If you’re thinking, “Good Lord, that was fast. I just got around to watching the What’s New in 2.2 video”, you’re probably not alone. 2.2, according to the ever-reliable Wikipedia, was released about 10 weeks before 2.3 RC 1. And it’s not like 2.3 is a minor tweak — it includes a major change to the Rails internals (Rack support), a nested form feature that’s been a top request for some time, and a bunch of other small, but nice changes.

However, I don’t mean to do a “What’s New” post — at least, not this week. This week is a little bit more meta, and might more accurately be called, “How To Deal With What’s New”.

Measured Currency by Brooks Elliott

What have I been doing this week? Estimating things.

Estimating potential jobs is critically important to a consulting firm. Estimate too high, and you don’t get the job, estimate too low, and you’re setting yourself up for client disappointment.

Complicating matters, the job is never specified in enough detail, and you really don’t want to spend too much time putting the estimate together, because that’s time spent not coding.

Even if you aren’t estimating potential work, being a good estimator is a very useful skill within the ordinary work of an agile development team. Being able to specify how long your next task will take makes it easier to plan iterations and determine the status of the project as a whole.

So, in the grand tradition of a blogger writing things down in order to force himself into some more systematic thinking, here are some ideas about estimating.

On Beyond Zebra

Previously on Agile Ajax: I wrote about a complicated problem that went beyond ActiveRecord. I resolved to add a database column with pre-generated results to make the search logic easier. Commenters questioned my reluctance to use SQL directly.

I wanted to come back to this topic and talk about the process of creating and maintaining the pre-generated data. To reiterate the problem, I needed a report that would display:

• All individual times for all swimmers within search criteria
• The most recent relay time for a swimmer in each event, but only if the most recent relay matches the critera, otherwise don’t show any relay times

The solution being pursued is to add a “most_recent_relay” field to the database and use that in a two-phase database search to display the report.

Just a quick note that the next two testing interviews are up on the Rails Prescriptions Blog:

Geoffrey Grosenbach of PeepCode and Topfunky.

Gregg Pollack of Rails Envy, the Rails Envy Podcast and Rails Activist fame.

Enjoy!

These interviews will be just as important as Frost/Nixon

Over at the Rails Prescriptions blog, I’m going to be posting a series of interviews with various and sundry Rails folks — I’m cross-posting the first one here. To get the series started off, I’ve decided to use myself as a guinea pig and see if I can hold up to the grilling.

A couple of quick notes before I get to it.

• The free e-book Getting Started With Rails Testing is now available. Check it out.
• Those of you lucky enough to be in the sub-zero Chicago area can come to the Chicago Ruby.org meetup Saturday, January 17th to hear lots of interesting stuff, including me talking about testing and Rails some more.

And on with the interview.

I’m pleased to announce that the getting started guide, conveniently titled “Getting Started With Rails Testing” is now available for download at the Rails Prescriptions site.

It grew to be a bit longer than I originally intended, but I’m very happy with how it turned out. It starts with an empty Rails application and walks through the first couple of feature additions, adding tests for controllers, models, views, and basic security.

Download, read, enjoy, tell all your friends, let me know what you think.

I’ll be doing a talk on Getting Started With Rails Testing and/or related testing topics this Saturday, January 17th at the monthly meeting of ChicagoRuby.org.

It’s at 3pm, location and other information is available at their meetup.com site.

Looking forward to it — see you there!

Image of Thomas The Tank Engine is from the
New York Times, I think, but I can’t find the exact page.

I love ActiveRecord. I don’t really much like working with relational databases (like Tolkein wizards, databases tend to be good at getting you out of the kind of trouble that databases get you into…).

Sometimes, though, you get a requirement that seems explicitly designed to drive both ActiveRecord and your database of choice stark raving mad. Here’s an example based on an actual client requirement (details changed to protect the innocent):