Geek Smithology

September 26, 2005

Listening to users considered harmful?

Filed under: Craft of Dev by Nathan @ 9:41 pm

I read a post over on Kathy Sierra’s blog that really hit a high note with me. Go read the article right now and come back.

Just in case you didn’t read the article, here’s a quote with the gist:

…we still assume that listening to real feedback from real users is the best way to drive new products and services, as well as improve on what we have. But there’s a huge problem with that — people don’t necessarily know how to ask for something they’ve never conceived of! Most people make suggestions based entirely around incremental improvements, looking at what exists and thinking about how it could be better. But that’s quite different from having a vision for something profoundly new.

True innovation will rarely come from what users say directly.

Oh my god that’s so true I almost peed myself. The (alleged) priority of my last company was to “build the brand.” The premier “brand building tool” was to become experts, champions even, in their business domain. There were Fortune 500 companies happy to outsource that part of their market research, but the company undercut its vaunted expertise by kowtowing to every client whim. Even when the client was clearly uninformed with ideas that could lead to misleading data. They also refused to admit that the company (a dot-com) could not succeed without a robust platform, but that’s another story for another time.

While there are bottom line concerns, several clients left because we gave them what they asked for, but it wasn’t what they needed. And to succeed, that is a distinction you must be able to make – the difference between what a client wants and what a client needs. Never ask a client with no domain knowledge (let alone expertise) “what do you want this report to look like?” Instead you ask “How do you want to improve your business?” Or (cribbing Kathy again) you need to look at each feature and ask yourself “How will this help the user kick ass?”

That is the kind of thinking that builds brands.

During the process of turning random client streams-of-consciousness into a reliable implementation blueprint, you need to crawl into every closet of the client’s business. Interview everyone you can about what they hope to accomplish. I can’t possibly frame it as perfectly as the pragmatic programmers, so again I quote:

Many books and tutorials refer to requirements gathering as an early phase of the project. The word “gathering” seems to imply a tribe of happy analysts, foraging for nuggets of wisdom that are lying on the ground all around them while the Pastoral Symphony plays gently in the background. “Gathering” implies that the requirements are already there — you need merely find them, place them in your basket, and be merrily on your way.

It doesn’t quite work that way. Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics.

Truer words about the requirements process have never been uttered. Your clients know only what they expect to accomplish, and if they knew all the details of how to implement it, why would they need you?

“But Nathan, client X wants everything their way, even if they are ignorant of the true consequences. What do we do about that, Mr. Smarty Pants?” That’s easy; you fire them! As Christopher Hawkins writes in his article 11 Clients You Need to Fire Right Now in the 09/05 issue of Software Development:

Sometimes it’s necessary to fire a client who started out promisingly, but is now offering diminishing returns – or devolving into downright bad business.

If you are building a brand on your expertise and a client is asking you to compromise your integrity for no other reason than because “that is what they want”, then they are not doing you (or themselves!) any favours, and you have to cut them loose, bottom line be damned. When you are in a position where you need clients more than they need you, your ship is sinking…fast! You must never confuse “the customer is #1″ with “the customer is always right”, because that way lies madness.

When you go back to your work, ask yourself “How does this help the user kick ass?” If there’s no compelling positive answer, the time to change is now!

September 24, 2005

Idiomatic means Readable

Filed under: Craft of Dev by Nathan @ 11:29 am

Caught a post on Foo blog with regard to code and the people that love it (or hate it, in this case) and review it. I have to say, the snippet was sick (in the non-ironic sense, like leprosy) There are a couple good points about good vs. bad developers and learning from your mistakes (a neat essay on exactly that can be found here.)

Today’s theory is that every language has a culture, a way of thinking, and a smogasbord of idioms that differentiate gurus from grunts, and that most people completely ignore this aspect of development. This condemns them to a life of mediocrity. They will become professionals, and they will make a living, but why play with the Monkees if you have a shot to jam with the Beatles? When you truly grok a language, only idiomatic code is readable and everything else is physically painful.

I’m gonna get right to some examples to show what I mean. This is gonna show up on javablogs, so I’ll do some Java, but I’m gonna switch it up at the end to show that some principles know no boundaries. The overarching thread between all of these examples is that it is not good enough for code to work. If it’s not succinct, idiomatic (and hopefully elegant) you’re making maintenance harder than it needs to be.

Here is an example of a Java method that works but that we would be embarassed to have written:

1
2
3
4
5
6
7
8
9
10
11
public class Foo {
    private String value;  // mutators cut for brevity

    public String toString() {
        if (value != null) {
            return value.toString();
        } else {
            return value;
        }
    }
}

Java developers will know that this does the exact same thing as:

1
2
3
public String toString() {
    return value;
}

..but manages to make the snippet harder to read. This probably evolved something like this:

  • Joe Developer throws a quick toString() method in, just using value.toString() because that’s what he always does
  • Sometime during the life of the code, an NPE was thrown
  • Rather than diagnose the problem (or, say, document it), Joe Developer tosses in a null check.

You can just feel the cruft growing while the windows are breaking. If you thought that kludge was egregious, here is to get a String in the format YYYYMM for the current day (ie 200509 for today.)

1
2
3
4
5
6
7
8
9
10
String period = "";
Calendar c = Calendar.getInstance();
period = Integer.toString(c.get(Calendar.YEAR));
String mon = Integer.toString(c.get(Calendar.MONTH) + 1);
if (mon.length() == 1) {
    mon = "0" + mon;
}
period += mon;
mon = null;
c = null;

To this day, the

mon = null;

and

c = null;

calls baffle me: there’s a superfluous Calendar, the developer uses a String instead of a StringBuffer, yet there was a need to “optimize” garbage collection with some explicit null assignment. If you were to review this code with the developer, they would get defensive and say “it works, so who cares?” But there’s also the future to think about, and this code is diseased: error prone and a maintenance nightmare.

Everyone knows that a hallmark of a Java guru is deep knowledge of the APIs – this is why when somebody says “Give me a book and I’ll learn Java in a week” they aren’t telling the truth, they’re telling me what I want to hear. This is why code standards and code reviews are so important. One of the things I’m trying to figure out in my own career is how to bring that to the forefront with clients, so that they care about it, and believe in paying a little extra now to save a lot later. I don’t have the answers to that one yet.

“And how would you write this code, Mr. Smarty Pants?” you ask. I dunno, how about…

1
String period = new SimpleDateFormat("yyyyMM").format(new Date());

Succinct, idiomatic, elegant. You don’t even need to know Java to figure that one out.

Time for one last example, this one in Perl. This is some code that checks to see if an array contains a certain element.

1
2
3
4
5
6
7
# $s is the string we're looking for, @a is the array to search
my $found = 0;
for (my $i = 0; $i < (scalar @a); $i++) {
    if ($a[$i] eq $s) {
        $found++;
    }
}

At this point, $found contains the number of times $s is in the array. Idiomatically written, this becomes

1
my $found = grep {$_ eq $s} @a;

If you can’t read that, you don’t know Perl.

If you want to rise to the top of your profession as a coder, you’ve got to dig beyond “it works” and learn about your language, its culture, and its quirks. There’s also the issue of really getting to know the platform on which you are developing, but that’s another story for another time.

September 23, 2005

Real World Problem Solving: A Memoir (Part the Fourth)

Filed under: Craft of Dev by Nathan @ 8:38 am

[Editor's Note: This is the final installment of a IV part series. Part I is here. Part II is here. Part III is here. And now, the thrilling conclusion...]

As part III closed, we had an applet looking for a class that didn’t exist when it was downloaded, but not looking when it was stored locally. I was pooched.

I took a break to clear my mind, but the applet was never far from my thoughts. We had the project status meeting and all I could say was “it still doesn’t work.” After the meeting broke, Eskimo Bill and I were going over the past two and a half days and he said “I still don’t see why it works locally but not over the ‘net.”

It hit me like a ton of bricks — the applet didn’t work locally.

The theory coming out of that discussion was that the WS client was having trouble deserializing the message and was looking for the Helper class to assist. But the applet still worked, and that put a few Roquefort mold holes in the theory. I cobbled together a quick log4j.properties file to put the applet into debug mode and watched the log.

Every time it went to get a Deserializer, it tried to grab a helper class three times before defaulting to a SimpleDeserializerFactory. So there it was, all we needed to do was define a deserializer for all the Java types and we’d be home free. Or not. How the hell do you namespace, define and map every single java type we might use in a way that doesn’t make the problem worse? It’s not feasible, and probably not even possible.

So I downloaded the source code for the web services and took a look. Sure enough, before defaulting to the default serializer, it looked for the helper class, which was just

1
Class.getName()

with _Helper appended as a convention. It tried this three times (with three different classloading schemes) and swallowed any ClassNotFoundException objects before defaulting. It was all coming together now.

When the applet was being loaded from the hard drive, it used a file system classloader. If there was a ClassNotFoundException, it got swallowed pretty much instantaneously and went about its business. However, if the applet was downloaded from the server, it used a network classloader. If the class wasn’t found locally, it did an HTTP GET to find it. And if it didn’t get it, it looked the next time. And the next. And so on…

Finally! I knew exactly what was happening, which lead to exactly what I had to do to fix it. Which leads to rule 6 (people who have worked for me will know this one well)

6) If you can’t explain why what you are doing will fix the problem, you aren’t fixing the problem.

Most systems that have been in existence for several years will have a lot of long standing, hard to understand problems. At one shop there was a report that would always crash the server on which it ran. I heard a lot of theories and people would come to me and tell me about them and I’d say “how is what you are explaining going to guarantee that what it happening won’t happen again?” Usually there was no answer, and they would not be allowed to put in their patch. And then, one day a developer (what the hell, I’ll let you know it was Le Fuchs) came to me and said “If a report is run for date parameters that are in different years, there’s a flaw in the datespan calculation logic that causes an infinite loop, and it crashes.” He showed me the code, and we put his patch into the next release. Isn’t it amazing how the true solution always seems obvious when you know what it is, but impossibly vague when you don’t?

So I made the required patch, applied it to the source code, and after copiously documenting the process and checking it into CVS, I had everyone test it. It worked (of course) and there was much rejoicing. I drank 1.42 litres of beer[1] and felt pretty good.

The rest is denouement. I don’t know anyone in their right mind that could’ve seen an UndeclaredThrowableException leading to a patch for the source code of a third party library. In retrospect, you can google for the problem (if you know what it is), but we had three people looking for various things and coming up dry: hindsight really is 20/20.

So as I close this down, I’d like to thank IDEA for a kick ass dev tool, JBoss for providing their source code, and DJ Pavo, DJ Shadow, and Fatboy Slim for providing the war music.

What a long, strange trip it’s been.

[1] On an uber geek note, you may recall I was using version 1.4.2 of the JRE. Yeah, I know…

Update
Based on a comment and a couple emails I’ve gotten, I’m updating this entry with how you can fix this problem if you have it:

There are two ways to fix this. First, if you are just using Axis and can upgrade, the problem has been fixed in version 1.3 (which just came out in the last couple weeks.) Second, if you are using JBoss 4.0.2 (as we are), you can go into the file

1
org.jboss.axis.encoding.ser.BaseFactory

and in the method

1
getMethod(Class clazz, String methodName)

, after the first attempt to get the method, it tries the _Helper bit.

Where it says

1
if (method == null)

, you can either comment out the entire branch (if you aren’t going to use helpers @ all) or you can use the same code Apache did in Axis 1.3 and change the if test so it reads:

1
if (!clazz.isPrimitive() && !clazz.getName().startsWith("java") && !clazz.getName().startsWith("javax") && method == null)

So that it doesn’t attempt _Helper class loads on any primitives or java library classes. Feel free to add any package names you want to exclude.

I don’t really like the “fix” – I’d rather see the _Helper stuff as an option that can be enabled/disabled based on whether or not you are using code that uses them, but I’m not a committer on the Axis project (yet :-) )

September 21, 2005

Real World Problem Solving: A Memoir (Part the Third)

Filed under: Craft of Dev by Nathan @ 9:57 pm

[Editor's Note: This is part III of a series. Part I is here. Part II is here.]

As the last part ended, our applet was trying to load the mysterious java.lang.String_Helper and coming up dry. Where was this class and how could we get it to our app?

Well, a quick look through every jar in our system (like I’ve said before, a good bash shell and related tools makes WinXP a tolerable dev environment) with this little bash script:

1
2
3
4
cd sdk
for i in $(find . -name '*.jar')
do jar tvf $i | grep java/lang/String_Helper && echo $i
done

…revealed that this class didn’t exist anywhere in the environment. And it couldn’t, right? Because it’s java.lang Which brings us to Rule #3.

3) When you know that something can’t happen, it can’t happen. Trust your knowledge and experience.

At this point, I dimly recalled that weren’t able to generate a strict JAXRPC mapping file for our web service code, because we had some fields of type “Object”, which could not be mapped. It felt like reaching (and it was), but it fit most of the data to say that perhaps the deserialization code was choking on the “Object” fields and trying to find a helper class. But that didn’t explain why downloading and running it locally worked fine, and I was breaking rule 4 of dev problem solving:

4) Any working theory must account for all known phenomena within the problem space.

And with this, I’m going to digress.

First, a short word on my state of mind: I had only slept about 11 hours combined over the previous three nights, and it seemed that every time I tried to think about anything else, the problem pushed it out and took over. I was dreaming about applets.

Second, every professional dev that has worked on non-trivial code (especially non-trivial, undocumented legacy code) has felt the ultimate low of getting lost and not understanding why something is happening. Either you don’t have enough knowledge, or you have enough knowledge but are losing confidence in it, but either way it doesn’t matter. It becomes tempting to Program by Coincidence, trying different things until something finally works. The problem is, you never know which change (or combination of changes) actually made the symptom go away (note I make a distinction between that and actually solving the problem!) And thus, rule 5 of dev problem solving.

5) Only formulate and test one theory at a time – don’t program by coincidence.

I tested the theory by refactoring the objects away and retesting the call. No dice, the server applet still wanted a helper class, and the hard drive applet still did not. I backed out the changes, and returning to first principles, I wrote a simple web service that took no parameters and returned a string. It too wanted a String_Helper.

There was another hail mary theory that it was a security issue, but a quick grant of all permissions in the java policy (also, all jars for the applet are signed) showed it to be false. I felt completely and utterly stymied. I had entered a maze with no exits and no cheese.

As a friend of mine would say, I was pooched.

September 20, 2005

Real World Problem Solving: A Memoir (Part the Second)

Filed under: Craft of Dev by Nathan @ 12:46 pm

[Editor's Note: This is part II of a IV part series. Part I is here.

Before I start, I want to clarify something based on a comment: the rules I'm presenting are not meant to be "skills" or "lessons", but rules. They may be rules based on lessons learned that require skill to apply, but they are rules nonetheless.

If they seem obvious to you, and you apply them in your work, congratulations, you are ahead of many of your colleagues]

As the last part ended, we had an applet that was trying to call web services, but throwing

1
java.net.BindException

in the process.

The exception message intimated that the bind error occurred due to the desired port being in use. One theory was that the WS client code wasn’t closing sockets, but it was eliminated immediately; if that were the case, running the browser on the same machine wouldn’t work either.

I had another developer deploy the build. It worked when browser and server were the same machine, but then something strange: it worked when I hit it from a remote browser. We had the d00d with the original failure and true to form, it failed for him again. Must be client related. A quick survey showed that I was using a Java5 JRE, and he had 1.4.0. And thus we come to rule #2 about dev problem solving.

2) Use the exact same environment as that in which the test failed.

This includes hardware, OS, browser, plugins, and versions thereof. If you can’t do that, then approximate as close as you possibly can. I installed a 1.4.X JRE and tried again and sure enough, KABOOM! Were we going to have to force all the users to upgrade to Java 5? What a nightmare that would be (and a big fat monster strike against applets, but that’s a whole ‘nother rant.)

So I grabbed some thread and jumped into the labyrinth after my socket minotaur. Monitoring the network traffic while loading the applet revealed that it was opening hundreds of sockets; eventually the machine would run out of legal ports and wrap the number, crashing in the process.

This meant it didn’t really work if the browser was on the same machine, but it was running quick enough so that by the time the port numbers recycled, those sockets were done doing their thing. We chalked up Java5 working to improvements in the JVM and the fact that under certain network loads, the applet could work. Depressingly, all we’d established was that the applet wasn’t working properly under any circumstances — what does an applet need with all those sockets?

I opened the JRE plugin console and turned on trace debugging (I would come to love my x and c keys) and saw that it was trying repeatedly to download a class called java.lang.String_Helper. Like, every time a String showed up in the code. There was talk that we were missing this class, but that’s impossible. You can’t create a class in the java.lang package — it won’t even compile. Yet, why would it try to load that class if it didn’t exist? And it was looking for other strangeness, like a long_Helper. As we pondered these questions of universal importance, the applet came up. The trace debugging had slowed the JRE down just enough that it could recycle sockets fast enough. That could only mean one thing: the applet didn’t need that helper class.

So I started up the Applet in the IDEA debugger and did not get any messages about helper classes. Eskimo Bill downloaded the applet HTML and all the jars to his hard drive, ran the applet in trace mode, and did not get any messages about helper classes. Zero. Zip. Zilch. Zydeco (oh wait, not Zydeco.) Empirically speaking, it seems that these classes were in the local environment, but were not part of the applet download.

The obvious answer was that jars were missing from the applet deployment, right?

September 18, 2005

Real World Problem Solving: A Memoir (Part the First)

Filed under: Craft of Dev by Nathan @ 9:51 am

[Editor's Note: I originally put this together as one giant post, but as I approached and then passed the 2,000 word mark, I decided to pull a Kill Bill and break it up into parts. Without further ado, here is part the first...]

One of the things listed in almost every developer job ad (on on every developer resume) is “problem solving skills.” But what does that really mean? What differentiates “good” from “bad”? As one side of what I think it means, I present a play-by-play of a problem I ran into, and along the way I compile a list of “rules” for dev problem solving. Let’s get it on!

As mentioned before, I lost a hard drive and whole boatload of work last week while refactoring an old school web service (and the applet that loves it) over the J2EE 1.4 school. I got a loaner laptop right away on Friday and proceeded to work on getting back to where I was. After a pretty crazy weekend (yes, I created a separate dev branch in CVS this time) I figured I was at even money: the applet was up and running. It was time to move on to the next thing after some quick verification testing.

And so began a week long saga of pain, misery, and torture.

It started out innocently enough. While the applet worked fine when the browser was on the same machine as the server, it bombed when the browser was remote. I’ve experienced several (too many, in fact) developers who would’ve gotten insulted at this point and dropped the infamous “it works on my machine” bomb, leaving everyone else to figure it out. This leads me to the first (of several) rule of dev problem solving:

1) If it works on your machine, but not in testing, staging, or production, it doesn’t work. Period. And it’s your responsibility to figure out why.

So I took a look and the exception was java.lang.UndeclaredThrowableException with a cause of java.rmi.RemoteException. WTF? Undeclared throwables come up when a method object is invoked and it throws an exception that cannot be matched to the throws clause of the method object (and is not a RuntimeException or Error.) A quick cruise through the offending code and I saw that every method being used correctly defined RemoteException in its throws clause. However, I also noticed an exception or two being swallowed. So I added some tracer bullets, threw up the exceptions, and rebuilt.

This time we got a much more informative, but equally puzzling exception java.net.BindException. This explained the UndeclaredThrowable exception – it was never declared, and was just bubbling up.

But why the bloody hell couldn’t we bind?

September 17, 2005

MP3otW – Deus by the Sugarcubes

Filed under: MP3 of the Week by Nathan @ 2:44 pm

In 2005 (maybe moreso in 1995) everyone and her dog knows who Bjork is, but back in 1988 not too many people knew about the Sugarcubes. I have very clear memories of listening to their first album, because it was so much different than choking down the latest Rick Astley turd on FM Radio. Deus wasn’t as popular a song as Motorcrash, but it struck a chord with me.

Deus does not exist
But if he does, he lives in the sky above me
In the fattest largest cloud up there.
He’s whiter than white and cleaner than clean.
He wants to reach me.

I think it kinda meshed with my own fucked up ideas about religion and god and how I couldn’t figure out why I didn’t think it sucked, but still wanted nothing to do with it.

In truth, I haven’t evolved too much on that front.

September 14, 2005

Microsoft is good at some things…

Filed under: Industry by Nathan @ 12:47 am

I know that in certain circles it’s de riguer to hate Microsoft. (Or Micro$oft, or Microshit, or whatever the 1337 Gates-haters are calling it today.) But in certain areas, they are obviously kicking serious ass – not only in terms of raw dollars, but the products themselves. I like Visio (yeah, I know MSFT bought Visio, but Google bought keyhole, so whatever.) And as much as I’d like to switch to Open Office, I just can’t stand to use it. And you know what else? I’ve even found that WinXP can be a tolerable Java development environment (provided you install a good bash shell and related utilities, like Cygwin) although I will never, ever prefer it to linux.

What’s the point of this? Just that Microsoft has unveiled some screenshots from the next version of Office, called Office 12. I think it looks amazing and I’m actually excited about it — far more excited than I am about Vista[1]. It sounds like they’ve actually listened to what some people don’t like, and from a usability/sexiness standpoint, it looks mighty fine.

If Open Office wants to get a share of any kind of mainstream pie, this is the standard to which they must rise. It doesn’t take precision instruments to measure just how huge the gap is at present.

[1] How many freaking versions does a product need, anyway? Apparently seven…

September 13, 2005

Eskimo Bill Says… (4 in a series)

Filed under: Eskimo Bill by Nathan @ 8:08 pm

…Telus can bite me.

MPAA doing the censor rag

Filed under: Sight by Nathan @ 6:06 am

I do not agree with what you say, but I will defend to the death your right to say it.

— Voltaire

The MPAA has told the folks behind the movie Saw II that they can’t use the original one shot poster they devised. Why? Because a couple o’ severed digits are standing in as the Roman Numeral for 2 and I guess they are too gross. If you think I’m going to link to this, you’re right. But first, let me say that a) It’s 163K, and b) if you get squeamish about fingernail pain, you might want to skip it. If you’re cool with that, it’s here.

Why this poster is unacceptable while it’s fine to feature Jennifer Lopez with her hips airbrushed smaller and her butt airbrushed bigger is beyond me. It’s the opposite of the films themselves, where you can get away with a boatload of death and keep your precious PG-13 but swear a couple times or show a boob and it’s adults only, baby. Has the MPAA completely lost its collective hive-mind?

Well, duh.

September 12, 2005

2001/09/11 + (4*(365d)) + 1d

Filed under: Personal by Nathan @ 1:18 am

Just read the 9/11 anniversary memories of another Canadian over on the Bliss Blog, and while I am not capable of that sort of evocative emotion or eloquence, I’ll twiddle the keys for a bit to eke out a quick memoir of my own. It rambles a bit, and arguably gets off point, but I promise there will be no haikus.

To answer the obligitory (and obvious) question “where were you?”, I was at my desk in my home office in Forest Lawn. For some reason, I decided not to go into work that day. Of course, at the time, “work” consisted of going in to flog the dead horse that was Shopplex.com for a tiny paycheque and promises of beaucoup de stock. Despite solid enough business acumen to see that the shares (and the company) were worth nothing, I stuck with it. I loved getting paid for being Just Another Perl Hacker, and we are a dying breed. Sometime in midmorning, as I happily hacked away at Hephaestus[1], the Ront came onto MSN and after the usual pleasantries, I got this:

1
The Ront: the world trade centre fell

I didn’t know what he meant. I figured maybe it was a stock market crash or some other relatively innocuous event; the events that were transpiring never once crossed my mind. At some point, one of our fellow coworkers got on the horn; he picked up the Ront and they came to my house. As I made some coffee I dimly recalled that the last time Trever had visited my horrid abode of teal shag and orange wood panelling, it had been to watch the Avs win Ray Bourque’s first and only Stanley Cup.

They turned on the TV and it was on almost every channel. So we sat quietly, mostly dumbfounded. There were remarks on how good the coffee was, nervous pitch black humour about not working downtown anymore, and the occasional theory as to what the fuck was going on.

And the unspoken but unbearably heavy “why?”

I watched a retrospective documentary this afternoon: stories of victims and heroes and life and death. And while a part of me applauds the indominable human spirit, another part of me is sickened at how pathetic it is that only tragedy makes people care about each other; how pathetic it is that I am as guilty as anyone.

Am I changed person because of 9/11? Perhaps, in some imperceptible and unconscious way, yes I am. Have I changed how I live my life or how I relate to people because of 9/11? No. And while for a time people agreed that security was important, now all the airport check points are an inconvenience and an annoyance. We live in an impossibly impatient society. Everyone is in a hurry and noone considers the consequences.

A few years ago, a man died while trying to get around a tractor-trailer on an exit ramp. The driver of the semi never saw the car and ran it off the road. The car did a few flips, and the man was probably dead before it stopped rolling. Just within the last couple weeks, a couple of women died while making an illegal u-turn using a service lane.

Whenever this sort of senseless and completely and utterly avoidable death happens, my thoughts are always “What were that person’s last thoughts? What put them in such a rush that they just had to push in that last straw?” And while we can never know the truth, I’d wager that the reasons were mundane: wanting to get home quickly, not wanting to miss the next exit, or maybe just daydreaming.

I don’t think there’s any way to slow down our society. That could only happen if people could find some peace and some serenity, and not have to play the game to get ahead. But there is such drive to get ahead, and such drive to play. I’ve had times where I know for a fact that my family is upset with how many hours I work and how distant I can be in the middle of a project. It’s so easy to space out and think about logical problems – things I can prove correct or incorrect. And my worth to the society as a consumer grows. I get better positions, I get more money, and I keep running on that rat race treadmill.

When all you think about is getting ahead, you forget what’s really important. It’s easy to forget that my son’s laugh while flying a kite is worth a million times more than the most elegant algorithm. It’s easy to forget that holding my wife is worth more than staying late to score a few points with boss only to come home and sleep on the couch so I don’t disturb anyone. It’s easy to forget that my family cares more about whether or not I’m home for supper than whether I’m a Team Lead or a Manager. And even so, money’s tight. I see it as a failure that my wife has to work to help out[2]. And the cycle, the vicious cycle, repeats.

There have been times where burning the candle at both ends wasn’t enough – I had to break it in half and touch the flame to those ends to get a little more light. But I’m getting older, and after an all-nighter it now takes days, not hours, to recover. The truth is, I need to sort some things out before I’m finally forced to decide, once and for all, which is better: to burn out? Or to fade away…

[1] Shopplex’s online website editor that was going to change the face of the Interweb (to be fair it was pretty cool, and was based on code written by the impecable Chris Scott)
[2] Just to make this ABUNDANTLY CLEAR, I’m not some neanderthal ass who doesn’t let his wife work. She would rather stay home with the boys for a few years, but that’s just not possible right now.

September 10, 2005

Another II Haiku

Filed under: Grab Bag by Nathan @ 12:47 pm

pH34r my M4D sKiLLz, j00
l4m3R n00bz w1LL b pwnZ0r’d
4 teh f4t l00t. w00t![1]

[1] Rough translation:

I am really good.
New players will surely lose.
I will take their stuff.

September 8, 2005

HDD = 0xDEAD [EXPLICIT]

Filed under: Craft of Dev by Nathan @ 8:35 pm

My laptop just died. More to the point, the hard drive of my laptop has shuffled of its mortal coil. It has ceased to be, it is a non-HDD. Worse, I have just spent about 20 hours over the last two days converting a creaky old school web service over to ws4ee. While re-implementing the web service was mostly cool, getting it to work with the applet that calls it was somewhat mind numbing. Since I’m writing this, you probably guessed that none of that is committed.

And you want to know why? As in “Why the fuck were you so fucking stupid that you didn’t commit for 2 fucking days!?” It’s because I didn’t want to break the build, of course. That’s right, I didn’t want to break the build. A noble goal, of course.

What would’ve been an even more noble goal would’ve been to create a fucking dev branch so I could commit all the fucking broken builds I wanted to!!!!! Let this be a lesson to you, folks, continuous integration where you go two days without a check-in ain’t. I was already under some time pressure, so now not only do I have to wait for a new HDD, but I have to find time to redo all that work. Even under the ol’ “If only I knew then what I know now” banner it’s still looking like at least a day.

Mere words cannot describe how I feel right now.

In the words of Darth Vader at the end of Episode III (but with real anguish, not that “I can’t believe James Earl Jones has sunk this low” bullshit), NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!

September 7, 2005

That Reitman’s Commercial (you know the one…)

Filed under: Sight by Nathan @ 8:38 pm

As a general rule, I hate commercials. I know this doesn’t make me “unique” or “special”, but I get a kick out of those new Reitman’s commercials. You know the ones where every time a woman sees a camera she starts doing “teh model thang” and posing and whatnot? Well I think it’s hilarious.

I don’t mean hilarious in some sexist sense like “every woman thinks she’s a model when there’s a camera around”, but in a funny cause it’s true “everybody with a camera is really annoyed” sense. Cause I’d be[1].

Oh, and whoever thought up that whole Jack-in-the-Box dude was a genius. A crack up everytime I think of ol’ sphere-headed Jackie boy saying “You are so fired.”

That’s entertainment.

[1] You may be asking “You’d be what? Rolling around and posing? Or annoyed?” The answer is yes.

September 4, 2005

The Shuffle Game (3 in a series)

Filed under: Sound by Nathan @ 9:15 pm

It’s been a few weeks (been busy, forgot, you know the drill) but the Shuffle Game is back. Had a real nice mix come up this time, creating a pretty mainstream list. Best song in this bunch is a tie between 1 and 10. Most embarassing song? There isn’t one this week.

  1. Nowhere Fast – The Smiths – Meat is Murder
  2. Sexual Revolution – Macy Gray – The Id
  3. Been It – The Cardigans- First Band on the Moon
  4. Interlude 1 – Snoop Dogg – Doggystyle
  5. U.S. Blues – Grateful Dead- San Bernardino, 1977.02.26
  6. Manic Monday- The Bangles – Different Light
  7. Never Gonna Stop – Rob Zombie – Past, Present & Future
  8. Pulling Teeth – Green Day – Dookie
  9. Please Please Me – The Beatles – Please Please Me
  10. Suspect Device – Stiff Little Fingers – Inflammable Material
  11. Crucify – Tori Amos – Tales from a Librarian
  12. I’m Not Sorry – Morrissey – You Are the Quarry
  13. The Wake-Up Bomb – R.E.M. – New Adventures in Hi-Fi

For all those that get one – enjoy the long weekend!

September 3, 2005

MP3otW – Material Girl by KMFDM

Filed under: MP3 of the Week by Nathan @ 12:21 pm

Kein Mehrheit fur die Mitleid

Roughly translated, the above means “no pity for the majority”, and it that for which the letters KMFDM stand[1]. They were one of the first and electronic industrial bands, and that name could describe their feelings for late 80s top 40 radio. But rather than throw down something raw like Terror I’m heading back to cover land with their charming version of Madonna’s Material Girl.

Not much else to say this week – lemme know if you dig.

[1] Not, as you may have heard back in the day “kill mother fucking depeche mode.”

Powered by WordPress