Recently, I’ve been dogged by a Subversion issue (and generally dogged by Subversion — Mercurial and Git are my new friends) that stumped me on and off for a few weeks. The dreaded error was a “Checksum mismatch”. Essentially, the file downloaded from the server didn’t have the content expected. It had been modified.

For those interested, the post that finally led to the fix is here:

http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=450635&orderBy=createDate&orderType=desc

The cause of the problem was that to the web server that served the files had stripping out “non-essential” content from HTML and JavaScript files, namely comments. For end users, that’s great. Less bytes to download? Awesome, we saved an e-tree! But for a developer working on that particular file, those comments are (arguably) valuable. And required if you want to fetch a valid copy from the server.

I was the victim of an over-optimization.

This issue got me thinking: are we on the brink of over-optimizing “all the things”? Almost all content on the internet can be optimized in some way. HTML (and any text file) can be compressed (gzip, they call it), JavaScript and CSS can be “minified” and combined into a single file. Pictures, videos, and sound files can be compressed into lower resolutions, lower bitrates, or lower quality for faster transmission or because the eye or ear can’t perceive the difference. The 1080p video from iTunes is not the same as the one on a Blu-ray.

In addition to these file-level optimizations, there is caching. Almost every point between the source and the destination has the opportunity to cache the content. What guarantees that we get the correct version of the correct file? Nothing, sadly.

Optimizations can fall into two basic categories: those done safely (lossless) and those done with a risk (lossy).

The risks of lossy optimizations are obvious: content is lost, changed, or whatever term you’d like to use to soften the effect. It may not matter most of the time, but someone or something at some point is going to depend on the full content. In this case, it was my sanity for 6 hours last week.

The risks of lossless optimizations are less-obvious. There is always the risk that the conversion did lose data, thus truly being lossy. But I’m finding the challenges and risks are more upfront, in the actual creation, and not the consumption, of the content.

I’ve been working with Rejuicer, a pretty slick JavaScript and CSS minification tool. It’s pretty easy to setup, and for basic organizations of files, a no-brainer. Soon after diving in, subtle issues crept up. Remember the “cascading” part of Cascading Style Sheets? If Rejuicer servers your files in an order you don’t expect, the content has changed. It’s now lossy. The same can happen with JavaScript.

The lesson to learn here is if you are depending on someone else for your optimizations, be sure you understand how they work. If you are consuming content, be aware that optimizations are likely being applied.

There is an (admittedly small) upside to working on something in small bursts. While there is a huge cost to task switching, a regularly scheduled task that doesn’t last long can be productive. Here’s how:

If the task has a relatively low switching cost — something you know well, or something that doesn’t take long to get setup/back into — the time in between sessions gives you time to think (if only unintentionally) about the task, and the upcoming session. Occasionally, you’ll find that you’ll be surprisingly efficient at that task, having had some time to think about things in interim.

Even if you only have a small amount of time, it can be efficient, on the right task.

Maybe this is well-known to the JavaScript coding community — below is a simple technique I’ve found that runs a block of JavaScript when subscribed events stop firing. Full disclosure, I stole this from Hugoware. If he stole it from someone else… ;)

Use Case

A user is entering text into a text box. The user stops typing for a period of time, tabs or clicks out of the text box, or is otherwise done using the text box. When the user is done, server side validation is done (such as checking for uniqueness of a username on a sign-up form).

Solution

Attach a set of events to the text box that capture when the user is making a change, or leaving the text box. Every time the event fires, create a function that contains the functionality you want, to be fired on a timeout. If the event is fired again, cancel the existing function.

In code (using jQuery 1.7 syntax):

var timeout;
('#mytextbox').on('focusout blur keyup change', function () {
    if (timeout) {
        window.clearTimeout(timeout);
    }
    timeout = window.setTimeout(function () {
        // Perform server-side validation here
    }, 1000);
);

Bonus: jQuery plugin

While the above code is pretty simple, if you want to use this pattern a few times on the same page, it can lead to some duplicated code and multiple variables to hold the timeout. So I’m solving that with a jQuery plugin. Behold, jquery.onidle.js:

$('#mytextbox').onidle('focusout blur keyup change', 1000, function () {
    // Your idle functionality here
});

For more details on the plugin, visit its GitHub page.

A started a new job in late 2010. At first, it seemed like something that was too good to be true at the time. It had a lot of awesome perks (to me, in no particular order):

1. Wasn’t consulting
2. Was a product/service owned by the company and slowly built upon
3. Had a software team and manager that believed in a lot of those software principles you read about, but never truly see at your job (confession: we’re not perfect, but we strive to always improve)
4. Was a telecommute job with very little travel
5. Used the technology and practices I wanted to use

I’m not here to recruit (although at the moment we are hiring) you, but to share a set of experiences that had me baffled until recently.

Whenever I start a new job (or project, as it often is in consulting), there is a period of time where I know absolutely nothing about the software you are writing and the business behind it. After a few weeks or months (depending on the size of the project and code base), I’ve always felt very comfortable. If I ever made it to the year mark on a project, I could recite policies and procedures (even to this day for previous projects, in some limited capacity).

But my new job was different. I hit the six month mark, and still knew less than 50%. Now, at a more than a year with the company, I realize that I may lucky to reach the half way point in knowledge, if I am lucky. This bothered me a lot.

Why wasn’t I learning this new code? Was it harder? Was I losing my touch?

Why wasn’t I learning the business? Was I not paying attention? Was it because I was working from home?

I was lost.

Only recently, I realized the answer to why I wasn’t understanding the business behind the job. Put simply, I didn’t fully understand the business. I was no longer on the “front lines”, sitting, talking, planning, prototyping, demoing, testing, and involving the end user in day-to-day project activities.

Instead, I was on a product development team, sheltered from the “why’s”. Instead, I had plenty “what’s” and “how’s”, but never a good explanation why. Sure, there were some user stories, but never did I get the depth of knowledge gained from being there with the end user, watching them work, and truly understanding what the needed.

How have I solved this problem and why am I happier? I’m not sure it is truly solved. I volunteered to work with a client more directly. In two months, I feel I know their business and needs better (but not anywhere close to completely) than what I learned in the first twelve months. I’ll be master of a few things, instead of a jack of all trades.

Sure, there is a larger slope to learning “everything” this time. I’ll eventually get to “the guy who knows a lot”. In the meanwhile, I’ll be happy to know what I know and to know how to find answers to what I don’t.