Query functions return stuff. For example, new, create, get are all functions which ask for something in return.

Command functions change state. For example, set, adjust, compute.

Try very, very hard not to “mix and match”. Functions which both query and command are really hard to test, and worse, they are much harder to understand.

Think of it this way: testing a query function means testing only that the returned result is correct. Testing a command function means testing only the state of the object as a result of the command. If you have a function which commands and queries, you may find your function has weird interactions. Basically, your test code has to test the return, the state, and every possible interaction.

Plus, it’s just semantically confusing otherwise.

Update 2012/05/19: Command and query are analogous to “inspect” and “mutate” in the c++ world.

One reason is this: Vast amounts of software engineering literature provide examples using these languages.

Currently, I’m reading “Working Effectively with Legacy Code” by Michael C. Feathers.

All the code in the book is (of course) C, C++ or Java. But the principles documented in the book are language independent.

The last example in the book, on extraction refactoring, is something I’ve been doing for years, and didn’t know there was a name for it. That’s pretty cool.

But it can be learned.

1. Write the code you’re going to write anyway.
2. Test your just-written code thoroughly.
3. Keep your tests and throw away all your code.
4. Now rewrite your code.

It takes extra time, but only the first time.

Given you’re writing test code anyway, test-first will pay you back the second or third time you write the code.

If you’re not writing test code, move along, nothing to see here.

The main gotcha: he didn’t write any test code.

Most likely, the client was unable or unwilling to pay for the test code when the site was first created.

Most likely, the client will not be interested in paying for test code now.

The irony here is that had the developer originally written test code, he would have much more confidence updating the site.

The client pays regardless: either someone comes and cleans it up, or the client pays for a new web site. At this point, not writing test code increases developer time as the new developer reverse engineers the existing code. Might as well test.

Finishing might be really boring, but it’s in no way difficult.

Here’s how to finish those projects:

1. Do all the work.
2. Publish what you did, like write a blog post or something.
3. Promote it everywhere sensible.

I bet you have a project which wants only three or four hours to call done. Why not just do it?

Personally, I had a pretty good time in college.

I didn’t go into a lot of debt, I met a lot of really cool people, and took some really interesting classes.

Perhaps if these unhappy people approached education with an open mind and asked what they could contribute, they might have “got a lot more out of college.”

In short, college is like anything else: if you don’t put anything in, you’re not getting anything out.

1. The language is fine. Different than Ruby, no better, no worse.
2. The working environment needs a lot of work to match the ease of use provided by `rvm` and the `rubygems` system.

The current task is setting up the numerical toolchain, for which Python is celebrated.

The setup instructions for the numerical toolchain ask the user to set global variables for important tools such as gcc, fortran and the like, which is spectacularly inconvenient for people doing more than scientific python programming.

More later after I figure out how to firewall the python tools.

Update 2012/04/03: From StackOverflow, the Python community appears to be heavily RTFM. One of the questions I was looking up was how to find the number of items in a list. The obvious list.[size,length,count] didn’t work, nor did [length,size,count](list). Turns out it’s len(list). No comment.

Here’s one way to do it:

1. (Best) Test first when you can.
2. (Almost as good) Test immediately after writing the code.
3. (Still pretty good) Fix anything broken before pushing to remote.
4. (Better than most) Push no uncovered code.

It’s worth noting that iterating into a spike by writing and continually rewriting tests results in a “covered spike.” It’s not test-first, but it’s hard to argue it’s not test-driven.

Taking test-first as an optimal strategy for development, we can redefine test-driven development as “push no uncovered code.”

In martial arts, a kata has a starting point and a stopping point, so too does a code kata.

A code kata starts from a position where everything is known, and proceeds along specific steps to a desired result.

Typically, a code kata is less about programming and more about framework and configuration.

The end result of an effective code kata reduces implementation time by 90%.

Here are a few code katas I’ve developed for building Ruby on Rails applications.

* Devise
* Email
* Cucumber BDD

Developing a kata is very time consuming. The payoff is that 90% reduction in effort.

The term frame control implies a subtext of psychological manipulation on the part of the speaker.

(This carries over into writing.)

The epiphany: when someone is writing or speaking as to invite controversy, if they establish frame control, you have two choices:

1. Agree with the speaker.
2. Leave the conversation.

Discussion under these conditions serves only one purpose: maintaining the speaker’s frame.