So, in a previous post I said I’d likely chose git as my dvcs of choice. Well, it’s been almost 2 months and I find that while I’m very happy with the speed of git, it’s command line is more than I care to understand at the moment. I can get by with just a handful of commands, and on projects that are using git, I’ll do exactly that.

However, I’m really liking Bazaar, and the guys developing it and the plugins around it. QBzr is a spectacular front-end to Bazaar. I really enjoy being able to dig through the history, and it’s nice syntax highlighted views of source code. I also like the fact that I can write a plugin to extend the tool. I haven’t done that quite yet, but I hope to write one that’ll allow me to use a shorter syntax for referring to remote project urls. Plus, Jelmer is working integrating Bazaar with Mercurial (bzr-hg), and against git (bzr-git). So in the end, I can know one tool but work against any project of my choosing. If you haven’t taken the time to try out Bazaar, I highly recommend it.

Here’s a great article from Thomas Ptacek at Matasano entitled: Typing The Letters A-E-S Into Your Code? You’re Doing It Wrong!

I’m not a web developer, but I certainly understand having a nuanced problem like that of web security. It’s interesting to see the plethora of ways in which you can screw it up hard.

This is one of the talks that was presented at PyCon 2009. Ned walks you through examining how much code your unit tests actually cover. As we become more “testing aware,” a portion of the community is really starting to focus on numbers. In particular, 100% test coverage, as though it were some panacea. Ned points out how that is a fallacy, and shows a couple of examples of how you can have 100% coverage and still be broken (it’s the paths through your code that matter… and it would be nearly impossible to test them all). Ned’s talk isn’t the only one out there about this sort of thing, which is a Good Thing. There needs to be a lot of discussion about this so that we don’t forget that once we get to 100%, we can still do better.

You can find a pdf version of the slides here: http://us.pycon.org/media/2009/talkdata/PyCon2009/026/coverage.pdf

Just did a quick hack to make Python use native Mach semaphores for the GIL instead of the mutex/condition variable pair, and got sizable speed up (13%) on David Beazley’s thread test from his presentation (I have 4 cores instead of 2 though). Guess I need to create a patch to add support for it.

Got this via Twitter: http://www.dabeaz.com/python/GIL.pdf

Man, there is some good stuff in there. Thanks David. While you’re there, check out PLY. See the talk up on blip.tv.

Another great article appeared in the April issue of Python Magazine. This time it was written by Paul McGuire, author of pyparsing. The article is called Create your own Domain Specific Language in Python with imputil and pyparsing. It’s a fairly long article, but it walked through the steps of generating a language to describe state machines. The author used pyparsing to extend the Python language to add a state machine construct that is intermingled with real Python source code. He stored these extended source files as .pystate files instead of .py files, and then hooked the module import process with imputil to allow him to import .pystate files and have pyparsing automatically transform .pystate files into real python code.

More and more I’m realizing the power of these sorts of solutions. It was great to see an article bringing these tools together to do something very interesting, and non-trivial. If you haven’t subscribed to Python Magazine, you may want to consider it. There have been some really top-notch articles.

Just got my dead tree version of Programming Clojure by Stuart Halloway Friday, which reminded me I need to write a blog post about it.

Clojure is a functional programming language built on top of the Java Virtual Machine. The things that make it interesting:

• It’s a Lisp-style language, but it removes some of the parenthesis
• Has a different concurrency model that support transactions against variables.

The latter point is really interesting to me. I’ve spent a fair amount of my life near processors, because I do a lot of work that’s meant to run either in the kernel (device drivers) or because my work is targeting an embedded environment (either with or without an operating system). So I’m pretty familiar with the nuances and pitfalls of locking and synchronization. Clojure’s model could be a step in the right direction. I think it’s too soon to tell, but it’s pretty compelling.

Back to the book. I originally bought Programming Clojure as a Beta Book. Since then I’ve read the book twice more(!), and I must say, it was just as enjoyable reading it the third time as the first.

First, let me say it one more time for those who don’t know me: I do not have a Computer Science degree. I majored in Electrical Engineering, and my deep passion for computers and solving problems landed me in the computer science realm. That means I don’t have a background in data structures and algorithms, nor did I take a course that surveyed the wide and varying languages that are out there like so many computer scientists have to take as part of their curriculum. So, while I once wrote a bunch of lisp macros for XEmacs, I certainly don’t claim to understand all of it’s nuances and why some decisions were made the way they were.

However, Programming Clojure won’t leave you stranded. In fact, I found it to be quite the opposite. Imperative languages are so popular, that Stuart felt the need to walk through why a functional programming language is useful, how it fits into today’s world, and more importantly he walks you through the concepts step-by-step throughout the entire book. Programming Clojure felt as much like an introduction to functional programming as it did an introduction to Clojure. For some the more advanced folks who are fluent in a functional programming language, you might find this a distraction. However, I suspect more people are in my boat, and will find Stuart’s treatment of great benefit.

The book starts off with a basic introduction to functional programming and Clojure’s functional programming constructs. Since almost anyone who is looking at Clojure is probably looking to make use of the Java ecosystem, Stuart also shows off integration between Java and Clojure really early on. He continues throughout the book to build on key concepts of functional programming and lisp: sequences, lazy evaluation, and macros. He takes a break in between and spends a whole chapter on Clojure’s concurrency model: Software Transactional Memory. Finally, he finishes off the book with how to integrate unit testing (yay!), database access, and web development with Clojure.

The book is loaded with programming examples (that actually work!), so it’s very easy to follow the book and try things as you go. All you need is the Clojure jar, an editor, and you pretty much have everything you need at that point.

If I were more clever, I’d sign off with a Clojure snippet. Unfortunately, I’m not that clever when my son is sitting on my lap insisting on playing with the mouse. :-) I will say that the book is an easy read, and if you have an application that needs to be concurrent, consider reading Programming Clojure. Whether or not you end up using Clojure, I believe functional languages are closer to coming up with a much more usable concurrency paradigm than the current threading/locking scheme we have today. As I said earlier, Programming Clojure is as good an introduction to Clojure as it is functional programming, so why not start off with this book?