You'll probably find nothing of interest here. But in case you decide to stick around, you'll find mostly tech stuff, maybe a little other stuff about what I think or feel, maybe I'll throw in a haiku or two before we're through.
My name is Titiimaea Filmore Galumalemana Vaiinupo Ala'ilima. I am a software engineer and technical architect. I live in Greater Boston with my gorgeous and talented wife Julie, and my amazing kids Sean and Jeannie. Welcome.
Any system worth its salt is going to need some pretty intricate testing to verify it does all the wonderful things it's designed to do. But hand-crafting test cases is tedious, brittle, and prone to masking your presuppositions about what will work and what might break. Auto-generating data takes care of a lot of the grunt-work, but how do you figure out what to look for at the end if you're not explicitly defining the input and the expected output?
I've written elsewhere about Lean software practices, but I'm actually going to take on a different meaning of the word today. You may, like me, be presented with a large heap of old code, some of which reeks so thoroughly of rot as to make the gods on high spew their ambrosia. How to clean these Augean stables might seem a Herculean task. However, turning the course of the river can actually done bit by bit, in fabulous Lean fashion, to deliver incremental benefits that move you closer to your end goal.
I've been doing a lot of work in Python of late. There's a lot to like about it. List comprehensions were a bit odd to work with at first, but they have certainly grown on me. Nice baked-in laziness capabilities. However, there's something essential about Python that bars it from ever becoming my tool of choice. I have several characteristics in common with Larry Wall, among them a love of linguistics. And just as that influenced his development of the Perl language, it impacts how I view other programming languages.
A recent discussion on Slashdot brought up the question of whether or not process is killing passion in the best software developers. The original post on which the Slashdot discussion is based made some good points, in particular that process easily runs amok and enslaves those whom it purports to help. The chorus of jeers from the Anonymous Cowards soon joined in to decry all manner of process.
I have what might be regarded as an extreme allergy to repetition. Once in a job interview I used my desire to "end repitition in our lifetime" (hereafter "ERIOL") sorta like a campaign slogan. (My interviewer pointed out the irony of using that phrase multiple times within the interview. Sadly the techniques I will discuss here are not available in everyday speech. However, lawyers use the "hereafter" trick above all the time in contracts to define shorthands to be used throughout.)
So you've built out your unit tests with mocks and everything is looking peachy. But the next thing you know you have to extend a class here or there, tweak a little functionality. Maybe the cases that you so carefully mocked are suddenly no longer valid. Or maybe a few assumptions crept in that never really are valid in the first place. If your test suite is comprehensive enough you'll certainly catch it eventually, but possibly only after a monstrous cascade of test failures that don't make it clear where the real problem is. How can you guard against this sort of class-mock drift?
Here's a situation I often find myself in: I'm writing two routines that share essentially identical structure and differ only on a few values. The obvious DRY approach is to put the common stuff in a single subroutine and the specific stuff in two wrappers. Simple enough.
Every now and then, you want to be able to do certain things if you're inside a transaction that you wouldn't otherwise do, or conversely do some things only if you're not inside a transaction. MySQL doesn't give you a simple way to do that. You might think just checking the value of
@@autocommit would do it, but no such luck, because that doesn't work if the transaction was started with
start transaction (or one of its aliases, e.g.