Entertainer’s May Sprint

Entertainer will be sprinting tomorrow and Sunday!

I think we’ve really settled into our new / not-so-new home on Launchpad. From Launchpad/Bazaar to Google Code/SVN to Launchpad/Bazaar again, we’re committed to use modern version control practices with Bazaar’s distributed version control, and we believe that Launchpad is the right tool for encouraging developer sharing. Launchpad has a lot to offer as it effectively manages the complexity of tying distributed version control with bug reports and features requests, and we want to make the most of that.

As for this sprint, I think the big push will be to land Paul’s Object Relational Model (ORM) in the trunk, and to replace our somewhat unwieldy database code with cleaner object interfaces from the ORM. Coupled with an initiative to use pylint to enforce good Python practices and standards, and unit testing for handling change, the codebase will really start to shape up as we move to a .1 release of Entertainer.

With some new recent contributors, Entertainer is really building up some momentum that will hopefully carry us far beyond this weekend’s sprint. Come join us tomorrow on IRC at #entertainer on irc.freenode.net and let us know if you can help out. I’m sure that there will be plenty to do.

Test Driven Development woes

I just finished reading Kent Beck’s Test-Driven Development, and, while I enjoyed the examples in the first half of the book, I’m disappointed about the lack of discussion on dealing with “legacy” code.

In my short amount of time using Test-Driven Development (TDD), I have seen that it can be a great, confidence building tool; and it has enabled the Entertainer devs to iron out some major issues in the code base (e.g., video thumbnailing was done entirely by Paul by following the TDD principles). However, I have struggled with retroactively applying TDD and unit testing to preexisting code.

I have literally lost sleep thinking about how to isolate tests and break coupling of existing classes. My hope was that Beck’s book would provide some answers. Instead, I got “There is a whole book (or books) to be written about switching to TDD when you have lots of code. What follows is necessarily only a teaser.” His “teaser” basically stated that there is a Catch-22 of “refactoring would result in errors because there aren’t tests, and tests can’t be written because the code isn’t refactored for it” (paraphrased). And his advice is essentially to try your best to break it. The entire subject gets about a page in the book. Thanks Kent.

Would I recommend reading Beck’s Test-Driven Development? Sure. It’s a good introductory read to understanding the core principles of “test-first” unit testing. The first half of the book offers some great, relatively simple examples that most developers should have no trouble following. The second half does disappoint, however, as it seems more like half-baked refactoring advice instead of tackling really challenging problems that could be addressed (like what to do with preexisting code or GUIs).

I’ll be reading Fowler and Beck’s Refactoring: Improving the Design of Existing Code next to see if I can get some answers to the questions that I desperately want; even if that advice is set outside of the unit testing/TDD mentality.

Scatterbrained development

Quite a few days have passed since any of the development team of Entertainer has committed changes to the trunk. I understand that everyone gets busy at times so there could be any number of reasons why things seem a little slow with Entertainer, but I thought I’d explain what I’ve been up to (aside from normal life events that pull me away from my computer).

I think I’ve been spinning my wheels, and I’ve been spinning my wheels because I’m trying too many different things. I’m pretty new to the open source development world, and there are tons of things to learn. I find myself exploring python, clutter, GTK+, glade, blogging, django, unit testing, etc. All of these things are great in their own right, but it’s distracting and I’m not getting my hands dirty with coding as much as I could or should. I just finished listening to MacBreak Weekly on TWIT, and Patrick Wilson, the drummer for Weezer, made an interesting comment about being “a mile wide, and one inch deep.” Eventually, I’d love to have a deep understanding of everything and be a mile wide and a mile deep, but for now, I think I’m going to scale back my exploration and focus on getting deeper with stuff.

I intend to shift my focus from trying to understand all of Entertainer now, to understanding the core by fleshing the testing framework with more unit testing code. I’ll finish up my issues that I accepted from our google code change tracker, and get to work on expanding test coverage.

In the future, when I’m more comfortable with my python skills and how the Entertainer source code functions, I may jump back into some other topics of interest (like clutter and how we intend to package our software). So, my advice to budding open source developers? Get out there and get a full feel for the field, but don’t get sucked into long winded tangents.

>>> print “Hello World!”

This is my first blog post, and since it’s my first post, I’d like to explain the purpose of my blog. My great adventure into the blogosphere will probably have a distinctive slant toward all things Python. I intend to journal my experience with my involvement on the Entertainer Media Center project. Entertainer is written in Python, a dynamically typed language that I’ve spent some time with over the last couple of months.

As someone who uses Perl for development in his day job, my brief impression of Python is amazement at its elegance and readability. Python has already showed me how easy stuff like unit testing and Test Driven Development can be. But that’s a subject for another post. I don’t want to drone on already, so I’ll stop here.

Thanks for reading.