Coding Is Like Cooking

I am really interested to find out more about this concept of “clean code”, and in particular how it relates to programming language. To this end, I’m still chewing on KataArgs.

My latest idea is to start from Bob Martin’s Java implementation, and translate this as directly as possible into python. My idea is to then refactor it to be more pythonic, and see if it turns out looking anything like his Ruby implementation.

I have put up some code on launchpad, which is my attempt at a direct translation of the Java. It was really interesting to do, actually. Of course I had read the Java before, and followed along in the book all the steps to create it, but actually translating it made me understand the code on another level. When I tackled this Kata from scratch, I also got a much better understanding of it, but this was different.

One thing that jumped out at me was the error handling. It’s much more comprehensive than anything I’ve produced in my own solutions, and also compared with his Ruby solution. So I think it’s a bit misleading of him to say “I recently rewrote this in Ruby and it was 1/7 the size”. Of course it is smaller. It does less. Although to be fair, in a way it does more too…

One thing I found awkward to translate was the use of the enum for the list of error codes. Python doesn’t have a direct equivalent, being dynamic as it is. The other awkwardness was the Java iterator. In python iterators are built into the language, but don’t let you backtrack, or get the current index, unlike Java ones. I was surprised to find how extensively the tests rely on this functionality. To my mind, they probe the internals of the args parser too much.

By far my most interesting observation, though, is the one I want to explore more. This code is well written Java, but directly translated, it makes pretty poor python. Why is that? What, specifically, are the smells, and what are the antidote refactorings?

I will no doubt post more on what I find, (with the help of my friends at GothPy, of course)

The second official meeting of the Gothenburg Python User Group was last night. Eight of us turned up, despite my writing the wrong address on my meeting invite. (It is Norra Ågatan 10A, not 6A – sorry!)

Anyway, in the first part of the meeting Jacob Hallen explained about PyPy, a very interesting project. It seems PyPy aims to replace jython, iron python, stackless and a host of other things, and has nearly as good performance as cpython. Jacob reckoned it would be ready for general use in about a year’s time.

After fika, Johan gave a short presentation about how he uses Python at Nordea. Although the company policy is only to use Java and Cobol, he has had some successes with using python too. He’s written several small applications that have been quick and cheap to build and have lasted much longer than their initially projected lifetimes. Unfortunately he hasn’t persuaded anyone else at Nordea to write any python yet.

The coding challenge for the evening was KataRomanNumerals which went very well. We split into four groups and in less than 45 mins three of the groups had working solutions, all different, all elegant in their own way. My group was the one that didn’t come up with a solution and that was because I was more interested in how to define the tests than how to define the solution 🙂 I wanted to write the tests in a spreadsheet then generate unittest test cases. It kind of worked. I will try again another time with FIT instead.

Most importantly, everyone said they enjoyed the evening and the chance to write some python code, just for fun.

At the XP2007 conference, Geoff and I presented a workshop entitled “The coder’s dojo: Acceptance Test Driven Development in python”. (Geoff also presented the same workshop at agile2007). We had three aims with this workshop, the first was to use the meeting format of a coders dojo, the second was to do some coding in python and the third was to demonstrate how you can do Acceptance TestDriven Development using TextTest. We felt the workshop went well, we had around 30 participants and we were able to do a little of everything we had set out to do.

Perhaps the most important thing was what we learnt from the experience. The workshop participants gave us some very useful feedback. One thing people said was that there were too many new ideas presented to expect as much audience participation as we did, and that instead of trying to do aRandori style kata, we should have done it as a Prepared kata. There also seemed to be a view that the Kata we had chosen (KataTexasHoldEm) was quite a difficult one. Another very valuable piece of feedback was that we were doing Test Driven Development (TDD) with much larger steps than people were used to.

What I have done is to create a screencast in an attempt to address this feedback, and open up our workshop material to a larger audience. In it, I perform a Prepared Kata of KataMinesweeper, doing TDD with TextTest and python. Geoff and I have been developing this approach to testing for a few years now, and we think it deserves consideration by the wider agile testing community. There are important advantages and disadvantages compared to classic TDD with xUnit.

I will write an article about this approach and provide links to the screencast in my next post on this blog.