Developing Upwards

This week hasn't been great for my productivity. It has been a series of days overshadowed by a series of things coming up. Between standing in line at the DMV , computer issues, and today helping my brother-in-law with a very sudden move, it feels like typing is an unfamiliar act. (Unless its on the T-Mobile G1, which I'll be reviewing this weekend.) Today, I helped load a seventeen-foot U-HAUL truck, made a few last minute stops, drove said truck just over an hour south and helped unload it into a storage shed. I've never loaded and unloaded a complete truck in one day, in all the several moves I've made over the last years. I was always able to stretch them over two days, with a nice sleep in the middle. After all that, I had to drive the truck back to drop it off. I barely made it. My dear wife hit traffic on her way to pick me up, so I sat and I waited. I listened to the mechanic at the drop-off location declaring how "North Carolina is McCain country," w...

Just let these guys do it for you. My hats off to them for this contribution to the community. It is much appreciated and will find use quickly, I'm sure. I know I have some room for it in my toolbox. Hopefully, the changes will be taken back to the 2.6 line so that any bugfixes that come will help stock Python and the backport. So, if you don't follow 2.6/3.0 development you might not be aware of multiprocessing, the evolution of integrating the pyprocessing module into the standard library. It was cleaned up and improved as part of its inclusion, so its really nice to have the result available to the larger Python user base that is still on 2.5 and 2.4. Although some edge cases might still need to be covered, the work is stable quickly. Here's an overview incase you don't know, so hopefully you can see if it would be useful for any of your own purposes. I think, starting out, there is more potential for this backport than the original multiprocessing module. Thus, I ...

This is how to review Memiary in 5 easy steps: Forget what you did yesterday. Check! Decide that all problems can be solved not just with software, but by adding new software just for that purpose. Check! Get written about on the popular ReadWriteWeb so people find you. Check! Be nifty enough to grab someone's attention when they try out the new service. Check! Surpass a plain text file in convienience, flexability, privacy, and install base. Damn ! Maybe next time. The best way to solve a problem is to avoid needing to solve it in the first place.

Yeah, AppEngine has been around for a while. That doesn't make my general AppEngine article less timely. Hey, I don't just write about stuff because its hip. In a few months, I'll announce what Google Chrome means for the web landscape. Seriously. Although a lot of people believe Google App Engine is a very big thing and extremely important to the landscape of the web, I get the strong impression from outside the camp that its more of a toy, and I want to address that. As with my quick review of App Engine itself, its hard to make real calls when everything is still beta, but we're working with what we've got here. The people who see the real potential of App Engine feel it and the people who just think its neat Just Don't Get It . What is there to get that so many developers are missing and why would those of us that do think its important enough to be evangelical about, as I'm doing right now? Once again, making any claims or arguments in this discussion h...

In Part 1 I wrote about my method of testing the actual tag function for a custom Django template tag. I said I would follow it with a Part 2 on testing the rendering of the resulting Node . This is that follow up post for any of you who were waiting for it. Testing the rendering poses some more problems than our little tag function. Rendering is going to do a bit more, including loading the templates, resolving any variables in question, doing any processing on those results (like looking up a record from the database based on the variable value), and finally populating a new context to render the tag's template with. How do we test all of that, without actually doing any of that? This is the goal we're reaching here, for unittests. We want each test to be so specific that we test what something will do, without actually relying on those things it does. We aren't testing any of those things, just that our render() method does them. What can we mock easily? get_te...

This is an index of different articles I've written covering techniques for testing specific software components. The number is small, but will grow in time. Initially, expect a heavier lean towards Django topics. How To Test Django Template Tags Parts One and Two

I'm involved in a project that has gone for a long time without tests and everyone involved knows tests are rilly rilly important . There is a point where acknowledged best practices simply meets the reality of the development mind and it doesn't always work out like you'd hope. We know tests are important, but we need to resolve this ticket right freaking now . You understand. The point was reached that this just couldn't continue and the costs of fixing the same bugs over and over were way too obvious to ignore. Tests are now popping up for things we're fixing and new things we're writing. As it happens, I came across my first real need to create a custom template tag. Of course, I wanted to test it. So how do you test something that is so entrenched in the Django processing pipeline as a template tag? Incidentally, I'm just going to assume you either know all about testing and Django template tags or you can follow along just fine. Testing breaks ...

So, this was going to be a post about the Python module, subprocess. I'm a big fan of subprocess and there are a lot of problems that are easier to solve by using it. We reduce thirteen distinct facilities into one class. We reduce a diverse ecosystem of interfaces into one, uniform interface. The subprocess module is good, both by itself and as a symbol for what Python stands for. I won't be writing my original post about subprocess. It isn't that subprocess isn't important, or that I don't think I can express myself properly, but that it brought up something else I should write about right now: What should I write about? Is this a blog about software development or is this a blog about Python development? Does it need to be only one? I'm looking for my direction here. I'm not going to stretch this out, because if I do, you won't read it . And truth be told, I want you to read it. I want you to enjoy reading what I write. At heart, I am a writer. I take...

We learn to recognize a bad bit of code quickly as our code-fu grows. Arbitrary side-effects smell badly and crazy one-liners frustrate us. It becomes easier to identify what lines of a codebase you might want to clean up to improve the overall quality of the work. There is a line between codebaess with bad code in them and bad codebases. When do we learn to recognize this and what are the signs that the problem is far reaching, not localized? A bad codebase is an expensive codebase. It is difficult to work with and difficult to collaborate with others on. Identifying what makes a codebase bad is key to knowing when, where, and why to improve it. Improving the overall code quality reduces the overall code cost. I'm thinking about software in economic terms these days, and I'm hoping we can turn the recession to our favor by pushing the mantra Bad Code is Expensive Code . Costs of code come from three actions. Adding features costs, fixing bugs costs, and understanding costs. Ad...