I just recalled the end of a conversation I had with a fellow at a the Oakwood bar a few weeks ago. We chatted briefly, and upon parting ways he left me with:

Make it a great day.

Normally I would have thrown out my usual “later, hope you have a good one,” but his command was echoing through my ears like the roar of an animal I had never seen before. So I stood bewildered, pondering those words, as he walked away. He probably thought I was a jerk for not responding, but I honestly got stuck in a moment.

That closing instruction, “make it a great day,” leaves someone with a task. It reminds you that life isn’t up for grabs, you control your own destiny.

No matter what kind of day you’re having, you can always turn it around.

Here are 5 things you can do to change the direction of even your worst day.

• Exercise. Whether that’s taking a break from work to crawl on the floor and do 10 pushups and 20 situps every hour for a day, having vigorous sex with your partner, or taking a lunch trip to the gym, you can always find a way to get your heart pumping.
• Eat Healthy: It’s so damn easy and cheap to go to McDonald’s and grab a value meal. But what does that say about the value of your insides? That grade-E beef covers your arteries with more cholesterol than you could imagine and makes you pay for every bite. Instead, take a bag of oranges and a apples to work, munch on some carrots, eat a few hard-boiled eggwhites, and drink 10 glasses of water. You’ll walk away with your head held high and without suffering horrible heartburn and instant regret.
• Clean your Desk. Get rid of the clutter and spray something that smells pretty in the area. Get rid of visual distractions so you can focus on the task at hand.
• Learn a New Word. There are plenty of sites that will give you a new word every day. Find one you like and set it as your homepage. Or visit a random wikipedia article to get even more in depth.
• Hug Somebody. And hug them right. Squeeze them tight and take a deep breath to get the scent of their hair. If you don’t have someone that will let you do that without calling HR, I suggest you go to a bar, strike up a conversation, buy the person a drink, and 9 times out of 10 you can sneak in a good hug when leaving (and bonus points if you leave them with the message to Make It A Great Day)

I was reading Kill Zone by Gunnery Sgt. Jack Coughlin, and was struck by the personal mantra of one of the Marine snipers:

Slow is smooth, smooth is fast.

Even though lives are not usually on the line, it’s important in the software industry to understand that sometimes we shouldn’t rush around like chickens with our heads cut off. During your project’s crunch time, this is most important.

Slow down, take a breather, and think before you slam in a bunch of crap code. All the technical debt you create has to be accounted for by someone. Be the rabbit, not the hare.

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.