Xaprb

Better performance is important in everything, not just MySQL. I don’t want to wait for my text editor to open a file or perform syntax highlighting. I don’t want to wait for my version control system to compute diffs or update my copy of the code with other peoples’ changes. I don’t want to wait for my code to compile. I don’t want to wait, period.

Two tools I have enjoyed recently are Git and the Go language. Both are fast — very fast. It’s a welcome change after suffering from bzr and launchpad over the last couple years. If there is a slower or less efficient revision control program than bzr, I’m not aware of it.

Go compiles fast enough that it’s even a good scripting language. If Gentoo were written in Go, it would be no fun for its regular devotees to use — who wants to use an operating system that doesn’t give you enough time to savor that satisfying feeling of watching Xorg or LibreOffice compile for hours? You can probably tell that I don’t live for the thrill of watching “> /dev/null 2>&1” scroll up my terminal all day.

Clojure In Action, by Amit Rathore. Manning, 2012. About 400 pages.

This is a lucid and interesting introduction to Clojure and the LISP family of programming languages. It’s been years since I programmed in LISP and I found myself recalling those days, at the same time as I learned a lot more than I used to know. Indeed, I realized that my knowledge of LISP was only superficial, and that I probably ought to take some time at some point and learn it deeply enough to have the epiphany people talk about. (Can I plead that I’ve had the epiphany with SQL? No? How about XSLT — it’s basically LISP in XML? Drat.)

The book is in two parts. First you learn about the fundamentals of Clojure, how it works on the JVM, state and concurrency, and so forth. In the second part there’s a lot of deeper and more specific topics. You could say that the first part is about learning the language and environment, and the second part is about how to really put Clojure, um, into action. Conventions, idioms, and the like make their appearance in both parts, but in the second part there’s a lot of specific topics like building web applications with Clojure and creating DSLs.

I haven’t read the whole book. I saved parts of it for later. Perhaps that’s a shame, but perhaps I’m just not ready for them yet, either. In any case I found the parts that I read to be well worth my time.

I’m going to try to explain how to make software testable in really practical terms. I won’t use words like “dependency injection.” Those things annoy smart programmers and make them stop listening.

Here is a pseudocode snippet. There is some function that parses some IP address out of the output of the “ifconfig” command, and some other code that uses this to get an IP address and do something with it.

parse_ip_address() {
   hostname = system.execute("hostname");
   ifconfig = system.execute("/sbin/ifconfig");
   ip = regex.capture(ifconfig, "/some/regex/" + hostname + "/some/other/regex/");
   return ip;
}

// ... some other code ...

ip = parse_ip_address();
// do something with the ip address.

This code is extremely hard to test. If someone says “it doesn’t work on my computer,” you can only respond “it works on mine and I can’t reproduce it.” The code relies on the server’s hostname and the output of the ifconfig command, so the only way you can reproduce it is if you get access to your reporter’s computer and run the code there. (Imagine if it relied on the time of day or the date!)

Let’s rewrite the code.

parse_ip_address(hostname, ifconfig) {
   ip = regex.capture(ifconfig, "/some/regex/" + hostname + "/some/other/regex/");
   return ip;
}

// ... some other code ...

hostname = system.execute("hostname");
ifconfig = system.execute("/sbin/ifconfig");
ip = parse_ip_address(hostname, ifconfig);
// do something with the ip address.

Now you can write back to the person who reported the issue and say “please send me the output of /sbin/ifconfig, and your hostname.” You can write a test case, verify that it breaks, fix the code, and verify that all of your other tests still pass.

That is the absolutely essential core practice in testing: write code in units (be it functions, modules, programs, or something else) that accept input, cause no side effects, and return output. Then write test suites that begin with known input, execute the code, capture the output, and compare it to what is expected.

Now you’ve learned in ten minutes what took me many years to learn. When they taught me about software engineering in my Computer Science classes, they didn’t teach me how to test. They said “you must test rigorously!” and moved on to the next topic. They left me with the vague understanding that testing was an advanced practice that takes enormous time and effort. It turns out to be simple — if you start out right. And it saves enormous time and effort.

Testing has enabled me to avoid becoming a good programmer. I can’t write good code, but I can write good tests, and with good tests, you can see clearly how broken your code is.