afongen

Every workday should include a nap, a study says. “It estimates that sleepiness on the job costs the nation’s businesses about $18 billion a year.”

Well, duh. I’ve long advocated the siesta for its health and productivity benefits, although I’ve had no data to back me up. I often take the bus to lunch, and take the opportunity to catch a few minutes of shut-eye followed by a nice, invigorating walk. Somehow, though, I just don’t see employer-endorsed naps happening anytime soon, especially within the State. I can just imagine the headlines.

“Headlines.” Hmph, as if people read the news. It’s the TV news teasers that would be killer.

I’m at work, and man it’s hot in here. I can handle heat just fine when outside, at least there’s usually a breeze. But it’s a couple degrees hotter inside at work than it is outside, and the landlord won’t turn on the air conditioning because it’s going to be in the 40s in a couple days. Okay, fair enough, ya cheapskates, but how about turning on the fan to at least circulate some air?

No.

Someone’s brought in a large oscillating fan. Thank god. I’m tired of dripping sweat onto my keyboard.

Via Tim McGyver, a list of open source GIS tools.

I’m still looking for a reason to use MapServer. Maybe if I can attend the upcoming MapServer Users Meeting, I can be inspired. Or at the very least, make it to May’s Twin Cities PHP Users Group meeting, at which MapServer’s creator will be speaking. I’ve been trying to go for a long time now, but never seem to make it. Doesn’t help that now I live even further away from where the meetings are held.

For later reading, once I catch some time:

• The Hundred-Year Language.
• Tim O’Reilly: The Architecture of Participation
• .NET XML Best Practices Part I:Choosing an XML API

That last one has me the most curious:

As someone who has spent the past several years learning and using the various XML APIs available throughout the industry, I can honestly say that the .NET implementations are the best I’ve seen in terms of productivity, efficiency, and extensibility. The .NET XML framework provides support for all of the W3C-stamped XML specifications including:

• XML 1.0
• Namespaces in XML
• DOM Level 2
• XPath 1.0
• XSLT 1.0
• XML Schema

I’ve never seen this before. I got this message today in Mozilla 1.4a:

Not sure how useful that is for the average end user, but of course the average end user is not using Mozilla. I suppose we can expect this feature to be rolled into Netscape. It may be nice to make it clear that it’s not necessarily the browser’s fault that a page loads slowly, if only to lessen the chances of people switching browsers for some perceived speed improvement. Hm.

I’ve always been bothered by the options on dialog boxes like these. Let’s see, click OK to abort (i.e., to cancel), and Cancel to continue … huh?

Henrik Gemal’s Using Mozilla in testing and debugging web sites makes me realize just how much I take for granted in Mozilla. Sure, I give a silent thanks whenever I use the JavaScript console, Venkman, or the DOM inspector, but until now I hadn’t really given any thought to how nice it is to have detailed control over my cookies, colored HTML source, and detailed page information.

Cool things that I didn’t know about:

• LiveHTTPHeaders, a tool for live access to HTTP headers on pages you visit. A far sight handier than, say, a telnet session or Rex Swain’s HTTP Viewer, although those certainly have their uses.
• View Selection Source (described in the article).
• Cache manager. Enter about:cache in the location bar.
• Configure Mozilla with about:config.

Granted, I no longer use Mozilla for casual browsing at home (I switch between Safari and Chimera), but I do use it as an ever-more-indispensible development tool.

Hydra is a decent text editor in its own right, but what makes it interesting is its collaborative editing feature: just click on the “share” button and you can allow others on a network to edit the document right along with you. Click the Rendezvous button and share over an ad hoc wireless network! Too damn cool.

They mention extreme pair programming on their home page as one possible use. I wonder how it could be used in the classroom…

First Chimera had to be renamed Camino for legal reasons. Now I see that Phoenix must be renamed, too, also for legal reasons. What gives?

Oh, this reminds me. When I was working for The Roastery, I took a call from a guy who was wondering how long we’d been in business. When I told him, he just sort of sighed, then explained that he owned a shop in Missouri or Montana or somewhere like that, also called The Roastery. He’d been told the company name was unique in the country. “Well, thank you for your time,” he said, “now I have to go kick my lawyer’s ass.”

At least he was good-natured about it.

Unit Testing in PHP.

And if you’re not convinced: Top 12 Reasons to Write Unit Tests.

And what do you know, the latest issue of The Perl Journal has an article on “Test-Driven Development in Perl.”

I have very much been enjoying the serialized interview on artima.com with Andy Hunt and Dave Thomas, authors of The Pragmatic Programmer. In particular, the first segment rang true: “Don’t Live with Broken Windows“.

As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can’t fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn’t trust it, shouldn’t go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. “Well, that’s broken. Oh I just broke that. Oh well.”

I picked up the book at the library a few weeks ago and devoured it. It’s very good, I learned a lot and have much to think about. I’m not ready for everything in the book, especially the latter chapters, partly because of the situation in which I work, partly because of where I am in my development as a programmer. So much of it, though, just resonated with me. They just plain make sense and have some great ideas. Read through the interviews and you might see what I mean.

It’s been especially interesting to me as I’ve been working with code that I wrote a couple years ago and realize just how far I’ve come in my programming practices. Sometimes I look at the code and wonder, “What was I thinking?!” Other times I just look at it and go, “Oh yeah, that made sense, but I’ve figured out a better way of handling that now.” It’s kinda cool. When I read “Don’t Live with Broken Windows,” I had just come across a comment in some oldish code: “Not the best way to handle this, but it’ll work as a proof of concept. Clean it up before it goes into production.” Of course, it had been in production for over a year. Heh. So i cleaned it up.

I don’t do so much of that anymore: I try very hard to take the time to get things right the first time, while at the same time avoiding premature optimization. The trick is balancing this against the unreasonable timelines I must usually work with. It’s been satisfying to realize that the code that I write under these conditions is far better than it was even a couple years ago. I’m confident that what I learn from The Pragmatic Programmer will help even more.