Sometimes when you are doing rapid development, you need to create a new method right now, but you don’t put the method in the right spot. Maybe you aren’t sure what object should ultimately have the functionality. Maybe you are simply too lazy to open the correct file. Whatever the reason, you decide to define the method right there at the top-level, pretending you are a procedural programmer.

While listening to the Code Quality panel discussion at CodeMash, I tweeted about “the state of mocking”:

The state of “mocking” is that the term “mocking” is misused by everyone. You often mean “test double” or “stub”.

This garnered some retweets and some great replies, so I wanted to have the opportunity to respond in a little longer form. I’ve written this post between sessions and in the halls, so give me a little leeway and feel free to send me a tweet with corrections, arguments, whatever.

Recently, I was asked to help review new tests for production code that made use of the Builder pattern. The code in question did not lend itself to nice and easy testing, but leveraging a lesser-used bit of Mockito functionality helped make the code better.

What is refactoring? Martin Fowler provides a solid definition:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

That description seems fairly reasonable; let’s look at some potential refactoring techniques.

Over the last year or so, I’ve been trying to learn about various types and methodologies of testing. The Ruby community is pretty vocal about testing, so I felt out of place not knowing even the most basic of things. This post is intended to organize my current thoughts and hopefully provide some guidance for people on the same journey.

Git encourages you to create commits early and frequently, but I often find that my last commit isn’t quite as awesome as I’d like it to be. However, there are three little tricks I use to tweak it a bit.

I’ve been trying to learn Clojure recently, so I wrote Conway’s Game of Life. I’m sure that the code is highly non-idiomatic, but I’d rather get it out into the wild, instead of sitting on my disk.

At work, we are embarking on a grand new project, one that promises to involve quite a few engineers and take a good chunk of time. It is the quintessential Next Big Thing. So far, one or two prototypes of the new product have been developed (and demonstrated with positive feedback), but now it is time to really get our hands dirty.

Of course, by “hands dirty”, I mean that it is time to generate reams and reams of project plans and software designs, both of which will take an inordinate amount of time to create and then be underused and under-maintained. One old friend that popped up during project planning was the ever-popular Gantt chart.

The version of ActionMailer included with Rails 3.0.4 allows you to use named routes in the mailer view by default, but writing a functional test that tests those named routes isn’t as out-of-the-box.

We recently tackled an issue that seemed rather impossible – an unsigned 64-bit value was greater than the maximum value that a 64-bit value can hold. What unfolded was a dark, gritty look at the underbelly of everything we hold dear (or a normal debugging session, as we like to call them).