Agile Otter Blog

There is a relationship between how slow tests are and how much we interact with the tests while we are developing software. If the tests run instantaneously, I'll run them constantly. If the tests run in 30 seconds, I will run them 3 times in any 5 minute window of coding. If they run in 1 minute, I will run them 3-4 times per hour. If they run in 10 minutes, I will run them maybe 3 times a day. If they run in an hour, I'll run them 5 times a week at most. If they run for a day, I will almost never run them. If the build/test cycle is not incredibly fast, I will not participate in the code as fully and richly, instead falling back to rely on my IQ and memory and good intentions more. This is why tools like Infinitest for Java, sniffer for Python, autotest for ruby, and the like matter so much. It is also why there have to be build servers and test servers for any significant project. It is also why manu...

A nice discussion about things that should not be done in Python code, but frequently are. Nice mention of Clean Code's naming rules (I'm a proud daddy).

I saw this in a python tutorial today: if os.path.exists("/tmp/uPlayer"): f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close else: os.mkdir("/tmp/uPlayer") f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close Really, now? We start by duplicating the whole open/write thing in order to create a directory? Maybe one of the problems people have with clean coding is that their examples are poor. If you write, it behooves you to write refrigerator code. Not to mention that close is a function, so it needs parentheses. This code doesn't even do what it thinks it is doing. It's closing the file when f goes out of scope, not when we reference the f.close bound method. It makes me sad for the children.

I'm working with Industrial Logic's newest Python album on microtesting (not yet released) and was lucky enough to get to test out the automated critique. So the way this eLearning works is that you download a problem to work on, and you're given tasks to perform. In this case, it's all about writing microtests for some simple python code. When you finish, you upload your results and an automated critique system digs through the code and gives you ratings and pointers. This is rather like having a mentor sitting with you, reviewing the code. I tell people that the eLearning here is something like they've never seen, but people think I'm marketing or something. Today I have a story for you: Yesterday I made a mistake and the automated critique busted me. The mistake was one where I constructed an object incorrectly and invalidated the premise of the test, yet I did this in such a way that the test passed for the wrong reason. I was feeling so sure I'd...

I'm learning my way through Pylons, which really is very simple (so far) but the tutorials are all wrong in different ways. Even different versions of the same one. One will reference sa.something or orm.something but never import or define 'sa' or 'orm'. Others refer to things without prefixes, but show imports "as sa" or "as orm". Yet others leave out whole sections of code to type. That's the problem with docs, even the best of them. They lie. They may not have lied originally, but eventually they lose touch with reality and begin to say things that are not true. I don't know the editing snafus that lead to several copies of the QuickWiki tutorial all being wrong, but I know that it takes extreme vigilance to keep a document from going south. And I know that as you re-edit, you begin to be less wary. You start to read what you meant instead of what you wrote. I'm sure this is the same case. The subject matter is quite sim...

Mike Pirnat found a snippet of python code. I can only suppose it was written as a joke. Python is such a readable language left in something approaching a "natural" state. This code looks like an entry in the old C obfuscated code contest. It uses a lot of the same tricks they would use back then, though we don't have any way of writing proper macros. It could have gotten much worse if they really wanted to stretch with lambdas, comps, generators, localizing methods, misusing decorators, etc. Personally, I think it's a great example of how important naming and tidiness are. If you can make a great language like python look like a load of manure, then imagine how "clever" programmers can do evil in languages like C++, Java, or even Ruby. Bad code is a matter of intent (or default, in some cases). Good code is intentional. All our code should not be joke code.

A classic unit test blunder is to make use of the system time freely in your code. Another blunder is to monkey-patch your preferred time function. I was working with some ATs which failed because they were written with a date in mind, and the calendar has marched on since those days. The answer is fairly obvious, to override date function. With a little searching, I find a utility fixture for forcing a given date/time. It worked as long as I ran the test in isolation, but failed when I ran the test in its suite. Code in the system performed imports as "from mx.DateTime import now", and 'now' became a stable reference to whatever mx.DateTime.now happens to be. If you change the reference in mx.DateTime, it doesn't affect your stable reference. It binds at the time the mx.DateTime importer is loaded. Now, python does some nice optimization. When you import a file, it doesn't necessarily read the file from disk. If the file is already loaded, it merely maps ...