My friend—Tim—and I gave a presentation at PyOhio on unit testing frameworks for Python. I’ve had the the slides and source on my Presentations page since we gave the talk, but now the talk is available online too! It’s always amusing to see yourself talk. :-)

Check out other PyOhio 2009 talks as well!

At my workplace, we like to follow an Agile development methodology called Scrum. Turns out there is a bit of an issue… most issue trackers don’t allow us to organize tickets the way we need to. We’ve been using Trac for a long time (before we started using Scrum), and it’s one of the few tools that pretty much everyone likes. I’ve looked at other issue trackers (Bugzilla, Jira, Scarab, Roundup, etc), but they’re either costly, too heavyweight, or just plain don’t do what we need them to.

So, several weeks ago, I decided I’d make a dent in getting us closer to an ideal situation. I created a Trac plugin that allows you to prioritize your backlog using drag-and-drop in your browser. On top of that, it shows milestones on the side, and you can drag-and-drop tickets onto them to assign them into that milestone. It makes laying out your priorities and assigning them into sprints (milestones) a breeze.

For the little bit of actual code that comprises the plugin, it was a long road to get there. I cycled through 4 javascript toolkits before landing on Dojo. I learned quite a bit about Ajax—although I’m certain I have more to learn, and had to reacquaint myself with Genshi. In the end, it all works rather well and I’m fairly happy with the end result. I did learn that I’m terrible at web design, so it doesn’t look quite like the picture I have in my head, but it works. :-)

If you’re interested, I’ve released the plugin on Launchpad as trac-backlog.

A number of you who follow this blog also know that I’ve been using photography as a creative outlet, and a way to let my mind work on other things that don’t end up as source code on a computer. One of the guys I’ve been following for a while is Zack Arias. He’s well known for his OneLight Workshop, and has an amazing story about he came to be the photographer he is today.

He was asked to be a guest blogger for Scott Kelby’s blog a while back. Instead of writing an article, he put up a video called Transform. Often we all wear masks, and never show what’s happening behind them… but not Zack. He let us know about his personal struggle, and made a motivational video to encourage folks to keep trying.

That’s sparked an email, which led to a blog post called How Many Of You Are Standing On The Dock?. The outpouring of response has been phenomenal. Zack and B really struck a chord with folks, and the amount of positive energy it has created is almost overwhelming. Story after story after story… Amazing.

But it doesn’t end there. A convicted felon, Derrick, ended up knocking on Zack’s door, and it turned out, he had something to share… Dope, Soap, and Hope.

I think we all have a story like this. There’s a step we’d like to take, but it’s so far off course from where we’re at it seems impossible to get to our destination. Check out the links above, and prepare to be inspired! There are tons of amazing stories in there!

I’ve gathered the pertinent links here, for your browsing convenience:

• Transform
• How Many Of You Are Standing On The Dock?
• Dope, Soap, and Hope

Just caught wind of this article. Turns out the need for software developers to optimize can give away information. Take a look at how this article shows you how to determine the right cookie based on a timing attack. Great stuff, and once again, shows the real need to understand a problem before you go coding up solutions.

My cousin and I have been pushing ourselves to do more photography. I wanted more of a playground than my site here (which is really for the fam). If you’re following this at all, and are interested, you can find some of my latest work on my Flickr photostream.

BTW, if you’re thinking about putting some pics online, or you’re looking to get more involved in photography, Flickr is a great place to share and interact with many other people in the same shoes. Occasionally, you run into folks like Ed McGowan who have been taking pictures for about a year, but has incredible style. There’s a lot of great inspiration up there, and many of the “communities” seem to be very positive.

TTFN!

Did you see it? Yeah, that was the world growing just a little bit dimmer, as one of the most amazing people in the world passed away after a long struggle with cancer.

Kristen was a person of rare form. She had more compassion than should fit into one individual, and such a zest for life. The positive energy that flowed out of her was immense, and felt by everyone. She was incredibly smart, and had a way with people that few could match. One of her most amazing qualities, was that she was herself. There was no mask, and no frills. What you saw was who she was, and she was incredible. She was genuine.

I doubt there are many people in the world who could have put up the fight she did against cancer. I doubt that any of us are living life with half the vigor that she did while being treated. I doubt that any of us will forget her, that smile, or that laugh as she exits the world. We’ll miss you Kristen.

Go Jackets!

Charlie Nutter was kind enough to update pickjdk.sh to look in the right place for Mac OS X. Get it here.

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?

I was browsing some announcements, and through a series of clicks, ran across Whoosh. Lucene is pretty recognized in the Java world as very flexible indexing and search framework. Whoosh appears to be doing that for the Python world. Occasionally, I’ve needed such a thing, but ended up writing my own lexer and indexer. I’ll have to keep this library in mind the next time a problem like that comes around.

My drive to and from work is anywhere from 20 minutes to 40 minutes, depending on the traffic (fortunately, it’s often much closer to 20 minutes). If you know me at all, then you know I hate to waste 20 minutes just driving. I need to feel like I’m doing something useful with that time. I often spend it listening to NPR, but I also spend quite a bit of the time listening to podcasts.

One that has consistently been useful and informative is Software Engineering Radio. Markus has pretty consistently struck interviews with a number of figure heads in the software world, and the interviews were pretty in-depth, on-topic, and very useful. He not only brings in folks to talk about technology, but also behaviors, management, and design. Recently, in Episode 131, Markus had on two authors of the book Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. It was an interesting interview with loads of useful information about both positive and negative behaviors they saw in teams and companies—I’m eager to get my hands on the book now. :-) Anyways, the moral of the story is this: it’s a great podcast that goes beyond just technology behind software but also talks about the business of software and it’s teams. If you have some idle time on the way to work, check out this podcast.

Glad to see that the documentation of how to use git with svn is finally becoming much more complete. If you haven’t seen the crash course, take a look: http://git.or.cz/course/svn.html

Recently, on the Bazaar mailing list, a question came up as to whether rebase would be added to the core. My gut reaction was to say “that’s a bad idea” (not that I have any real say on the matter). However, Stephen J Turnbull started chiming in with a few things to help stop the spread of FUD around rebase. In particular, this message sparked my interest.

There were two implications in this statement made in response to rebase not preserving history:

In git, it does, by construction. What it doesn’t preserve is the value of the ref.

The first implication is—at least in my head—If I can’t get to the old ref easily, then I essentially don’t have the history. However, that isn’t the whole story. In my mind, I had always pegged rebase as squashing the commits, which I would consider “destroying history.” Stephen’s statement, made me second guess that. To my surprise, the default behavior of rebase is not to squash the revisions, but to simply migrate your commits. The individual commits themselves are preserved. For me, that’s Good Enough. Yeah, it’s not the “original history”, but it’s still useful.

I still don’t know how I feel about squashing the revisions into just a single revision. On the one hand, if you went through several techniques before deciding on the final one, I kind of want to see that. On the other hand, if you history is just littered with stupid stuff (accidental commits and the like), well… I don’t really need to see that. I suppose that this is where you leave the choice up to the individual developer instead of setting on outright policy (after all, we don’t take away your hammer just because you might break your fingers with it).

FWIW, I really like git (and have for quite some time). It’s list of commands is enormous, but it really does give you quite a number of options in terms of how you’d like to work. I also really like Bazaar. The team has a great workflow, with peer reviews, PQM, and the sheer responsiveness. In the end, I expect that git will be my tool of choice for most personal projects. Bazaar will likely be the one I use most at work, because of the spectacular integration with Subversion, and because it has decent support for Windows. And I expect to be using Mercurial here and there, because that’s what Python has chosen. :-) However, Mercurial integration with Subversion is getting better everyday… so who knows.

BTW, thank you Stephen for encouraging me to take a closer look at rebase. Now that I understand it more, I definitely see its usefulness.

Update: FYI, you should be careful when rebasing and pushing your changes to a public location. It can cause some issues. Google ‘git rebase push’ to see some examples and read some blogs as to why.

Lightning talks are great. They communicate a tremendous amount of information in a short period of time, which is like candy for our brains.

One such talk was on a module called argparse. It’s meant to mimic optparse, but it also parses arguments (not just options) and helps validate them. Seriously, the idea is so simple that I’m surprised the original optparse authors—or myself—didn’t think of it. This one will definitely be finding it’s way into many tools that I write. Kudos to Steven Bethard for creating this module.