I’ve been spending a lot of time lately on the Python Wiki trying to figure out if there is material, advice, basically anything that could help me start a Python Users Group. I happened to be running through an area trying to collect articles/useful information in a format suitable for conferences and user groups, when I ran across an article about embedding python. It’s actually a very good article, despite being 8 years out of date. And, to be honest it’s exactly how you would embed Python today, except you may want to use Py_InitializeEx() to keep Python from attaching signal handlers. I wish I knew of this article the first time I tried embedding Python. Might have saved me from reading a lot of source code.

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.