Archive for September, 2004

Doughnuts! I like Doughnuts!

Wednesday, September 15th, 2004

I’ve been a software developer for quite some time, and at my last job, I was indoctrinated into the practice of buying doughnuts for the development team if one of the developers “broke the build”.

For those who don’t know what that means, let me tell you. Any decent software project has a central repository for source code which does versioning. That allows you to “undo” some changes if you decide that you made a mistake, or that a feature shouldn’t have been added, etc. It also lets you see wny each change was made because you typically add a comment for each “commit” that you do to the source repository.

Breaking the build is not really breaking the “build”, per se, but committing a piece of code to the software respository that causes the next build to fail (a “build” is when you compile all the code in the project — usually for testing purposes).

The penalty for breaking the build was therefore furnishing the entire development team with doughnuts the following morning. Sometimes, people woulc bring the crap from around the corner — one of these places in downtown Washington, DC that couldn’t possibly stay in buisiness unless everyone who worked on the block went there for breakfast and lunch (which they did… apparently because they derive no joy whatsoever from meals). However, those of us who knew what we were doing would seek out and find the very best in doughnut-land: Krispy Kremes.

After I got married, I switched jobs and I’m now leading the development team for an organization in Baltimore, MD. There is no central office and so everyone works from home. This is a big advantage for me, since I live in Virginia. However, even the development team doesn’t work physically in the same location, so if someone breaks the build, it’s kinda hard for someone to provide doughnuts to everyong in retribution for breaking the build.

Several days ago, one of our engineers, Luke, broke the build. In jest (since we really can’t do the whole doughnut thing), I created a bug report in our bug tracking system, and mentioned doughnuts.

Needless to say, the “bug” was fixed in minutes.


This morning, my friend the UPS dude comes to my door (poor guy… he’s lugged a TiVo up 4 flights of stairs to my apartment when the elevator was dead for a couple of days) with this box from Dunkin Doughnuts.

“What the hell is Dunkin’ Doughnuts sending me?”, I said to my wife.
“Open it!”, she yells as she starts tearing into the box. “There could be doughnuts in there!”

It was way too light to be doughnuts. It was also way too light to contain a bomb, so I figured it would be cool to open it.

Image of Dunkin' Doughnuts box (9x12x6") containing several gift coupons -- from Luke

I laughed so hard I almost fell our of my chair. I think I’ll send Katie out to get us some doughnuts.

Your Javascript Sucks

Friday, September 10th, 2004

First of all, you can’t win using Javascript in a browser. There’s always some stupid bug, either in the browser or in the Javascript itself, or in the site which uses it, or whatever, which prevents your Javascript from working properly. There, I said it: Your Javascript will break. Given that cosmic truth, why do web page authors always create pages where Javascript is actually required for use?. I never do this, even when using Javascript makes sense. Javascript should be used to add a little bit of functionality (such as client-side form validation) or maybe to open up a pop-up from a link instead of replacing the current page (’cause you can’t do that anymore in XHTML 4.01!).

Anyhow, using Javascript to drive the navigation on a website is just asking for trouble. Consider this my plea to the web page authors of the world: stop requiring Javascript. Just stop. Because lots of folks don’t have browsers that support Javascript (okay, not that many), lots of folks disable Javascript so that all the bugs in IE don’t hose them (okay, not that many), and there’s always the chance that your Javascript will fail and hose the user (okay, pretty good chance).

Perhaps I should relax and relish in the fact that Internet Darwinism will intervene and that sites that don’t work will not get used. Unfortunately, I know that this is not true. I believed this back in the day when IE and Netscape were neck-and-neck in the browser wars and some pages didn’t work on one of the other browser. If they didn’t work on both, those pages either died and weren’t used, or got fixed with a quickness. Unfortunately, one browser won that war (I’m not angry that IE won — hey, it was faster, had better features, and more fully supported CSS first) and it all went downhill from there. Microsoft decided that they were going to make their browser display HTML and work with pages no matter how poorly they were written, including the kind of mistakes that would accidentally launch nuclear weapons if they were made in that type of software. Microsoft is also all about backward compatibility. That means that, unless some serious changes occur in the direction of their browser, IE will continue to render the drivel created by today’s web authors, no matter how egregious. Microsoft has made drivel the standard, since it works. If it works, nobody will be motivated to fix the problems in their web browser. Broken pages will remain, and browsers that choose to punish bad pages will have trouble gaining acceptance.

So, web authors of the world: please, for the sake of all Internet denizens, please stop requiring Javascript to get around your pages and sites. Javascript is fine to spice-up the interface, or do sone neat tricks. That’s cool. The Javascript kids get a bonus for having it. But, do not punish those who are at a disadvantage for any number of reasons, including their browser or browser version, their browsing preferences, or your stupid Javascript.

It’s Good to be Smart

Friday, September 10th, 2004

I recently purchased a wireless ethernet USB adapter from D-Link – the DWL-122 to be exact.

It turns out that the item was defective, and I called customer support to get an RMA number to return the adapter. I went through all the hoops that I despise, even though I know that the customer support people are required to go down a list of things that probably aren’t wrong, just in case they can find a way to place the blame on you, your network, your power, your cat, etc. [there’s a pat-on-the-back bounty for anyone who can find that online article that was all about this dude at a customer support center revealing all the different strategies people around the call center used to get people off the phone].

Anyhow, I finally went through all the foolish things I had to do (including, but not limited to, power-cycling my wireless router, which was currently working with the built-in Wi-Fi adapter in my laptop) and was given a case number. That case number is used to fill-out an online RMA request. You go to the D-Link website and enter in all you information (including the case number) and boom: they give you a bar-coded form that you print and include with your return so they know why you’re sending them a package.

There’s only one problem: there’s a step in the process where you have to choose between a “Replacement” return (where you send the item back, and they send you a replacement once they’ve tested it or whatever) and a “Cross Shipment” return (where they sell you a new one, then reimburse you when they get the defective item). That step was a roadblock, since neither big, throbbing button on the page actually does anything. Nope. Nothing. Nada.

Since I’m Smart™ (and I use Mozilla Firefox, further contributing to my Smart™ quotient), I popped-open my trusty Javascript console to see what was going on (things like this are often Javascript-related). Sure enough, some programmer had coded illegal HTML which resulted in Javascript that simply wouldn’t execute.

Let me take this opportunity to rant about Javascript in browsers. In fact, let’s do that in another post.

Looking at the HTML source code for this page revealed that the button fired-off a Javascript call which should have set the action for a <form> element and then submitted the form. Unfortunately, the form was defined after the entire page, including the </html> element. Maybe it was just Firefox’s propensity to — uh, I dunno — comply with HTML rules, but you can’t define anything useful outside of the page boundary.

The Javascript console told me: 'confirmed' is not defined, because the form (called ‘confirmed’) was not defined within the page. Makes sense. However, it was obvious what the form was trying to do, so I copied the source code for the form, added a submit button and the action attribute myself (helpfully provided by the Javascript code), loaded the hacked form in another window, and submitted the form, and continued with the RMA process.

Chris: 1
Teh Intarweb: 0