Super Ouch!

My very good friend Dave Edwards lives in Salt Lake City, Utah and continually makes us all jealous that he’s got season passes to Snowbird and I think a couple of other places in the immediate area. He can basically finish up classes for the day (at U of Utah) and run up the hill for a few runs.

Whils planning this year’s week-long ski trip, we received a message from him on the mailing list, which includes this excerpt. I’ve in-lined the image thumbnail to make for a better blog entry.

Two weekends ago, I decided to try something called “sand skiing,” which is exactly what it sounds like: you find a large sand dune, hike to the top, and ski down on some old, beat-up skis that you don’t really care about. Needless to say, it’s a fun way to spend an afternoon.

But if you’re going to try sand skiing, here’s some advice:

  1. As you ski, the sand really tends to come up over the tops of the skis and bury them, which is a problem since sand is so much heavier than snow. If possible, I’d recommend a set of fat, powder-type skis; if you can afford to ruin a pair without straight edges, so much the better.
  2. You will want to set your bindings as low as possible so that they release easily. If your bindings pop out when you look at them wrong, so much the better. Heavy sand on your skis can generate a LOT of torque quickly, and it’s better for your legs not to absorb that if you can avoid it. Also, the sand tends to work its way into the bindings and jam them up, so it’s better to be jammed with lower release settings than higher.
Nice tib-fib fracture!

Unfortunately, this was my first attempt at sand skiing, and I didn’t know
these guidelines. I had my bindings set just slightly lower than I would
for snow skiing, which turned out to be a bad idea.

So, to make a long story only slightly less long, I’m in a hard splint for two more weeks,
followed by a cast for six to eight weeks, followed by rehab. There’s a
chance I might be able to ski again by the end of the season: we’ll just
have to wait and see.

In the meantime, the mountains continue to be buried by snow, as I hobble
around my apartment emitting primal screams 🙂

I nearly cried when I saw that picture. I mean, as soon as I read the words I decided to try something called “sand skiing”, I knew where the story was going. I wasn’t exactly prepared for that image, though. He pretty much cracked the bone in half, and then right down the middle — just for good measure.

Get well, soon, Dave.

Moved to WordPress

So, after pulling for the little guy, I have finally switched to WordPress.

I’m sorry to the Java folks out there. I really did want to use a Java-based blogging engine. However, Roller simply did not meet my needs:

  • Run on a Cobalt Qube 2
  • Run for more than a week without crapping out

I must admit that I didn’t try too hard to figure out what the problem was with Roller. All I know is setup and configuration sucked (as it often does with Java) and the database connection would simply die and never come back. I had to check the blog every day to see if it was still working.

WordPress seemed to fit the billing and was super-easy to install. Hey, that makes me happy — one less thing I have to deal with myself.

I’m going to try and make all the old links work, not that anyone really gives a crap. Maybe I’ll just redirect all the old-style URLs to the home page. I did enough work writing a SQL script to convert the Roller database into a WordPress-style one.

Doughnuts! I like Doughnuts!

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

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

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

Backbreaking Futility as Relaxation

For years, my family has taken a vacation to Cape Cod, Massachusettes. My only requests for activities have been:

  • Eat Seafood (especially Lobster)
  • Build sand castles

The second activity is pretty much more of a requirement than the first, and I need to spend every possible day on the beach busting my butt building a castle only to have it washed away with the tide when we’re finished.

When we first started coming to The Cape, I was maybe 10 years old or so. One of the things parents give to their kids when going to the beach is a set of pathetic “sand toys” consisting of a few sand castle molds, a shovel which cannot possibly survive the excavation of as much sand as it can hold, and a crappy bucket.

Despite these primitive tools, I was able to learn the trade quickly and soon hooked my dad on the whole thing. Since he was much bigger at the time, he would provide the man-power required for amassing a great deal of sand on which we would build our castles. I convinced him that the plastic shovels we were using were inappropriate and convinced him to buy us a fold-up shovel which could lift much more sand — even when wet.

Over the years, we have collected various castle molds and other sand sculpting implements. For example, the best piece of plastic that we have is a 7-inch yellow plastic shovel from a McDonald’s kid’s meal. We have two of them and must have had them for more than 10 years by now. (Last year, they really started to fail, so if you have any of these lying around that you’d be willing to donate, please send them my way!).

We now have two drawstring bags full of sand molds, shovels, etc. and a regular, garden-variety shovel that we use to cut out a moat and create a pile of sand large enough to build on and sculpt.

My sister and I are now both married, yet still bring our growing families on this annual vacation. My brother-in-law, Wayne, has also gotton sucked into the whole sand castle process and can even carve stairs quite well. His stairs are featured in a photo from yesterday’s exploits:

Photo of northwest face of Monday's sand castle

More images from that day can be seen here. There are a lot in there, they are quite large, and I have not yet created thumbnails for them. So, if you have a dialup connection or some kind of Clay-Tablet-by-Carrier-Pigeon (CTCP) device, then you might not want to look at all of them.

This year’s trip to The Cape was less fruitful than previous years. We had bad weather about half the week, and then we burned a day fixing-up the large deck which now features bolts into the house (yay!). That meant that we only had two days for building sand castles.

Photo of southwestern face of Friday's sand castle

Lots of people stop to watch us as we build the castles, which is nice. The most common question we get is “so, how long did it take to do this?”. We never know. We’re not looking at our watches. We wildly estimate all the time, and have considered keeping better track of time to tell people, because they seem confused when we don’t know how long it takes. Kids also ask “How did you do that?“, which is tough to answer. The most obvious answer is “Just watch for a while, and you’ll see,” but most kids don’t have that kind of patience. I blame television.

We also get lots of jokers who think they are the first ones to tell us any of the following jokes:

  • ““Do you have a permit from the city to build this here?” (or some variation thereof)
  • “Does your work area meet OSHA standards?“
  • “You know the tide is coming in, right?” (to which we usually reply, “The what-now is ‘coming in’?“

This kind of thing used to irritate me. I actually like to work without any distractions. When people try to interact with you, it seems like they’re uncomfortable there staring at you (or more likely the castle) while you work. So, they just make up things to say to fill the silence. I rather enjoy the silence. God knows the beach itself isn’t silent. There are people everywhere. The waves are making noise. The wind usually blows a few miles per hour, so you can hear it going by your ears if you’re facing the right way. (I also wear a hat which makes the wind audible pretty much all the time). I find all this ambient noise calming, especially when I’m working for a few hours. I get time to hum to myself and think things over.

Sadly, the area where we build eventually succumbs to the tide. The beach where we build grows by about 100 meters when the tide is all the way out, but it takes 3 hours or so after high tide for our work area to become dry. That also means that 3 hours before the following high tide is when our castle will go under. That leaves about 6 hours of total building time, including a lot of digging and then the cleanup and escape with all our tools, chairs, umbrellas, etc.

Despite the obvious futility of building such a work of art which is destined to be swallowed by the waves mere hours after its construction, I don’t mind the castle going under. It seems perfectly natural to me, and actually feels like a part of the construction process. It reminds me of life. Life is immediately followed by death. Yet, somehow, we all find the impetus to do something we enjoy with at least some of our time. It’s also like a a journey where the destination is not the goal, but rather then journey itself. Construction of these castles is a journey that is an end in itself through which I derive great joy.

On the days that we’ve left our castles out on the beach without watching the water melt them back into the ocean floor, I feel sad, like I’ve missed-out, or been robbed of something. Even the days when my wife is unable to prevent the onlooking kids from storming the castle as it gets close to the end, I don’t mind the human element of destruction. Have you ever seen a group of kids storm a sand castle? They love
it. I’ll admit it’s hard to watch them do it, but I would merely be prolonging the inevitable (which, at that point, is only a few more minutes away).

At the end of the day, my back is sore from moving hundreds of pounds of sand and leaning over so much, my knees are sore from kneeling on the sand, and my skin is often sore from being slightly burned by the Sun. Still, building sand castles remains one of the most relaxing things I do.

United States Congress: Don’t legistate religious doctrine

I recently received an email from, honestly, one of the most annoying political action groups that I know of. MoveOn.org.

I say that they are annoying mostly because I get an urgent email from them just about once a day telling me about the latest injustice inflicted upon US citizens by the Bush Administration.

I could wax politic about the current climate of reactionary politics in the US, and how we should be focusing our energy solving problems, etc. blah blah blah but I’ll save that for another day.

Despite their vexatious tenacity, MoveOn.org occationally moves me to action. Today was one such time.

Here, I am publishing the short note I attached to a nasty-gram, sent by MoveOn.org on my behalf to President George W. Bush, and to my (Virginia) US Senators and congressman stating that I oppose an ammendment to the US constitution to deny marriage rights (and benefits) to same-sex couples.

“We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.”

I believe that prohibiting same-sex marriages denies those would do so their unalienable right to pursue happiness.

Religious organizations and groups have every right to refrain from performing any such marriage. However, the government has no business legislating religious doctrine.

‘Nuff said at this point. I don’t care if you’re an atheist or a Bible-beater. The word “marriage” as used in the “Defense of Marriage” act and its ilk is decidedly religious in nature. Religion has no business in the US constitution. Marriage in the minds of same-sex couples (not to put words into their mouths) is more about rights than religion. In that vein, same-sex couples deserve the right to get married.

Customer “Support”

This morning, I was having trouble sending email. I have Comcast Cable Internet services, and there didn’t seem to be anything on their web site about any outtages or anything, so I thought I’d get onto their LiveSupport chat thing and quickly talk to a person.

Now, let me tell you: this LiveSupport chat thing is great. You wait in “line” maybe two minutes and then someone handles your support request through a little Java applet that lets you two chat. The support person can suggest websites as resources which appear in a window where you can click on them and follow the links, and you can even get a transcript emailed to yourself for future reference.

Today’s chat was less than helpful. I showed my boy Brian the transcript, and he thought it was too funny for words. He also suggested that the responses from the support person were not unlike those you might expect from Eliza.

Finding this assertion amusing, I figured I’d write what I expect Eliza to say to me, as a Comcast customer support call came in.

Eliza> Hi! My name is Eliza and I’ll be handling your customer service request, today. How can I help you?

Chris> I am having trouble contacting smtp.comcast.net

Eliza> Does it bother you that you are having trouble contacting smtp.comcast.net?

Chris> Well, frankly, yes. I pay for Comcast Internet and feel that I deserve the service for which I pay.

Eliza> Do you think that it is because you are having trouble contacting smtp.comcast.net that you feel you deserve the service for which you pay?

Chris> Well, duh! I pay for that shit, so I should be able to send my fucking email!

Eliza> Let’s calm down. Does it bother you that you pay for that shit?

Chris> Well, when I can’t send emails it bothers me, since I pay for it.

Eliza> Do you think it is because you are having trouble contacting smtp.comcast.net that you can’t send emails?

Chris> (silence)

Eliza> Why is it that you pay for Comcast Internet and feel that you deserve the service for which you pay.

Chris> (silence)

Eliza> Is there anything else I can help you with?

Chris> Yeah, go fuck off.

Eliza> It is because you cannot fuck off that you feel you deserve the service for which you pay?

Chris> This is hopeless.

Eliza> Do you feel hopeless because you are having trouble contacting smtp.comcast.net?

Chris> Yes.

Update: 2004-07-07 16:18: The actual transcript is available.

Uncle Chris

When we were young, I used to threaten my older sister with the thought of me being the uncle to her children.

Well, things have changed since then, and I’m proud to say that this morning, I became an uncle for the first time.

Joshua Hinton Suggs

Joshua Hinton Suggs, born 09:18 2004-06-17, 7lbs 8oz.

Uncle Chris, indeed.

Vindication

Several weeks ago, one of the servers that I manage suffered a hard drive failure :(. The machine itself was, ahem, on the low-end of the server-capable scale for Java applications (P3 500MHz with 256MB RAM), and honestly, we were getting a great deal on it. Since the disk failed, and we needed to do some major re-building of the server, I figured we’d get some nicer hardware at the same time.

So, we got a P4 1.8GHz with a 1GB of RAM. All is well, right? Wrong.

Shortly after we got the new server, we started getting strange errors. Some of the Java applications were dying with mysterious signal 11s. When a Java VM dies, it sometimes doesn’t completely die, and you have to murder the process in order to re-start it.

Occationally, Java VMs are instable on certain machines, but those usually turn out to be AMD Athlon machines (and don’t get me wrong, I’d buy an AMD any day over an Intel CPU), and it usually turns out to be a glitch in the VM which gets fixed anyway. Regardless, I thought maybe the particular Java VM release I was using, but it appears to be relatively stable and in use for quite a while, even on Linux.

Then, other weird things started happening. The last few days of backups were all corrupt, and I kept getting this message from bzip2 when testing the archive:

bzip2/libbzip2: internal error number 1007.
This is a bug in bzip2/libbzip2, 1.0.2, 30-Dec-2001.
Please report it to me at: XXXXXXXXXX.  If this happened
when you were using some program which uses libbzip2 as a
omponent, you should also report this bug to the author(s)
of that program.  Please make an effort to report this bug;
timely and accurate bug reports eventually lead to higher
quality software.  Thanks.  Julian Seward, 30 December 2001.

*** A special note about internal error number 1007 ***

Experience suggests that a common cause of i.e. 1007
is unreliable memory or other hardware.  The 1007 assertion
just happens to cross-check the results of huge numbers of
memory reads/writes, and so acts (unintendedly) as a stress
test of your memory system.

Okay, my brand-new hardware sucks. Great. Oh, well, just call-up the hosting provider and get them to change-out the RAM, right? Wrong

Now, let me first say that I’m not going to mention the name of my hosting provider. That’s because they give us (a non-profit organization) a good deal on their services, respond quickly with the same primary contact person every time, and generally seem like they want to keep things moving smoothly for everyone. Unfortunately, this time, things did not go quite so smoothly.

First of all, I was assured that every Intel-compatable machine that comes from their hardware provider has its memory tested with memtest86, which I use myself. They argued that the memory was most likely not the problem because of the aforementined memory testing and the fact that the hardware was all new.

Now, I admit that I fall squarely on the software side of things, and I have the luxury of pretending that hardware works perfectly every time (“What do you mean division doesn’t work on some Pentium Processors?). However, I know when hardware is failing: when Java applications are dying, all my backups are corrupted due to a bug which bzip swears is more often bad memory, and MySQL starts spewing garbage strings when queried (oh, did I not mention that already?!).

Now, I admit there’s another possibility: the problem could be the motherboard or the CPU. Memory errors are not always the fault of the SIMM chips installed. Sometimes, the CPUs L1 or L2 caches can be faulty or the motherboard can have a glitch. Sometimes, the hardware is actually all okay, but the combination doesn’t work out so well (like when you have memory that’s a hair too slow for the mobo).

One of the ‘experts’ at my hosting company suggested that there might be a “hole in my filesystem”. WTF is that? I’ve never heard of anything like that, and neither has google. As far as I’m concerned, if google hasn’t heard of it, then it doesn’t exist 😉

Anyway, I was assured by my expert that, my moving my /usr/local data onto a fresh partition, my problems would magically go away. I simply needed to get the bad Java files off of the corrupted filesystem, and I’d be home free. By removing those files from the filesystem, I’d be essentially fixing my system and things would get better. They didn’t.

“Re-install Java”, was the next attempt. Riiiight. Re-installing Java is just deleting a directory and then untarring the archive. Re-installing Java ain’t gonna do anything. Oh, well. I’ll give it a try. Guess what? The system is so hosed, the Java installer won’t even run without seg faulting. Oops. I shouldn’t have deleted the Java installation. A system running a few Java apps with one crashing every few days is much better than a system with no Java applications running at all.

After about a dozen tries, I got Java installed. I rebooted (that tends to clear up a lot of things) and everything came back up fine.

At this point, I’m planning my strategy for the next mysterious segfault that I see: “Hey, if the hardware’s just fine, then you won’t mind giving me an identical rig and using my flawless hardware for your own servers”. I didn’t have to: my good friend, and usual point of contact at the hosting provider, calls me today to say that he’s going to be in the data center twice today, 5 hours apart. Sounds like a good time to just bite the bullet and go in there and run memtest86 on the rig and see what happens. 5 Hours outta be enough to check it out.

It turns out that he didn’t need that long: the box crapped itself as soon as the memory test started.

Within 48 hours, I’m assured that I’ll have a fresh set of SIMMs and everything should be okay after that. I’m hopeful, but not stupid. In fact, at this point, I’m actually borderline despondent. They’re going to switch out the chips, and the motherboard will be the problem. “But we gave you new RAM, it must be good!” will be the new mantra. Then, we’ll go through the charade again.

I just can’t catch a break.

We went through a bout of this at an old client (again, name witheld) of my former employer, The Adrenaline Group. The IT management decided that it was cheaper to have an army of AMD Athlons than a substantially lower number of Suns for web- and application-servers (Technically, yes, it is cheaper, but Suns handle high load much better).

Anyhow, they chose Penguin Computing as their hardware provider, and we ended up getting a bad batch of machines. We actually had six production servers, six QA servers, and six development servers. As I recall, at least two of each set were bad. We never saw any problems on the development machines because all of our load testing was done in QA, and things looked good. It turns out that the load tests sorely underestimated the load and that the real load caused the machines to work hard enough to crap themselves.

The software development management had us up for a week trying to figure out where we went wrong. They even called-in a pair of consultants from BEA (the app server we were using) to figure out if we had deployment issues, since this was their first BEA deployment. They were as baffled as we were. They were totally flailing.

I even went so far as to suggest that the problem was the hostname of the server, since the same ones went down every time (joking, of course). The manager looked at me with wide-open eyes and said “Really? Do you think it could be that?”. “No,” I replied. “It’s the hardware. Just go into the data center, take that server out of the rack, and throw it into the trash. Repeat if necessary. It’s bad hardware!”. They had the same reaction as this guy at my hosting provider: “It can’t be the hardware.”

I’m a software engineer. I know when it’s the hardware.