Speak and Shout

Tuesday, May 20, 2008

A checkers game

I've made a couple different attempts before to write a Checkers program in Python, but for various reasons, the project stalled. This time, I've been quietly working on it behind the scenes, and last night I played my moves against an intelligent computer player. Some reasons why I had success this time around:
  1. Using existing open-source code as a reference. Before I was trying to do everything myself from scratch. Sometimes this can be useful for learning purposes, but in some cases it can just be an exceptionally bad use of time. Now I'm taking a look at code that other people have written and reusing it where I can. For instance, Martin Fierz's Simple Checkers has a good, basic evaluation function that I've been able to use, and Peter Norvig's elegant Python implementation of minimax would be hard to improve upon. There's enough other interesting challenges in trying to develop my program -- there's no need to waste time doing wheel reinvention.
  2. Testing. This is the first time I've worked on a personal project where I felt unit testing while I developed was an absolute necessity. (Although I did test-after, not test-driven development. Sorry, agile folks.) I always do testing in the Python shell, but it's somewhat informal. This time it was formal. Checkers has a number of rules about moves/jumps that are important to get right, and almost every test I wrote uncovered a bug or a subtle problem with my data structures. Thumbs up for unit tests.
  3. Focusing on the logic, not the GUI. Before I was developing my checkers GUI in tandem with the game model. Now I'm concentrating on getting the logic right first, and my initial "GUI" is simply an ASCII representation of the checkerboard. In the past, with too many pieces of code changing at the same time I was getting overwhelmed, especially when trying to refactor. Focusing on the GUI is seductive but is ultimately the wrong use of time early in the project.
In regards to #2 above, the focus on unit testing has also continued to drive the development of my Komodo extension, kNose, which is also very positive. I'm working on updating the extension to use nose 0.10.1 and its much improved support for plugins. (And in another major milestone, kNose is now hosted on google-code and has a new project member, Christoph Zwerschke, who's been a huge help.)

Once my Checkers game is released, I'd also like to donate it back to the AIMA project as an example of what can be done with community code.

Labels: , , , , ,

Monday, February 25, 2008

The Impatient Developer's Guide to Nose Plugins

Eric Promislow of ActiveState has been working with the nose unit-testing framework in order to hook it into the new version of Komodo IDE. Along the way he figured out how to write a nose plugin, and he's documented his work in this article. (Poor Eric misspelled my name as Brendan, but otherwise it's a great article! ;D )

I'm working hard right now on a game, but this information is cool enough that I could be persuaded to update kNose to use a nose plugin like Eric describes. However, Komodo 4.3 could very well obsolete my work. Are there enough kNose users out there that would like to see an update, or would you rather wait for the next version of Komodo and its unit testing support?

Labels: , , ,

Thursday, July 19, 2007

kNose 1.0 released

kNose is a free Komodo IDE/Edit extension for Python unit testing; it uses the nose unit testing framework written by Jason Pellerin.

kNose is available for download here, along with documentation I've provided on how to install and use it.

Hope you enjoy it!

Labels: , , ,

Wednesday, July 04, 2007

A quick kNose update

Sorry, I promised to keep everyone updated, and I haven't been doing that.

I've finished working on expanding and collapsing the tree view and running tests in a background thread. I'm currently writing the code to display tooltips in the tree for any tests that had failures/errors. It's been hard to find out how to do this, because it's very hard to google for "tooltip treeview XUL" (and other combinations thereof) and get any meaningful results. However, I finally found some sample code to look at, and I'm hoping this doesn't take me very long.

I've noticed some small bugs in my parsing of nose's output results, and I also need to save some of the treeview settings inside of Komodo's preferences. Both of these "to do" items, however, are fairly insignificant.

My plan is to release it by the end of this week.

Labels: , , ,

Monday, June 11, 2007

kNose extension under development

For about a month, I've been quietly developing another Komodo Edit/IDE extension called kNose. It's a GUI front-end for the nose unit testing framework for Python written by Jason Pellerin. I wanted something that would make it easy for me to jump into testing as part of my normal development. Despite the cool nature of auto-discovery and execution of unit tests with nose, I'm still too lazy to use it if it's not integrated with my IDE.

Here's a screenshot of how things look so far for the curious:


Yes, that's a red bar to indicate that some of the tests didn't pass. The auto-test feature, when checked, will run the tests each time a file is saved in the editor. When auto-test is unchecked, then the Run Tests button will kick off the unit tests manually.

Basically, my remaining to-do list is as follows:
  1. make the tree nodes expandable and collapsible,
  2. handle error reporting properly (whatever that means I haven't decided ... hover over a node to see a tooltip? ... double-click to get a dialog with the error message? I'll probably try both and see which style I like.)
  3. run nose in a background thread so that it doesn't freeze up Komodo while the tests are running.
  4. test on both Linux and Windows to see that things check out. (I'll be looking for a volunteer with a Mac as I get closer to release.)
The last, detail stages of the project always seem to be the hardest, so I'm posting to encourage myself to "press on toward the goal". Also, I was curious if other Pythonistas in the testing community would be interested in my extension.

It will probably be another two to three weeks before I finish since this is definitely a part-time project. I'll keep everyone posted.

Labels: , ,