Life without Caffeine . . .

I had to give up caffeine, fizzy drinks, and a few other pleasant things a few months back because a Doctor told me I am getting old (I had no idea!), and that has revealed some things about myself I wasn't entirely ready for.  For one, I rely WAY to much on caffeine, and it wasn't easy to get it out of my system.  I was irritable for a few days - like I usually feel when I take in too much caffeine.  Secondly, without being able to just drink a cup of coffee (Bleh!!) or, better yet, a Doctor Pepper, to get me past the afternoon, I now have to manage my biology in an entirely different way.  For one, I have to sleep (What a concept!), and when I hit a dip in the afternoon it's a reminder that I am not getting enough sleep, and correcting that is no small task.  Gone are the late nights working after the kids go to bed in the solitude and serenity of the living room - a time which formerly was my most productive for working on open source projects and other things I didn't have to actively account for my time to anyone.

In my case, just stopping the caffeine was an unworkable solution - unless I am okay with my evening commute inevitably ending in a fatal accident due to exhaustion.  I feel so much better not ingesting all the sugar and caffeine and other toxic crap that soft drinks and coffee bring (I've never cared for energy drinks), but it is more than just a change in drinking habits - it's really a change in how you manage your body.

Be Systematic

Years ago when my children had cousins who were into such things, I heard a cheer (ad nauseam) which went like this:

Be, Aggressive!B-E, Aggressive!B-E AGG-R-E-SS-IVE Aggressive!

While being impressed that you could effectively get a 7-year old to spell 'Aggressive' by putting it into a catchy cheer, a parallel occurred to me from my own experiences.

Be, Systematic!
B-E, Systematic!
B-E Sys-t-e-matic Systematic!

Some background.  In my career, one of the most frustrating things I have encountered  happens when trying to brainstorm a problem.  It usually goes something like this (in a group setting):

Facilitator:  So, the widget is failing every day.  Any ideas?
Suspicious Engineer #1: I suspect it is the hoozit of the whatzit.
Overconfident Engineer #1: Naw - it can't be that - the hoozit is finely-tuned.
Facilitator: Any other ideas?
Suspicious Engineer #2: What about the Ides of March?  It has been known to cause problems before?
Overconfident Engineer #2: Not anything I have seen.
Self-proclaimed SME and overall dominant personality:  I think it has to be muppets in the server room.
Facilitator:  I'll bet you are right!
All:  Let's go get those muppets!

The big problem here is the complete lack of discipline in testing conclusions and challenging assumptions.  The facilitator did the whole team a disservice by allowing dominant personalities (I.E., those with who make the strongest assertions) to squelch good ideas just by saying it isn't likely to be true.  A good facilitation of this sort of meeting should collect both pieces of information:  the identification of the problem area, and the likelihood (priority, or rank) that it is the culprit.

Instead of just throwing ideas around like clay pigeons and letting people take shots at them, the facilitator should collect all ideas and rank them according to the order the team agrees on, then test each idea in order.  This works not only on teams, but especially in individual work.  I can't count how many times I have been told by an engineer that the problem was identified, as well as a fix, but once the fix was done they discovered that either (1) there was an additional problem that hadn't been identified, or (2) the analysis was wrong and the fix didn't work.  This is terribly frustrating for a team - thinking a problem is fixed only to have it pop up again.  It is even worse for the team when the fix is reported and deployed to production only to have another team (usually production support, or worse the business users) report the lack of fix back to the team.

In conclusion:  follow the scientific method.  Observe and analyze the situation, make a hypothesis, test that hypothesis, then commit to work.  Challenge yourself.  Don't believe your own conclusions (let alone others) until you can see it (as close as possible - some problems in computer science just can't be observed - such as a rare race condition).

Why you should do assertions the way I don't want to do them . . .

I have heard people say things like "In unit tests, each test should pass or fail for exactly one reason."  Practically, this means there should only be one assertion per method.  Yeah, right.  I've done the math.  That's a friggin' big pile of tests when you could have 20 assertions in one method!  And who wants to think up that many good test names (because runtest0 will only go so far)?  Am I right?

So, I coded a test like this, because there were multiple assertion validations with one condition, E.G.,

void testSomething()
{
 stage(data);
 assert(reason1);
 assert(reason2);
 ...
}

That worked fine, and met my goal of being green and saving the planet by reducing the number of carbon-footprint bearing test methods.  Then I refactored something that I knew would effect this code.  Unfortunately, I had to do a lot of creative commenting just to get the crap fixed because the entire test wouldn't pass until all the assertions passed.  What a pain.

So, I guess there is something to that after all . . .

Test Driven ETL Development

I did a screencast showing how my team uses Test Driven Development to develop ETL code.  Here is the link:

Test Driven ETL Development

The presentation is a bit long because I discuss some of the theory of what we do and demonstrate the entire end-to-end process.

Siri, Punctuated

I have been a little tired of dictating text messages to Siri and having them come across bland - having no punctuation to speak of.  I would ask "How are you?", and she would transcribe "How are you."  On a hunch I tried speaking the appropriate punctuation and she picked it right up.

I tried:

Me: "Where are you.  Where are you question mark.  Where are you exclamation point."
Siri: "Where are you.  Where are you?  Where are you!"

Just for fun, I also did these:

Me: "Are you quote happy unquote question mark."
Siri: 'Are you "happy"?'

Me: "I picked up the kids semicolon they are very whiny."
Siri: "I picked up the kids; they are very whiny."

Me: "Are you colon happy comma unhappy comma or sad question mark."
Siri: "Are you: happy, unhappy, or sad?"

Anyway - pretty cool stuff.

This is on iOS 7 - not sure if it works elsewhere.

Maven assemblies with file permissions (modes)

I have this maven project which packages up some shell scripts and batch files in a plugin.  On the client side, they get extracted into a local directory where they can be used for various functions.  Long story short, I was a bit irritated that on windows the batch files are treated as executables, but on Mac OS X and Linux, they were simply text files, and had to be launched with:

sh etlunit

Granted this is not a big deal, but I was annoyed anyway.  So, I Googled and found a directive to the maven assembly plugin which supports setting the file mode.

<fileSets>
<fileSet>
<directory>src/bin/</directory>
<outputDirectory>bin</outputDirectory>
<fileMode>0755</fileMode>
</fileSet>

  </fileSets>

I tried that, and for some reason now my bin directory (created by the plugin) was inaccessible - it's mode had changed inadvertently - to 0000.  On a hunch I added the directory mode as well:

<fileSets>
<fileSet>
<directory>src/bin/</directory>
<outputDirectory>bin</outputDirectory>
<fileMode>0755</fileMode>
<directoryMode>0755</directoryMode>
</fileSet>

  </fileSets>

And now I feel much better about the universe.  I can add the scripts to the path or use:

./etlunit

It's little victories like these that make the Open Source Software world so much fun . . .

Revenge, Justice, Mercy and Grace

[Disclaimer - this blog entry is about the Christian doctrine of grace]

I heard an illustration by Pastor Doyle today which contrasted these four ideas. I thought it was very powerful.

Suppose a man breaks into your home and brutally murders your only son. Your response can fall into these categories.

You hunt him down in anger and brutally murder him, inflicting the exact pain he caused your son.  This is Revenge.

You hunt him down, but once apprehended you turn him over to the authorities for punishment. Once pronounced guilty, he is executed according to the law.  This is Justice.

You hunt him down, this time you forgive him and leave him to live in his guilt and shame.  This is Mercy.

As before, you hunt this man down, and having detained him you extend forgiveness, but this time you invite him into your home to live in your son's bedroom, take his place at your table, and become your legal heir.  You love him as an adopted son and he is called by your name.  This is Grace.

The point drives home for me when I think of myself as the brutal murderer.  It's easy to think of oneself as the victim - the one extending forgiveness - but in God's sight we are all offenders differing only in degrees.

Romans 3:22-24

So, it is God who extends grace to us through his Son, Jesus - He is the only one who has the right to.