Another Comic

XHTML2 Is Dead, Long Live HTML 5!

Swearing to Cope with Pain

Man, it has been a while since I last posted. I wanted to write about all sorts of things. Like successfully installing R for OpenSolaris using packages. Maybe about the uncertain future for OpenSolaris, now that Oracle pwns that. Maybe about coffee (see my byline, I actually haven't written one word about my addiction to the bean). Maybe about a candidate for a side project I've been mulling over, involving human speech parsing. But I've been busy, both professionally and in private life.

However, I found a wonderful article on Scientific American that is just so timely, that I feel compelled to post. Right here, right now.

Been quite busy at work, having been drafted to fight fires on a project that I now understand to be, simply put, a real death march project.

If you're in IT, then you know what I mean...

Crazed release schedules, dictated to us according to the customer's whims. Lack of basic, understandable documentation. Severe lack of a coherent, well-thought architecture. Largely apocryphal comments sprinkled in the code, probably mostly out-of-date and inaccurate. No unit tests, no automated builds. A test team working on a Frankenstein system comprising multiple web services and multiple db's, all the while claiming that a test sprint can be done in 1 hours' time. Argh, and don't even get me started on the misinformed decision to use Seasar2, which itself suffers from extremely poorly written documentation, even in its home language of Japanese.

So I've been suffering from recurring headaches, lately. The cause? Me banging my head on my desk, asking futilely, "Why, o dear lord, why?"

What is this global variable doing here? *wham*
Why is this method duplicated in several objects, but in different, unrelated packages? *wham*
Why are there 2 classes in separate packages but of the same class name that at a functional level are almost, but not quite, completely different from each other? *wham!*
Who the #$%! wrote this code??? *wham!!*
What the #$%! was he thinking??? *wham!!!*
What blockhead decided against unit-testing and automated builds?! *wham!!!!*

When I am coding, I often talk to myself. A lot. So much that the people that sit near me at my traditionally laid out Japanese office mention it. They mention it quite often, actually. And I find that if I am in fire-fighting mode, trying to fix code written (nay, slapped together??) by others, then I find that I begin to swear out loud. A lot.

Hallucinatory soliloquy? Generalized anxiety disorder? Just a tad schizophrenic? Tourette's?

No, none of the above. Not according to the Scientific American article Why the #$%! Do We Swear. No, I think the increase in my swearing out loud is in direct proportion to the amount of stress and frustration I am feeling at that time, and this outward vocalization is really helping me to relieve the pain I am feeling. It's a coping mechanism.

A brief excerpt:

The study, published today in the journal NeuroReport, measured how long college students could keep their hands immersed in cold water. During the chilly exercise, they could repeat an expletive of their choice or chant a neutral word. When swearing, the 67 student volunteers reported less pain and on average endured about 40 seconds longer.

...

How swearing achieves its physical effects is unclear, but the researchers speculate that brain circuitry linked to emotion is involved. Earlier studies have shown that unlike normal language, which relies on the outer few millimeters in the left hemisphere of the brain, expletives hinge on evolutionarily ancient structures buried deep inside the right half.

One such structure is the amygdala, an almond-shaped group of neurons that can trigger a fight-or-flight response in which our heart rate climbs and we become less sensitive to pain. Indeed, the students' heart rates rose when they swore, a fact the researchers say suggests that the amygdala was activated.

So you see, I am just trying to soothe my #$%! pain. I'm just trying to work it on out. Hell yeah, I can feel that dull ache receding...

Networking and FreeBSD 7.1 on VirtualBox

Quick tip if you're installing FreeBSD on VirtualBox... when configuring networking, be sure to select the PCnet-PCI II (NAT) adapter.

I was bored this Sunday evening, so I decided to install FreeBSD 7.1 alongside my virtualized Linux distros (CentOS 5.2 and 5.3), plus I still have OpenSolaris around). Having just installed Linux this morning, I mistakenly selected the PCnet-FAST III (NAT) adapter, and was scratching my head for the better part of half an hour when I found I couldn't SSH into my shiny new FreeBSD install.

The more you know...

CentOS 5.3 on VirtualBox

CentOS 5.3 was released last month, and I finally got around to adding that to the list of virtualized OSs I have running on VirtualBox.

Install was easy as usual. Since I again installed a handful servers and development tools, along with Japanese Language Support, I ended requiring all 6 of the CentOS 5.3 install ISO image files. No need to burn them to CD-ROM, just mount the files using Devices -> Mount CD/DVD-ROM in the VirtualBox main window menu.

Did the normal preflight check: ensured that SELinux is on and enforcing (you can switch this off if all you're doing is developing locally, but it helps to understand how SELinux works if you will be using it in production); disabled services not needed when running virtually (anacron, bluetooth, cups, hidd, pcscd, xfs); double-checked to see that root access is disabled for sshd; and I only open ports for SSH and HTTP/HTTPS in iptables (again, you can always configure more open ports as needed, like for accessing a database or whatnot).

Lastly, I installed the VirtualBox guest additions for Linux. Nothing special here, just follow the instructions in the User Manual. The long and short of follows below.

First, we install the packages necessary for installing the Linux guest additions:

# yum install gcc -y
# yum install kernel sources -y
# yum install kernel-devel -y
# shutdown -r now

Next, mount the VBoxGuestAdditions.iso file per section 4.3.1 Installing the Linux Guest Additions in the User Manual.

Then, all that's left is:

# mkdir /tmp/cdrom
# mount /dev/cdrom /tmp/cdrom
# sh ./VBoxLinuxAdditions-x86.run
# shutdown -r now

Hey, presto! In the messages displayed in the console at startup, you will see that VirtualBox Additions is also starting up now. Good to go. And not that much different from my previous post on guest additions with CentOS 5.1.

I should also add that there wasn't any need to first install gcc and dkms, since those packages were already included in the installation. Caveat emptor.

Robotic Penguins!!!

Is this not sweet, I ask you?

Learning from Failure, or There Goes My Golden Week Vacation

As a systems architect, I must concern myself with project management issues. Every now and then, I like to check my head and reread a wonderful blog post from Reg Braithwaite on What I've learned from failure. I printed up a copy and keep it in my notebook so that I can pull it out and read it on my train ride.

This is a timely topic for me as I now find myself only a week away from the big Japanese Golden Week holidays facing the ugly and imminent possibility that I will have to drag my carcass into the office during the holidays to assist another project team that are in the unenviable position of being smack dab in a "project out of control".

This project is rather high-profile and very important for my current employer. Being an outsider to this project, I don't know anything about how it got to this state. Only three weeks before going public, with a large string of national holidays right at the end... Doesn't that sound like project management wasn't working properly? And it always just slays me when I see that the only solution upper management can come up with is to toss more people at the problem by asking them to come in over the vacation. Urgh, I am having flashbacks of Lumbergh in Office Space: "m' yeah, I'm gonna need you to come in on Saturday..."

Close your eyes, take a deep breath, and repeat this mantra after me: Adding manpower to a late software project makes it later. Fred Brooks is spot on there. I feel like I should bring my copy of The Mythical Man Month in to the office and start whacking people across their faces with it.

So here's the punchline for today... what have I learned from failure?
People just never learn, that's what.

Closing note: It just so happens that there was a recent thread on /. on project management. Great comments, especially from myvirtualid.