We used to build software like a crappy banana split stand. Grab the banana off the shelf (which probably is about to expire), throw on ice cream, cover it in chocolate, add some cherries, whip cream, nuts, stir it up, put a spoon in it, hand it to the customer, take their money, and let them walk away.

STOP THAT RIGHT NOW!

Stop the gargantuan effort up front, stop compromising the quality of pieces that don’t get seen, stop making your customer wait til the end of the project.

Find a beautiful banana and show it to your customer. Let them take a bite. That might be all they need. Or they might want to take a small piece of it and try it in banana bread. They might not like that. But that’s OK, because we have lots of time and lots of banana left. Take the next piece and make a banana smoothie for them. Maybe add a strawberry for the next sip.

Aaron Oliver might suggest that a good time to have these tastings is right after your daily stand-up.

Let your customer be involved at each step. Let them help you make the right changes early and often. Be agile. Don’t be the hobo behind the bad banana split counter.

That is to say: do one thing, do it well.

Decorators (not to be confused with the decorator pattern) can add behaviors or side-effects to a method, and this can be dangerous. It seems harmless, because by adding a decorator, you’re likely taking boilerplate code and shuffling it elsewhere. However, they often encourage badness because of how easy it is to add these behaviors.

On testing decorated methods:

Adding an @decorator to a python object unarguably makes the undecorated code difficult to test in isolation. Decorators are applied at compile-time, and cannot be mocked or made to not-execute without some pain.

There are certainly a few common tricks that can help test a decorated method with minimal side-effects, but they require changes to the decorator itself. There’s just plain and simple no way to un-decorate a method for isolated testing.

Let’s look at a few common examples:

@expose: register a URL for a view function in a web framework

class BlogPostController(object):
    @expose("/blog/{post_id}")
    def index(self, request, post_id=None):
        """ show a blog post """
        post = adapter.get_post(post_id)
        return render("show_entry.html", dict(post=post))

Without the `@expose`, your `show_entry` knows how to get a given post and render it in the proper template. With the decorator, it also now knows which URL corresponds to that. You now have multiple reasons for this block of code to change, including pointing to a different URL or using a different template. It’s preferred to have a separate module for managing which urls point to which views.

Harm factor: low. Ick factor: medium – high.

@cache: try to get the result from memcache, otherwise, execute the function and stick it in cache for next time

class PostAdapter(DataAdapter):
    @cache
    def get_post(self, post_id)
        """ grab a blog post from the database """
        return self.query(Post).filter(id=post_id).one() # SQLAlchemy folks need to talk to Mr Demeter...

OK this seems cool right? You only hit the database when you have to, otherwise we get it even quicker by looking it up in the cache.

What happens if you want to disable caching? A separate cache abstraction layer would reduce volatility in your data adapter.

And what does the unit test look like?

class TestGettingAPost(object):
    def setup(self):
        self.query = Mock() #don't hit the production database!
        self.post_adapter = PostAdapter(query=self.query)
    def test_getting_a_post(self):
        assert self.post_adapter.get_post(123)

Damn, there’s no way to mock out the @cache decorator so it doesn’t run. Try to, I dare you. You’re likely going to actually get post 123 from your production memcache. Crappy. The only thing you can do is make the @cache grab the cache implementation from the PostAdapter instance (and mock that out in you test), or find some other sneaky way of disabling caching for test runs. But the @cache decorator isn’t all self-contained and fun anymore.

Harm factor: medium – high.

@validate: Make sure the request matches the specified schema, otherwise hand-off to error handler

class EditPostController(object):
    def _save_error(self, request, errors):
        """ @validate decorator kicked flow here, redisplay edit page with errors """
        ...
    @validate(schema, error_handler=_save_error)
    def save(self, request)
        post = self.schema.to_python(request.params)
        self.post_adapter.save_post(post)
        return redirect("/blog/{0}".format(post_id))

Without this @validate, there would be a lot of boilerplate code inside the `save` method. With it, any unit test for the save method will be likely linked to your schema. You’d have to make an actual valid request in order to test this method. That’s outside of any tests for your schema directly. That means double-coverage but 2 tests to update when requirements shift.

Harm factor: low-medium

Conclusions (or tl;dr):

As easy as it is to become infatuated with Python decorators, they definitely encourage you to violate the SRP. This can create a myriad of problems:

• Difficultly in isolating system under test
• Added complexity to enable testing
• Redundant redundant unit tests
• Making a code module more volatile than it ought to

They still have some valid use cases and can lead to cleaner code, however, as Master Yoda once said, “when you look at the dark side, careful you must be…”

My favorite driver is an outspoken dutch guy. He’s quick on the wheel and if he doesn’t get the idea I’m trying to convey to him he’ll just type something to try if that works. When he does get what I’m mumbling it’s on the screen faster than when I would have typed it myself, so it doesn’t give me time to get frustrated over things not being like the would be when I had the keyboard. And that gives me time to look for exits and pittfalls.

He also dismisses anyone that tries to say pairing isn’t as effective as coding solo.

No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. … If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.

My biggest stumbling block to date has been the ratio of time driving to navigating when you’re pairing a senior and junior dev. Trying to balance productivity and mentoring isn’t always easy. I find allowing the Sr. dev to drive 2/3 of the time and Jr. dev to drive 1/3 strikes close to the optimal balance. Any more driving for the Sr and you’ll lose the Jr entirely as he rides along for the tour. Any less and you lose valuable time in guiding-by-doing.

Whether you’re the driver or navigator, take your role seriously. Share in the responsibility and help foster a mutual respect for the other.

No worries, we can easily add the parter repository, then install Sun Java.

sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
sudo apt-get update
sudo apt-get install sun-java6-jre

Once completed, the Aventail VPN installation can proceed.

tar xf AventailConnect-Linux.tar
sudo ./install.sh

If you did attempt to install Aventail using the OpenJDK, you’ll need to uninstall it and re-install after installing Sun Java. See /usr/local/Aventail/uninstall.sh.

Chad had high hopes early. He bought the truck on a whim and, without too much inspection, figured it’d be a few month job to get it on the road again. Needless to say, months passed, and it was still in his dad’s garage. Life (and college) got in the way, and the truck sat abandoned for several years, with only an occasional wrench gracing it’s steel.

He’d buy new parts from time to time, and store them away to be put on at a later date. He’d spend the occasional weekend tearing something off, grinding on it, patching, and welding. Tearing off one part would show deeper damage. This was Chad’s baby, and he couldn’t simply mask that damage, so he’d plan to fix the next issue before continuing, or order another new body panel. Little visible progress was made, but lots of hours and dollars were invested.

Finally, 3 weeks ago, after lots of pressure from his friends and family over the last few years, Chad took the truck out of storage at his parents 2 hours away and brought it to his own garage. He’s got a reinvigorated passion to get this thing running, and I’m excited to help him.

Some of these challenges sound familiar to software veterans, but are any analogies actually relevant?

Consider for a moment that you’re assigned to a project that requires you to migrate an existing web application from Java+Oracle to PHP+MySQL. Doing rewrites of applications can often be driven by a desire to consolidate platforms and reduce costs, and there is often a fixed timeline. The project is locked and loaded, and you haven’t had time to do technical due diligence.

You dive right in without much planning, and before you know it, you’ve passed your deadline. You got hung up digging into the guts of the old software. What little new code you were able to write relies on features that your new database doesn’t have, but you didn’t realize because you were testing against the old one.

What has agile software development taught us that can right this project-gone-bad?

It would be a stretch to suggest the core tenets of the agile manifesto are entirely applicable. There really aren’t any processes/tools getting in the way, he’s not held up by a desire to document everything about the truck, contract negotiation doesn’t matter, and he really doesn’t have much of a plan that would inhibit responding to change.

However, the principles behind an agile team can be very useful to this situation.

• Rapid, continuous delivery of a useful software truck.  Don’t worry if, for example, the interior dome lights aren’t working right away.  But let’s get it running, and make sure it’s poised to keep getting better.
• A working software truck is the principal measure of progress.  Not how many new body parts got ordered off ebay, or how cool the sketch of flames on the doors might look.
• The project truck is built by motivated individuals, who should be trusted.  The friends that help need to be committed to the goal.
• Continuous attention to technical excellence and good design.  Don’t rush it.  And avoid duct tape.
• Simplicity.  One of the beautiful things about old cars is how few moving parts there really are under the hood.  Don’t ruin it by adding flamethrowers to the exhaust or an automatic transmission.
• Regular adaptation to changing circumstances.  Expect that we’ll uncover a few unanticipated problems, but be ready to figure them out and keep charging forward.

Chad is a perfectionist, and he’s not in a rush to get this thing done. However, we have made some progress already in the last few weeks. Here’s where we are now: most barriers to working on the truck have been removed, we’ve started a “spike” of work to get the motor close to starting, I’m going to help put together a prioritized list of features (similar to user stories), and we’ll identify incremental milestones along the path to winning car shows.

With any luck, we’ll get the motor fired up after our first sprint. And maybe, just maybe, I’ll learn something along the way that can help us develop better software!

Photo courtesy of chicanerii on flickr

What works best in a nursery?

Eh. Doesn’t really do it for me as a blob of color.

How about on a link? Well, that is actually quite pleasant against a white background.

Regardless, the takeaway from the whole story isn’t that you should switch all your colors to #0044cc, but rather that you need to rigorously test your audience and be able to make changes based on the observed behavior. Having the discipline to carefully react to the measurements can and will drive success.

I’m still looking for lots more goodies. I have yet to find the perfect off-road running stroller, and I’m a bit disappointed by the selection of baby snowboards, but I’ve got a few more months to sort it all out.

Here’s some of the clothes and gear I’ve found so far…

Nerdy T-shirts:

Exothermic reaction t-shirt – clevercuties.com

Bibonacci t-shirt – clevercuties.com. The nerd in me cannot resist something this awesome.

Big boys clothes in little man sizes:

Baby track suit – Nordstrom’s. Oh heck yes, he gonna be a soccer playa!

Baby Chuck’s – zappos.com

Outdoor gear:

Full-face helmet – nybikergear.com. This is a prerequisite for the snowboard, dirt bike, skateboard, and baby sky-diving outfit that he’ll be donning after a few months.

Kid in a bag – rei.com. Before he’s able to walk, he’ll be able to tag along on hikes. Throw him in a bag on my back and off we go. They even sell sun visors and other accessories.

Snowsuit – backcountry.com. He’s gonna be the hippest kid on the slopes for sure. Gotta look good, especially considering he’ll almost certainly be the youngest person to ever bust a double cork.

It provides two methods that you can use in your code, isVisited and isAnyVisited.

One important note about your URL specification is that you must specify an *exact* URL that the user has been to. So, for example, if someone has visited several twitter profiles, but never actually went to the homepage or signin screen, then it would be difficult/impossible to tell whether or not they were a twitter user without a massive brute-force query.

You can download sniff.js, or view a demo.

Sample usage:

dojo.require("mdg.sniff");
var usedYahoo = mdg.sniff.isVisited("http://www.yahoo.com");
var usedGoogleMaps = mdg.sniff.isAnyVisited([
      "http://maps.google.com",
      "http://maps.google.com/maps"]);
var usedFacebook = mdg.sniff.isAnyVisited([
      "http://www.facebook.com",
      "http://www.facebook.com/index.php",
      "https://login.facebook.com/login.php"]);

Source code:

dojo.provide("mdg.sniff");
 
//
// Browser history sniffing, based on infamous blog post:
// <http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html>
//
// Sample usage:
//
//    dojo.require("mdg.sniff");
//    var usedYahoo = mdg.sniff.isVisited("http://www.yahoo.com");
//    var usedGoogleMaps = mdg.sniff.isAnyVisited([
//          "http://maps.google.com",
//          "http://maps.google.com/maps"]);
//    var usedFacebook = mdg.sniff.isAnyVisited([
//          "http://www.facebook.com",
//          "http://www.facebook.com/index.php",
//          "https://login.facebook.com/login.php"]);
//
// Works with Dojo 1.3 and 1.4 (*may* work with 1.2 as well)
//
 
dojo.require("dojox.html.styles");
 
(function(){
 
    var _this = this;
 
    this.sniffCache = {};
 
    dojox.html.insertCssRule(".dojohistorysniff a", "color:#000000;");
    dojox.html.insertCssRule(".dojohistorysniff a:visited", "color:#ff0000 !important;");
 
    this.isAnyVisited = function(/*Array*/urls) {
        for (i=0; i<urls.length; i++) {
            if (_this.isVisited(urls[i])) {
                return true;
            }
        }
        return false;
    };
 
    this.isVisited = function(/*String*/url) {
        if (typeof(_this.sniffCache[url]) != 'undefined') {
            return _this.sniffCache[url];
        }
        var link = _this.addLink(url);
        var color = new dojo.Color(dojo.style(link, "color"));
        if (color.r == 255) {
            _this.sniffCache[url] = true;
            return true;
        }
        _this.sniffCache[url] = false;
        return false;
    };
 
    this.insertSniffDiv = function() {
        return dojo.create("div", {className: "dojohistorysniff"}, dojo.body());
    };
 
    this.getSniffDiv = function() {
        var divs = dojo.query("div.dojohistorysniff");
        if (divs.length > 0) {
            return divs[0];
        }
        return _this.insertSniffDiv();
    };
 
    this.addLink = function(/*String*/url) {
        var div = _this.getSniffDiv();
        return dojo.create("a", {href: url}, div);
    };
 
    /**
     * mdg.sniff.isVisited
     * Check whether or not a URL has been visited
     * @param url String
     * @return boolean
     */
    mdg.sniff.isVisited = this.isVisited;
 
    /**
     * mdg.sniff.isAnyVisited
     * Check whether or not *any* of the URLs specified have been visited
     * @param urls Array of Strings
     * @return boolean
     */
    mdg.sniff.isAnyVisited = this.isAnyVisited;
 
})();

I’ve cleanup up that sample code and tucked it into a script. You can pass a list of files to the script, and it will apply a sepia effect to each, making sure to backup the originals.

#!/usr/bin/python
"""
Apply sepia filter in batch to images
 
Usage:
    python batch_sepia.py [--no-backup] file1 [file2] ...
"""
 
import Image as PIL_Image
import shutil, os
from optparse import OptionParser
 
 
def open_image(filename):
    """ grab a PIL image from the given location
    """
    image = PIL_Image.open(filename)
    image.load()
    return image
 
def save_image(image, filename, quality=95):
    """ save the PIL image to disk
    """
    image.save(filename, "JPEG", quality=quality)
 
def make_linear_ramp(white):
    """ generate a palette in a format acceptable for `putpalette`, which
        expects [r,g,b,r,g,b,...]
    """
    ramp = []
    r, g, b = white
    for i in range(255):
        ramp.extend((r*i/255, g*i/255, b*i/255))
    return ramp
 
def apply_sepia_filter(image):
    """ Apply a sepia-tone filter to the given PIL Image
        Based on code at: http://effbot.org/zone/pil-sepia.htm
    """
    # make sepia ramp (tweak color as necessary)
    sepia = make_linear_ramp((255, 240, 192))
 
    # convert to grayscale
    orig_mode = image.mode
    if orig_mode != "L":
        image = image.convert("L")
 
    # optional: apply contrast enhancement here, e.g.
    #image = ImageOps.autocontrast(image)
 
    # apply sepia palette
    image.putpalette(sepia)
 
    # convert back to its original mode
    if orig_mode != "L":
        image = image.convert(orig_mode)
 
    return image
 
def convert_image(filename, make_backup):
    """ convert an image at the given path to sepia tone.
        @param filename
        @param make_backup - if True, will copy original file to file.bak
    """
    if not os.path.exists(filename):
        print 'Skipping %s' % filename
        return
    print 'Processing %s...' % filename
    if make_backup:
        shutil.copyfile(filename, '%s.bak' % filename)
    save_image(apply_sepia_filter(open_image(filename)), filename)
    print 'Done.'
 
def convert_images(files, make_backup=True):
    """ convert the list of filenames to sepia tone.
        @param filename
        @param make_backup - if True, will copy original file to file.bak
    """
    map(lambda f: convert_image(f, make_backup), files)
 
 
if __name__ == '__main__':
    parser = OptionParser()
    parser.add_option("-x", "--no-backup", dest="no_backup", default=False,
            action="store_true")
    (options, files) = parser.parse_args()
    convert_images(files, make_backup=not options.no_backup)

You can execute this from the command line as:

$ python batch_sepia.py image1.jpg image2.jpg image3.jpg

If you want to recursively apply the filter to a bunch of images, you might consider mixing this with some find/xargs-fu:

$ find $HOME/pictures -name "*.jpg" | xargs python batch_sepia.py

Once you’ve got your photos in order, head over to photoworks.com to get them printed!</shameless-plug>