You hear dependency injection often mentioned in the context of unit-testing as way to break dependencies and providing seams for testing (a term that I think Michael Feathers coined in Working Effectively with Legacy Code).

I actually learned dependency injection years ago when working on a project where the requirements where constantly changing. As a result, what our product needed to do was changing pretty rapidly as well. Dependency injection allowed us to map out our interfaces, and wire the pieces together as we saw fit. Using the same basic components, we were able to adapt to the changing requirements simply by rewiring the flow of data. It was a remarkable technique when I learned it—which was through hard knocks rather than Design Patterns and the like.

Nonetheless, dependency injection is useful outside the context of unit-testing. Unit-testing just happens to be a common use for it. Make sure to take a look at the Wikipedia entry, as it includes a number of links to dependency injection frameworks that might be useful to your project… including Spring For Python!

So, one opinion I’ve upheld for a long time was the idea that you should feel the pain of your design decisions. Why? Simple: you learn about the consequences of those design decisions. On the surface, it may appear that you made some excellent trade-offs, while in reality it turned out to be less than ideal.

The same is true when it comes to testing. Far too many organizations take the “toss it over the wall and let the test engineers write tests” attitude. Some organizations even believe it’s beneath a developer to write test code. I, however, believe developers need to play a large role in testing, especially at the unit-test level. It’s far too easy to make a decision that severely cripples testability. Without feeling the pain of having to develop the tests, you lose the feedback loop that lets developers learn and write more testable code.

I was excited to hear that advice being offered by Misko Hevery in The Clean Code Talks — Unit Testing. He basically offers the same advice I did above. He also offers something else: how to proportion your unit-tests relative to functional and scenario tests. I’ve always struggled with that question myself. On the one hand, I want to ensure the product handles edge-cases robustly. On the other hand, we’ve invested a lot of time in unit-tests.

What Misko offers is this:

• Unit tests should roughly match the number of lines of production code
• Functional tests should be a much smaller set of tests
• Scenario tests should be really small

To paraphrase Misko: once you get into functional and scenario tests, it’s more about testing the wiring than testing functionality (despite the name functional tests!). These tests are ensuring that the output of one object can be fed into another. While functional and scenario tests help show that a project is functioning, it doesn’t do much to tell you where a problem exists so that it can be fixed readily. And I have to agree with that assessment. Having struggled with scenario tests, I can say without a doubt that without extremely deep knowledge of a system, it can be impossible to get useful information from a scenario test.

I hate to keep linking to GoogleTalks, but I got into blogging to share. So:

I’ve always been amazed by the human brain, and its capacity to learn. So when I ran across a video on Google Talks by Dr. Michael Merzenich on rewiring your brain, I had to watch it. If you’re at all interested in how the human brain works, then consider watching. I’ve linked it below for your convenience.

This story started years ago over some software for model trains. It looks like it finally went to court, and was a huge win for Free Software. The short form: open source licenses stand up in court. A company stole a developer’s work, patented it, and then tried to invoice the original developer. It’s really worth a read, and a huge win for Open Source licenses.

I’ve been trying to get my head wrapped around how the new comments framework is supposed to work in Django. Turns out, there are a number of interesting issues.

Errors are displayed on another page

It’d be much nicer to show errors inline on the form rather than on a different page. Forcing you to a different page means you lose context about where you’re at, and what you may have been responding to. The same is true for previewing. Currently, previews also place you on a different page, and if you decide to edit the content, you’ve lost the required context.

There is an undocumented feature that allows you to embed a redirect into the form

The problem here isn’t that it allows you to do the redirect, it’s that this feature is undocumented. That said, it’s not very useful. The reason being that when you post a new comment, parameter data is added to the URL. That information is carried over on the redirect, so you end up with cruft in your url. It doesn’t even buy you anything, like positioning the page to the comment you just added. :-( Seems like there should be a better way to do this, but I think I’m going to have to resort to writing my own view.

Isn’t documented nearly as well as it needs to be

For all the hype I’ve been hearing about how the new comments framework has so much better documentation, I’m a bit disappointed with what I saw. Actually, Django has done an awesome job with documentation—it does set them apart from the rest of the open source community in my mind. I don’t know what happened here, but the ball got dropped somehow. And yes, I’ll submit patches to help correct the problem, once I figure out some of the details.

I haven’t even gotten to the moderation junk yet. I have no idea how that works, because there is no documentation for it. :-) I was hoping to be a lot closer to having comments in-place by now. I hope that I’m just missing something and it all falls into place soon.

I was cruising through my RSS feeds when I ran across this snippet on Daring Fireball. Specifically, it was a link to this article about how Apple is dealing with the fact that it rejected several authors applications, saying:

Apparently, Apple has now started labeling their rejection letters with Non-Disclosure (NDA) warnings:

THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE

You know, I think Apple is a very innovative company, but it has this nasty habit of shooting itself in the foot. If they’d only embrace the community of developers, they’d rule the cell phone world. But no, they can’t do that. They insist on silencing criticism instead of realizing that this outcome is entirely of their own choosing. I was contemplating getting an iPhone when my contract was up. I think I’ll be choosing something else. This is the first time I can honestly say that I’m disappointed to own a Mac.

I was browsing around this morning catching up on a few things and ran across James Bennett’s presentation at DjangoCon on writing reusable applications. Very nice! A video of the talk is also posted on YouTube.

If you’ve been watching the django-developers list, you might have seen references to “I want a pony”. Looks like James responded in his own way… scroll down to the bottom and check out his Pony Powered site! :-)

Now that I’ve started to spend some time on my site capturing links and other tidbits, I’m realizing that my sidebar needs to be wider. There simply isn’t much room over there. I bumped the font size down by a pixel—any more than that and it doesn’t look decent. But frankly, I may revert that as well. I think I’m going to have to expand the area, and then I need to revisit how that affects the width of my code blocks. It might be worth the trade-off though.

There are many little tools/tricks/snippets of information that I use all the time. So I tried to capture these on a page here on my site: Snippets of Useful Information and Tools. I’ve only got a few of them up right now, but they’re the most useful ones, IMHO.

I’ve got this artistic streak in me that I’ve been figuring out how to channel for a while. I’d love to play music—and I still might give it a try, but I never played an instrument as a child. It feels like it would be an uphill battle. I like to draw, but stink at that. I love graphic design, but I’m not very good at that either and feel like I’d need formal training to really get there. So, after watching the Strobist guys for a year learning so much and seeing how many of them have developed, I decided to give photography a whirl.

Continue reading Trying my hand at photography…

As I mentioned earlier in the year, I got tired of Wordpress and it fighting me with posting code. So here’s the new site, rewritten using Django, Pygments, Python-Markdown, Static Generator, and the Django Basic Apps (just the blog portion). I also wanted the site to be more friendly presenting code, so I changed the main column to be wide enough to avoid having to excessively wrap the lines.

It took me much longer to write the HTML and CSS than anything else—and I still have more that I want to tweak! It also took considerable time trying to figure out a useful IT setup. As you can see by now, I’ve moved the site off of an old box in a corner to a VPS managed by SliceHost. I really like their setup, and if you want to use Django, then SuperJared has some wonderful tools and tips. In the end, I chose to use Nginx and a fastcgi backend for the blog. I was really hoping for an alternative to Gallery2, but I couldn’t find anything that worked the way I wanted and looked halfway decent.

I intend to make the code that drives this site open source. I haven’t quite figured out what my plans are on that front. I may end up hosting my own Trac instance, or using something like Launchpad. I have several projects I’d like to push out there though.

Oh, and I’ve revisited my comments policy and a colleague has all but convinced me to enable them. However, Django’s comments system was changed at the last minute, so I’m going to wait it out a little while longer while django-comment-utils catches up. Besides that, I need to style the comment forms and such.

I’ve done my best to preserve everything, and even went back and corrected a couple broken links in the original articles. I hope you enjoy the new site!

..since I’ve posted anything. I’ve been in the process of rewriting my site. I’m tired of Wordpress, tired of escaping code, tired of futzing with code to make it readable, and basically tired of Wordpress working against me rather than with me. So I took a look at other blogging systems… and none of them had all the characteristics that I wanted. So I’ve been busy in background developing my own using Django. This will allow me to write code in blogs much easier, and I didn’t have to jump through the pain of trying to design my own Wordpress template.

The other big change I’m going to make is moving this site to a hosting provider. This site is run out of a box in the corner on a machine that’s a number of years old… it’s definitely on it’s last legs. I’ve purchased a slice from Slicehost, and hope to be moving this site there in the not too distant future. I’m going to do my best to try and not break the RSS feeds… but I can’t make any guarantees.

I wanted a copy of my svnsync’d version of the SVN repo while at PyCon. It’s about 450MB (and it’s not up-to-date currently)… but it has quite a few files. In 20 minutes time, it only got about 60MB of data across the wire. I killed it and ran:

ssh host "tar jcvf - -C /path/to/parent dir" | tar jxvf -

and it was done in roughly 25 minutes. Nice.

Updated: fixed the args to the ssh tar command.

This has been sitting in the queue for a while, but didn’t publish it for some reason…

I got this link from Daring Fireball and saw something interesting in the comments section (Comment 19):

Now, I’ve worked on embedded devices—and if I ever had to say “Oh, you need to reboot your device periodically,” well, I would have been left in the cold. The simple fact of the matter is this: it doesn’t matter whether you’re running Mac OS X, or Safari, or anything else. The expectation needs to be that I can use this device all the time without having to reboot. That’s part of what makes embedded programming hard.

It turns out that by default, on Leopard, Python 2.5 looks at ~/Library/Python/2.5/site-packages for Python modules. The problem is that nothing installs there by default. However, distutils (and setuptools) will read settings from ~/.pydistutils.cfg allowing you to configure some default settings for the install and easy_install commands. After a little bit of work, here’s the final result:

[easy_install]

# set the default location to install packages
install_dir = $HOME/Library/Python/2.5/site-packages

[install]
install-base=$HOME
install-purelib=$HOME/Library/Python/2.5/site-packages
install-platlib=$HOME/Library/Python/2.5/site-packages
install-scripts=$HOME/bin
install-data=$HOME/Library/Python/2.5/share
install-headers=$HOME/Library/Python/2.5/Headers

Now I can worry less about what’s going to happen with my Python modules the next time I upgrade.

It was an exciting first day at PyCon. I met Ben Collins-Sussman, Brian Fitzpatrick (who is just as down to earth as he appears to be), Ted Leung, Steve Holden (Director of the PSF), and many, many other great contributors to the community.

I was completely beat at the end of the day, especially after spending several hours editing slides for a talk I’m supposed to give back home. I slept longer than I have in a very long time—which is refreshing.

So, I’m getting geared up for today. I’m particularly excited about Alex Martelli’s talk on callback patterns and idioms in Python and Jono DiCarlo’s talk on Python Application Development. And I’m really looking forward to meeting a few more people. So if you happen to read this, and you’re at pycon, look for me! Here’s a picture of me (with my two kids):

So, I bought IWork ‘08 the other day and started playing around with it. I was glad to see they fixed a couple of things with IWork ‘06—there was some bug with gradient fills and tables that ended up leaving a thin line of background near the top edge of the cell… but only when you printed or made the PDF.

One thing I was kind of excited about was seeing Apple’s spin on Excel: Numbers. So, being an engineer, I opened up to a blank worksheet, filled column A with 0-360, and column B with SIN(RADIANS(A[X]))—where X is the corresponding row in A, and then created a chart from column B. So this chart has 361 points in it—relatively small considering some that I’ve done in Excel where in upwards of 40,000 points. Well, with 4 processors and 5GB of RAM, Numbers couldn’t be responsive while doing anything with that chart. In fact, I tried tweaking the chart in a couple of ways and ended up crashing the application. Backing the number of points down to ~180 made things work much better. It was a little disappointing. It’s not out of the realm of possibility to want to use 360 or more points in a graph. Anything that involves daily costs, or maybe daily inventories, or… well, you get the idea. I hope the next version takes care of some of these issues. From an engineering perspective, I really need to see more.

Yesterday I was setting up a new VM under VMWare Workstation when I noticed that mouse grabbing was not working. Now I use my VMs extensively, so I expect this feature to work as it slows productivity when it doesn’t. After digging around, I found that the VMWare Tools installer hadn’t modified the xorg.conf to handle the mouse. It turns out that they released the Xorg drivers as open source and now they’re maintained by the Xorg team! So, in this case, I fired up Synaptic and installed the vmmouse input driver, modified the driver line in my xorg.conf to be ‘vmmouse’ instead of ‘mouse’, and restarted X. Tada! I now have mouse grabbing without having to start the vmware-toolbox.

So, I was at work yesterday, trying to troubleshoot a problem we were having with our customer’s build system. For some reason, we’re seeing make fail with a complaint about a missing endif—an error that they’ve never seen. So we proceed with the usual check of tools and found that we were using the same versions of everything. Same gcc, same make, same binutils, same everything… except the Linux distribution.

To make a long story short, we discovered that their build system does not support make 3.80, because 3.80 has a nasty bug that doesn’t allow you to use eval within a conditional. Fedora Core 4 patched make, and low and behold, it works on our customer’s system. However, my distribution—SuSE—did not patch make, and therefore, did not work. So much for supporting make 3.80.