Coding Horror

Although I've never been more than a bush league hacker (at best), I was always fascinated with the tales from the infamous hacker zine 2600. I'd occasionally discover scanned issues in BBS ASCII archives, like this one, and spend hours puzzling over the techniques and information it contained.

I was excited to learn that a 2600 compilation was released earlier this year: The Best of 2600: A Hacker Odyssey. Although a lot of the information is hopelessly out of date and/or obsolete now, there's a timeless quality to the social engineering techniques, and at its core, the best articles are just plain good storytelling combined with technical writing skills.

The introduction captures, I think, the essence of 2600 -- the adventures of young adults experimenting with computers.

One of the true joys of the hacker world is the wealth of firsthand accounts that get shared throughout the community. Everyone has a story and many hackers have a whole treasure trove of them. This is what comes from being an inquisitive bunch with a tendency to probe and explore, all the while asking entirely too many questions. The rest of the world simply wasn't prepared for this sort of thing, a fact that hackers used to their advantage time and again.

In the hacker world, you can have adventures and obtain information on a whole variety of levels, using such methods as social engineering, trashing, or simply communicating and meeting up with each other. All of these methods continue to work to this day. Back in the 1980s, excitement via a keyboard was a fairly new concept but it was catching on pretty fast as personal computers started to become commonplace. It seemed incredible (and still does to me) that you could simply stick your telephone into an acoustic modem, type a few letters on a keyboard, and somehow be communicating with someone in an entirely different part of the country or even another part of the globe.

Of course, hackers had already been having all sorts of adventures on telephones for years before this, whether it was through boxing, teleconferencing, or just randomly calling people. And there were the occasional "real-life" adventures, something hackers were certainly not averse to, contrary to the usual stereotypes of pasty-faced teenagers who feared going outside and interacting with the world. The point is that whenever you got a bunch of bored, curious, and daring individuals together, it didn't really matter what the setting was. On the screen, over the phone, or in real life, there was fun to be had and plenty to be learned in the process.

The mighty 2600 empire soldiers on, of course -- the latest issue is Autumn 2008. This handpicked best of collection works as both historical archive and introduction. It's a great starting point, and a book I continue to take with me on trips for background reading. It rarely disappoints.

If you believe, like I do, in the value of learning through cartoons, then Ed Piskor's Wizzywig graphic novels are excellent companion pieces to the 2600 compilation.

So far there's Wizzywig Volume 1: Phreak and Wizzywig Volume 2: Hacker, with a third book on the way. You can read the first half of each book online; if you like what you see, Ed sells the books directly on his store. It's a little eerie how accurately he captured the ambiance of that era for me, all those fumbling, exploratory sessions with nascent online community through modems, local bulletin boards, and user group meetings.

It's fun to revisit the origins of my hacker odyssey, but I feel like we're nowhere near the end of it yet.

How about you?

I've been monitoring the progress of high-definition video playback on the PC for quite a while now:

• Next-Gen DVD: Are Those Additional Pixels Worth Your Money?
• High-Definition Video on the PC
• Is Your PC Capable of Hi-Def?
• Will Your Next Computer Monitor Be a HDTV?

It's been almost two years since I wrote that series, and I think we're dangerously close to viable high definition video playback on typical, mainstream PCs. One metric I follow closely is the price of the hardware, and OEM Blu-Ray drives are now only $99 shipped.

This drive is a DVD burner, in addition to playing HD-DVDs, Blu-Ray, and obviously DVDs -- and it also has very positive customer reviews. I couldn't resist, so I bought one.

I have no need for a standalone Blu-Ray player, but a cursory look tells me those are down to around $250 for decent models. And then of course there's always the PlayStation 3 option.

It's a shame OS X and Vista don't natively support HD playback of any kind (although Vista does include some copy protection mechanisms specific to high-definition video playback, which was the source of great hue and outrage). When you pair this $99 drive with some third party playback software like PowerDVD HD or WinDVD HD, you're set.

I'm particularly interested in high definition PC playback because the home theater PC I recently built is more than capable:

• Built in HDMI out (on the motherboard)
• Onboard video that supports H.264 acceleration
• A modern dual-core CPU

Also, I finally own a true 1920 x 1080 HDTV now -- yes, you can all stop making fun of me for using a creaky old brass and steam powered 852 x 480 EDTV -- so all the pieces are now in place for me to adopt Blu-Ray. I switched my Netflix account over to Blu-Ray this morning.

I'm not quite a high definition video early adopter, but I'm still on the leading edge of the curve. Funny how technology cycles repeat themselves. I distinctly recall being an early adopter of DVDs back in 1998, almost exactly 10 years ago. The 720 x 480 resolution and Dolby Digital sound seemed so impressive back then. I remember marvelling at the fancy interactive menus on the Austin Powers DVD. Of course, DVD quality is pretty pedestrian by today's standards. We've almost gotten to the point where DVD-level video quality is available worldwide in a typical web browser, not necessarily through YouTube, but through Vimeo and other alternatives.

With that in mind, I wonder how quaint Blu-Ray will seem in 2018?

A recent Stack Overflow post described one programmer's logging style. Here's what he logs:

INFO Level

• The start and end of the method
• The start and end of any major loops
• The start of any major case/switch statements

DEBUG Level

• Any parameters passed into the method
• Any row counts from result sets I retrieve
• Any datarows that may contain suspicious data when being passed down to the method
• Any "generated" file paths, connection strings, or other values that could get mungled up when being "pieced together" by the environment.

ERROR Level

• Handled exceptions
• Invalid login attempts (if security is an issue)
• Bad data that I have intercepted forreporting

FATAL Level

• Unhandled exceptions.

I don't mean to single out the author, Sean Patterson here, but this strikes me as a bit .. excessive.

Although I've never been a particularly big logger, myself, one of my teammates on Stack Overflow is. So when building Stack Overflow, we included log4net, and logged a bunch of information at the various levels. I wasn't necessarily a big fan of the approach, but I figured what's the harm.

Logging has a certain seductive charm. Why not log as much as you can whenever you can? Heck, just log everything! Even if you're not planning to use it today, who knows, it might be useful for troubleshooting tomorrow. What could it possibly hurt?

This attitude later turned into a liability for us. W ran into a particularly nasty recursive logging bug which dealt some serious hurt:

• On thread #1, our code was doing Log (lock) / DB stuff (lock)
• On thread #2, our code was doing DB stuff (lock) / log stuff (lock)

If these things happened close together enough under heavy load, this resulted in -- you guessed it -- a classic out-of-order deadlock scenario. I'm not sure you'd ever see it on a lightly loaded app, but on our website it happened about once a day on average.

I don't blame log4net for this, I blame our crappy code. We spent days troubleshooting these deadlocks by .. wait for it .. adding more logging! Which naturally made the problem worse and even harder to figure out. We eventually were forced to take memory dumps and use dump analysis tools. With the assistance of Greg Varveris, we were finally able to identify the culprit: our logging strategy. How ironic. And I mean real irony, not the fake Alanis Morrissette kind.

Although I am a strong believer in logging exceptions, I've never been a particularly big fan of logging in the general "let's log everything we possibly can" sense:

1. Logging means more code. If you're using a traditional logging framework like log4net, every logged event is at least one additional line of code. The more you log, the larger your code grows. This is a serious problem, because code is the enemy. Visible logging code is clutter -- like excessive comments, it actively obscures the code that's doing the real work in the application.
   
   
2. Logging isn't free. Most logging frameworks are fairly efficient, but they aren't infinitely fast. Every log row you write to disk has an overall performance cost on your application. This can also be tricky if you're dissecting complex objects to place them in the log; this may take additional time.
   
   
3. If it's worth saving to a logfile, it's worth showing in the user interface. This is the paradox: if the information you're logging is at all valuable, it deserves to be surfaced in the application itself, not buried in an anonymous logfile somewhere. Even if it's just for administrators. Logfiles are all too often where useful data goes to die, alone and ignored.
   
   
4. The more you log, the less you can find. Log enough things and eventually your logs are so noisy nobody can find anything. It's all too easy to bury yourself in an avalanche of log data. The hidden expense here isn't the logging, it's the brainpower needed to make sense of these giant logs. I don't care how good your tools are, nobody looks forward to mining a gigabyte of log files for useful diagnostic information.
   
   
5. The logfile that cried Wolf. Good luck getting everyone on your team to agree on the exact definitions of FATAL, ERROR, DEBUG, INFO, and whatever other logging levels you have defined. If you decide to log only the most heinous problems, evil has a lot less room to lurk in your logfiles -- and it'll be a heck of a lot less boring when you do look.

So is logging a giant waste of time? I'm sure some people will read about this far and draw that conclusion, no matter what else I write. I am not anti-logging. I am anti-abusive-logging. Like any other tool in your toolkit, when used properly and appropriately, it can help you create better programs.

The problem with logging isn't the libraries -- it's the seductive OCD "just one more bit of data in the log" trap that programmers fall into when implementing logging. That's why, in my opinion, logging gets a bad name. It's more often abused than not. It's a shame to end up with all this extra code generating volumes and volumes of logs that aren't helping anyone.

We've removed all logging from Stack Overflow, relying exclusively on exception logging. Honestly, I don't miss it at all. I can't even think of a single time since then that I'd wished I'd had a giant verbose logfile to help me diagnose a problem.

When it comes to logging, the right answer is not "yes, always, and as much as possible." Resist the tendency to log everything. Start small and simple, logging only the most obvious and critical of errors. Add (or ideally, inject) more logging only as demonstrated by specific, verifiable needs.

Software: do you write it like a book, grow it like a plant, accrete it like a pearl, or construct it like a building? As Steve McConnell notes in Code Complete 2, there's no shortage of software development metaphors:

A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it's an art (1998). Watts Humphrey says it's a process (1989). P. J. Plauger and Kent Beck say it's like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it's a game (2002). Eric Raymond says it's like a bazaar (2000). Andy Hunt and Dave Thomas say it's like gardening. Paul Heckel says it's like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it's like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?

I think we're leaving one metaphor on the table which more accurately reflects the way software is built in the real world: flail around randomly and pray you succeed by force of pure dumb luck. Sometimes it even works. Not very often, but just enough to confuse people who should know better into thinking they're smart, when what they really were is lucky.

The answer, of course, is whichever metaphor helps you and your team get to the end of the project. Personally, I see them as more of a battle cry, a way for a team to communicate a shared vision and a set of values. They're heavy on imagery and metaphor, and light on specific, concrete advice.

Even as Steve McConnell argues that most software development metaphors come up short, he quite clearly picks a favorite, and spends quite a bit of time defending his choice. It's not exactly a secret, as it's in the subtitle for the book: Code Complete: A Practical Handbook of Software Construction.

As much as I respect Steve, my software project experience to date doesn't match the controlled construction metaphor. I agree with Thomas Guest; software is soft; buildings aren't. I'm more partial to the model that Andy Hunt and Dave Thomas promote, what I call tending your software garden.

Programers as farmers, if you will.

All the best software projects I've worked were, for lack of a better word, alive. I don't mean that literally, of course. But the software was constantly and quite visibly growing. There were regular, frequent release schedules defining its evolution. There was a long term project commitment to a year out, five years out, ten years out.

To me, the parallels between farming and software development are strong and evocative. Steve disagrees.

The weakness in the software-farming metaphor is its suggestion that you don't have any direct control over how the software develops. You plant the code seeds in the spring, Farmer's Almanac and the Great Pumpkin willing, you'll have a bumper crop of code in the fall.

To be clear, all these metaphors are abstract and therefore heavily subject to interpretation (and/or useless, take your pick), so I don't want to get too wrapped up in defending one.

That said, I disagree with Steve's dismissal. The strength of the farming metaphor is the implied commitment to the craft. Farming is hard, unforgiving work, but there's a yearly and seasonal ritual to it, a deep underlying appreciation of sustainible and controlled growth, that I believe software developers would do well to emulate. I also think Steve was a bit unfair in characterizing farming as "no direct control". There's plenty of control, but lots of acknowledged variables, as well -- which I think more accurately represents the shifting sands of software development. Farmers do their best to control those variables, of course, but most of all they must adapt to whatever conditions they're dealt. Next season, next year, they know they'll be back with a renewed sense of purpose to try it all again and do better. Not so coincidentally, these are also traits shared by the best software developers I've known.

In particular, the rise of the web software development model has made the farming model more relevant. Where traditional software like Office might go through a bunch of monolithic, giant construction project updates every two to three years -- from Office XP, to Office 2003, to Office 2007 -- websites can be deployed far more often. Seasonally, if you will. Some websites even "harvest" monthly, organically growing new features and bugfixes each time. The guys at 37Signals apparently noticed this, too.

It recently dawned on me that software grows much in the same way that plants grow. New features are the flowers of the software world. And just as most plants aren't flowering all year long, software isn't sprouting features all year long. There's flowering season. There's new feature season. There's infrastructure season.

Sometimes software is working on its roots. Bolstering its infrastructure. It's growing underground where the public can't see it. It looks like nothing's happening, but there’s really a lot going on. Without those roots new features can't sprout.

And sometimes it's rest time. Plants rest in the winter. Software often rests in the summer (it's too nice to work too hard in the summer). Everything can benefit from a deep breath, relaxation, and sleep. Chaotic constant growth and change doesn't make room for order and organization. Growth requires new energy and new energy requires rest.

Another thing I've noticed is that tending to websites, which usually have community features and user-generated content at the forefront, feels a heck of a lot like weeding your garden. You grow a lot of content, but not all of it is exactly what you had in mind.

I scrutinize every comment, and I remove a tiny percentage of them: they might be outright spam, patently off-topic, or just plain mean. I like to refer to this as weeding my web garden. It's a productivity tax you pay if you want to grow a bumper crop of comments, which, despite what Joel says, often bear such wonderful fruit. The labor can be minimized with improved equipment, but it's always there in some form. And I'm OK with that. The myriad benefits of a robust comment ecosystem outweighs the minor maintenance effort.

And when you don't weed your garden? The weeds threaten to choke out your crops. Eventually, your software garden looks neglected, and then abandoned.

As Steve says, some software development metaphors are better than others. But when it comes to web development, at least, you could certainly do a lot worse than tending to your software garden.

While I've always practiced reasonable email hygiene, for the last 6 months I've been in near-constant email bankruptcy mode. This concerns me.

Yes, it's partly my fault for being a world champion procrastinator, but I'm not sure it's entirely my fault. There are forces at work here, factors that easily outstrip the efforts of any one measly human being, no matter how tenacious and dogged. Or, as in my case, no matter how lazy.

I've always liked Merlin Mann's explanation of this phenomenon:

Email is such a funny thing. People hand you these single little messages that are no heavier than a river pebble.

But it doesn't take long until you have acquired a pile of pebbles that's taller than you and heavier than you could ever hope to move, even if you wanted to do it over a few dozen trips. For the person who took the time to hand you their pebble, it seems outrageous that you can't handle that one tiny thing. "What 'pile'? It's just a f**ing pebble!"

The underlying problem is that individual human beings don't scale.

The net number of requests for my attention exceeds my ability to provide that attention by at least an order of magnitude. And the disparity around my ability to thoughtfully respond to my pile may be ten or more times worse still. The scale is insanely out of whack.

Email is certainly the backbone of the information economy, but it's also fundamentally and perhaps even fatally flawed. Tantek Çelik captured my thoughts perfectly with this post:

Last year when I posted The Three Hypotheses, they helped me explain why I found email so much less useful/usable than instant messaging (IM) and Twitter. Since then, I find that while I can keep up with more people contacting me over IM and following more people on Twitter, email has simply become less and less usable. But not for reasons of interface; I'm using the email application now as I was a year ago.

I'm probably responding to less than 1 in 10 emails that are sent directly to me, and even fewer that were sent to a set of people or a list. The usability of email for me has deteriorated so much that I exclaimed on Twitter: EMAIL shall henceforth be known as EFAIL.

The blanket equation of email with failure is strong language indeed, but it's a serious problem. The intrinsically low effort-to-reward ratio of private email is not necessarily a new idea; as I said in When In Doubt, Make It Public, it's almost never in anyone's best interest to keep their communications locked into private silos of any kind, email or otherwise. Why answer one person's email directly when I could potentially answer a thousand different people's email with a single blog post?

I urge you to read the full text of Tantek's article. He cuts to the heart of the email problem: size, in both the mental and physical dimensions.

Email requires more of an interface cognitive load tax than instant messaging. People naturally put much more into an email, perhaps in an unconscious effort to amortize that email interface tax overhead across more content. People feel that since they are already "bothering" to write an email, they might as well take the time to go into all kinds of detail, perhaps even adding a few more things that they're thinking about.

Such natural message bloat places additional load on the recipient, both in terms of the raw length of the message, and in terms of the depth and variety of topics covered in the email. This results in a direct increase in processing time per email, making it even harder for people to process and respond. I know I've let numerous emails grow stale because there were simply too many different things in the email that required a response. I didn't want to send a response without responding to everything in the email because then I would inevitably receive yet another email response without being able to file the original as being processed and thus have the situation worsen!

What we can to combat the email = efail problem? Take Tantek's advice: whenever possible, avoid sending email. Not because we don't want to communicate with our peers. Quite the contrary. We should avoid sending email out of a deep respect for our peers -- so that they are free to communicate as effectively and as often as possible with us.

1. Channel that private email effort into a public outlet. Discussion boards, blog entries, comments, wikis, you name it. If it can be indexed by a web search engine, you're in the right place -- and many more people can potentially find, answer, and benefit from that information.
   
   
2. If you must send email, make it as short as possible. Think of it as Strunk and White on speed. Can you reduce your email into a single paragraph? How about two sentences? How about just the title field with no body, even?
   
   
3. Remember the theory of communication escalation. Email is just one communication tool in our toolkit; that doesn't mean it is always the right one for whatever situation is at hand. Take advantage of phone calls, instant messaging, text messages, and so forth, as appropriate. Scale your choice of communication method to the type of conversation you're having, and don't be afraid to escalate it (or demote it!) as the ebb and flow of the conversation shifts.

So if you've emailed me, and I haven't responded in a timely fashion, I apologize. I know it may sound crazy, but I've been desperately clawing my way out from under this mountain of pebbles.

p.s. Email me if you agree with this.

I've been a fan of Dan Appleman for about as long as I've been a professional programmer. He is one of my heroes. Unfortunately, Dan only blogs rarely, so I was heartened to see a spate of recent blog updates from him. One of the entries asks a question I've often wondered myself: can you really rent a coder?

Over the past year or two I've kept an eye on the various online consulting sites - Elance, guru.com, RentACoder, oDesk. I've actually used RentACoder once (as a buyer on a very small project) and was satisfied with the results -- though I suspect I spent more time writing the spec and managing the programmers than I would if I had done the work myself.

I'm surprised Dan opens with such a sunny outlook on these services, because I've heard almost universally negative things about them. As professional programmers, I think we're all naturally inclined to see these sort of low-bid contract sites as cannibalizing and cheapening our craft. It's roughly analogous to the No-Spec movement for designers.

The odd thing is that, despite the sunny outlook, the article Dan wrote on this topic comes across as quite cautionary:

• You'll be competing with people around the world. In fact, you'll be amazed at how little people in some parts of the world will bid. That’s because a few dollars an hour can work well in a country where the average wage is a couple of hundred dollars a month.
  
  
• Many of the projects posted are unrealistic. For example, people asking for a clone of ebay for under $500. What ends up happening in these cases is that usually somebody ends up getting ripped off (either the client or the consultant who underbid or fails to deliver).
  
  
• A lot of projects go bad. They get cancelled. Or the consultant who bid on the work never delivered, or delivered poor results. Or the client has unreasonable expectations, or doesn’t actually know what he wants.

Maybe it's just my natural bias talking, but these sites seem awfully impractical to me.

Simply sorting out the DailyWTF project pitches from things you could actually deliver -- at ultra-competitive offshore programming rates, no less -- would require the patience of a saint and the endurance of an olympic athlete. Specification documents are hard enough to write when everyone involved is a coworker sitting in the same room. I can't even imagine the difficulty of agreeing on what it is you're building when the participants are thousands of miles away and have never met. But then I thought Amazon's Mechanical Turk was a failure, and it seems to be enjoying a moderate level of success.

Dan has a small chart comparing the services of these online freelance/consulting sites. It's too easy to write these sites off as an affront to software engineering. I guess they're sort of like dating sites -- they might be one way to find a client relationship, but I'd be highly suspicious of any professional developer who can't find a stable, long term relationship with a client eventually.

If nothing else, we should be looking at them for research purposes, as a baseline. Surely you can demonstrate better value to your employer than the random, anonymous programmers on Elance, guru.com, RentACoder, or oDesk. And I'd certainly hope that the projects you're working on are more sensible and rewarding (in both senses of the word) than the stuff that appears on those sites.

For as long as I've been a software developer and used bug tracking systems, we have struggled with the same fundamental problem in every single project we've worked on: how do you tell bugs from feature requests?

Sure, there are some obvious crashes that are clearly bugs. But that's maybe 10% of what you deal with on a daily basis, and the real killer showstopper bugs -- the ones that prevent normal usage of the system -- are eradicated quickly, lest the entire project fail. The rest of the entries in your bug tracking system, the vast majority, exist in an uncertain gray no-man's land. Did users report a bug? Not quite. Are users asking for a new or enhanced feature? Not quite. Well, which is it?

It's an insoluble problem. Furthermore, I think most bug tracking systems fail us because they make us ask the wrong questions. They force you to pick a side. Hatfields vs. McCoys. Coke vs. Pepsi. Bug vs. Feature Request. It's a painful and arbitrary decision, because most of the time, it's both. There's no difference between a bug and a feature request from the user's perspective. If you want to do something with an application (or website) and you can't do it because that feature isn't implemented -- how is that any different than not being able to do something due to an error message?

Consider an example: Visual Studio doesn't use the correct font when building Windows applications. Is this a bug or a feature request?

Personally, I consider this a bug. I guess Microsoft does too, at least in theory, because it's been in Microsoft's Connect bug tracking system for over four years now. When you build a Windows application, wouldn't you expect it to use the default font of the underlying operating system you're running it on, unless you've explicitly told it otherwise? Well, guess what happens when you create a new form in Visual Studio 2008 and instantiate a label control.

Party like it's 1996, folks, because you'll get MS Sans Serif, and you'll like it. That is the default for each new form. Never mind that every new application you build will look like -- let me put this as delicately as I can -- ass.

Here's a comparison of a label with the default font, versus one that was explicitly set to the default GUI font.

Judging by the applications I've used, most Windows developers couldn't care less about design. That's bad. What's even worse is learning that same design carelessness has shipped in the box with every copy of Visual Studio since 2002.

Of course, matters of design are so subjective. If only there were some definitive source we could refer to on the matter of proper Windows GUI font usage. Some sort of reference standard, as it were. Like, say, the top rules for Windows Vista User Experience from Microsoft:

1. Use the Aero Theme and System Font (Segoe UI)
2. Use common controls and common dialogs
3. Use the standard window frame, use glass judiciously

There are 12 rules in total, but the rule I'm looking for is right at the top -- applications should use the system font.

The hilarity of this list is already sort of self evident, given that I've written an entire post bemoaning the general lack of fit and finish in Windows Vista. I couldn't help but laugh at rule number 12: Reserve time for "fit and finish"! Now there's a rule Microsoft should have taken to heart while developing Windows Vista. Understand this is all coming from a guy who likes Vista.

But I digress.

Despite the windows forms font behavior in Visual Studio 2008 contradicting rule number one of Microsoft's own design guidelines, this "bug" has gone unfixed for over four years. It has been silently reclassified as a "feature request" and effectively ignored. Nothing's broken, after all: using the wrong font hasn't caused any application crashes or lost productivity. On the other hand, imagine how many BigCorpCo apps have been built since then that violate Microsoft's own design rules for their platform. Either because the developers didn't realize that the app font didn't match the operating system, or because they didn't have the time to write the workaround code necessary to make it do the right thing.

Yes, this is a small thing. And I'm sure fixing it wouldn't result in selling an additional umpteen thousand Visual Studio licenses to BigCorpCo, which is why it hasn't happened yet.

But the question remains: is this a bug, or a feature request?

One of my favorite things about UserVoice -- which we use for Stack Overflow -- is the way it intentionally blurs the line between bugs and feature requests. Users never understand the difference anyway, and what's worse, developers tend to use that division as a wedge against users. Nudge things you don't want to do into that "feature request" bucket, and proceed to ignore them forever. Argue strongly and loudly enough that something reported as a "bug" clearly isn't, and you may not have to to do any work to fix it. Stop dividing the world into Bugs and Feature Requests, and both of these project pathologies go away.

I wish we could, as an industry, spend less time fighting tooth and nail over definitions, painstakingly placing feedback in the "bug" or "feature request" buckets -- and more time doing something constructive with our users' feedback.

Remember last week when I said coding was just writing?

I was wrong. As one commenter noted, it's even simpler than that.

[This] reminds me of a true "Dilbert moment" a few years ago, when my (obviously non-technical) boss commented that he never understood why it took months to develop software. "After all", he said, "it's just typing."

Like broken clocks, even pointy-haired managers are right once a day. Coding is just typing.

So if you want to become a great programmer, start by becoming a great typist. Just ask Steve Yegge.

I can't understand why professional programmers out there allow themselves to have a career without teaching themselves to type. It doesn't make any sense. It's like being, I dunno, an actor without knowing how to put your clothes on. It's showing up to the game unprepared. It's coming to a meeting without your slides. Going to class without your homework. Swimming in the Olympics wearing a pair of Eddie Bauer Adventurer Shorts.

Let's face it: it's lazy.

There's just no excuse for it. There are no excuses. I have a friend, John, who can only use one of his hands. He types 70 wpm. He invented his own technique for it. He's not making excuses; he's typing circles around people who are making excuses.

I had a brief email exchange with Steve back in March 2007, after I wrote Put Down The Mouse, where he laid that very same Reservoir Dogs quote on me. Steve's followup blog post was a very long time in coming. I hope Steve doesn't mind, but I'd like to pull two choice quotes directly from his email responses:

I was trying to figure out which is the most important computer science course a CS student could ever take, and eventually realized it's Typing 101.

The really great engineers I know, the ones who build great things, they can type.

Strong statements indeed. I concur. We are typists first, and programmers second. It's very difficult for me to take another programmer seriously when I see them using the hunt and peck typing techniques. Like Steve, I've seen this far too often.

First, a bit of honesty is in order. Unlike Steve, I am a completely self-taught typist. I didn't take any typing classes in high school. Before I wrote this blog post, I realized I should check to make sure I'm not a total hypocrite. So I went to the first search result for typing test and gave it a shot.

I am by no means the world's fastest typist, though I do play a mean game of Typing of the Dead. Let me emphasize that this isn't a typing contest. I just wanted to make sure I wasn't full of crap before I posted this. I know, there's a first time for everything. Maybe this'll be the start of a trend. Doubtful, but you never know.

Steve and I believe there is nothing more fundamental in programming than the ability to efficiently express yourself through typing. Note that I said "efficiently" not "perfectly". This is about reasonable competency at a core programming discipline.

Maybe you're not convinced that typing is a core programming discipline. I don't blame you, although I do reserve the right to wonder how you manage to program without using your keyboard.

Instead of answering directly, let me share one of my (many) personal foibles with you. At least four times a day, I walk into a room having no idea why I entered that room. I mean no idea whatsoever. It's as if I have somehow been teleported into that room by an alien civilization. Sadly, the truth is much less thrilling. Here's what happened: in the brief time it took for me to get up and move from point A to point B, I have totally forgetten whatever it was that motivated me to get up at all. Oh sure, I'll rack my brain for a bit, trying to remember what I needed to do in that room. Sometimes I remember, sometimes I don't. In the end, I usually end up making multiple trips back and forth, remembering something else I should have done while I was in that room after I've already left it.

It's all quite sad. Hopefully your brain has a more efficient task stack than mine. But I don't fault my brain -- I fault my body. It can't keep up. If I had arrived faster, I wouldn't have had time to forget.

What I'm trying to say is this: speed matters. When you're a fast, efficient typist, you spend less time between thinking that thought and expressing it in code. Which means, if you're me at least, that you might actually get some of your ideas committed to screen before you completely lose your train of thought. Again.

Yes, you should think about what you're doing, obviously. Don't just type random gibberish as fast as you can on the screen, unless you're a Perl programmer. But all other things being equal -- and they never are -- the touch typist will have an advantage. The best way to become a touch typist is through typing, and lots of it. A little research and structured practice couldn't hurt either. Here are some links that might be of interest to the aspiring touch typist:

• Type Racer
• Typer Shark
• Dvorak, Keyboard Layout of Champions
• Colemak keyboard layout
• TyperA
• Das Keyboard with blank keys
• The Typing of the Dead (for PC)
• Put Down That Mouse. Seriously. It's a crutch.
• Typingmania (warning, Japanophiles only)

(But this is a meager and incomplete list. What tools do you recommend for becoming a better typist?)

There's precious little a programmer can do without touching the keyboard; it is the primary tool of our trade. I believe in practicing the fundamentals, and typing skills are as fundamental as it gets for programmers.

Hail to the typists!

Ever heard a software engineer refer to a problem as "NP-complete"? NP-complete is fancy computer science jargon shorthand for "incredibly hard":

The most notable characteristic of NP-complete problems is that no fast solution to them is known; that is, the time required to solve the problem using any currently known algorithm increases very quickly as the size of the problem grows. As a result, the time required to solve even moderately large versions of many of these problems easily reaches into the billions or trillions of years, using any amount of computing power available today. As a consequence, determining whether or not it is possible to solve these problems quickly is one of the principal unsolved problems in Computer Science today.

While a method for computing the solutions to NP-complete problems using a reasonable amount of time remains undiscovered, computer scientists and programmers still frequently encounter NP-complete problems. An expert programmer should be able to recognize an NP-complete problem so that he or she does not unknowingly waste time trying to solve a problem which so far has eluded generations of computer scientists.

You do want to be an expert programmer, don't you? Of course you do!

NP-complete problems are like hardcore pornography. Nobody can define what makes a problem NP-complete, exactly, but you'll know it when you see it. Just this once, I'll refrain from my usual practice of inserting images to illustrate my point.

Instead, I'll recommend a book Anthony Scian recommended to me: Computers and Intractability: A Guide to the Theory of NP-Completeness.

Like all the software engineering books I recommend, this book has a timeless quality. It was originally published in 1979, a shining testament to smart people attacking truly difficult problems in computer science: "I can't find an efficient algorithm, but neither can all these famous people."

So how many problems are NP-complete? Lots.

Even if you're a layman, you might have experienced NP-Completeness in the form of Minesweeper, as Ian Stewart explains. But for programmers, I'd argue the most well known NP-completeness problem is the travelling salesman problem.

Given a number of cities and the costs of travelling from any city to any other city, what is the least-cost round-trip route that visits each city exactly once and then returns to the starting city?

The brute-force solution -- trying every possible permutation between the cities -- might work for a very small network of cities, but this quickly becomes untenable. Even if we were to use theoretical CPUs our children might own, or our children's children. What's worse, every other algorithm we come up with to find an optimal path for the salesman has the same problem. That's the common characteristic of NP-complete problems: they are exercises in heuristics and approximation, as illustrated by this xkcd cartoon:

What do expert programmers do when faced by an intractable problem? They cheat. And so should you! Indeed, some of the modern approximations for the Travelling Salesman Problem are remarkably effective.

Various approximation algorithms, which quickly yield good solutions with high probability, have been devised. Modern methods can find solutions for extremely large problems (millions of cities) within a reasonable time, with a high probability of being just 2-3% away from the optimal solution.

Unfortunately, not all NP-complete problems have good approximations. But for those that do, I have to wonder: if we can get so close to an optimal solution by cheating, does it really matter if there's no known algorithm to produce the optimal solution? If I've learned nothing else from NP-complete problems, I've learned this: sometimes coming up with clever cheats can be more interesting than searching in vain for the perfect solution.

Consider the First Fit Decreasing algorithm for the NP-complete Bin Packing problem . It's not perfect, but it's incredibly simple and fast. The algorithm is so simple, in fact, it is regularly demonstrated at time management seminars. Oh, and it guarantees that you will get within 22% of the perfect solution every time. Not bad for a lousy cheat.

So what's your favorite NP-complete cheat?

If you've ever searched for anything, you've probably run into stop words. Stop words are words so common they are typically ignored for search purposes. That is, if you type in a stop word as one of your search terms, the search engine will ignore that word (if it can). If you attempt to search using nothing but stop words, the search engine will throw up its hands and tell you to try again.

Seems straightforward enough. But there can be issues with stop words. Imagine, for example, you wanted to search for information on this band.

"The" is one of the most common words in the English language, so a naive search for "The The" cannot end well.

Let's consider some typical English stopword lists.

You'd think a pure count of frequency, how often the word occurs, would be enough to make a common group of words "stop words", but apparently not everyone agrees. The default SQL Server stop word list is much larger than the Oracle stop word list. What makes "many" a stop word to Microsoft, but not to Oracle? Who knows. And I'm not even going to show the MySQL full text search stop word list here, because it's enormous, easily double the size of the SQL Server stop word list.

These are just the default stop word lists; that doesn't mean you're stuck with them. You can edit the stop word list for any of these databases. Depending on what you're searching, you might decide to have different stop words entirely, or maybe no stop words at all.

Way back in 2004, I ran a little experiment with Google -- over a period of a week, I searched for an entire dictionary of ~110k individual English words and recorded how many hits Google returned for each.

Yes, this is probably a massive violation of the Google terms of service, but I tried to keep it polite and low impact -- I used Gzip compressed HTTP requests, specified only 10 search results should be returned per query (as all I needed was the count of hits), and I added a healthy delay between queries so I wasn't querying too rapidly. I'm not sure this kind of experiment would fly against today's Google, but it worked in 2004. At any rate, I ended up with a MySQL database of 110,000 English words and their frequency in Google as of late summer 2004. Here are the top results:

Again, a very different list than what we saw from SQL Server or Oracle. I'm not sure why the results are so strikingly different. Also, the web (or at least Google's index of the web) is much bigger now than it was in 2004; a search for "the" returns 13.4 billion results -- that's 25 times larger than my 2004 result of 522 million.

On Stack Overflow, we warn users via an AJAX callback when they enter a title composed entirely of stop words. It's hard to imagine a good title consisting solely of stopwords, but maybe that's just because our technology stack isn't sufficiently advanced yet.

Google doesn't seem to use stop words any more, as you can see from this search for "to be or not to be".

Indeed, I wonder if classic search stop words are relevant in modern computing; perhaps they're a relic of early 90's computing that we haven't quite left behind yet. We have server farms and computers perfectly capable of handling the extremely large result sets that result from querying common English words. A Google patent filed in 2004 and granted in 2008 seems to argue against the use of stop words.

Sometimes words and phrases that might be considered stopwords or stop-phrases may actually be meaningful or important. For example, the word "the" in the phrase "the matrix" could be considered a stopword, but someone searching for the term may be looking for information about the movie "The Matrix" instead of trying to find information about mathematical information contained in a table of rows and columns (a matrix).

A search for "show me the money" might be looking for a movie where the phrase was an important line, repeated a few times in the movie. Or a search for "show me the way" might be a request to find songs using that phrase as a title from Peter Frampton or from the band Styx.

A Google patent granted this week explores how a search engine might look at queries that contain stopwords or stop-phrases, and determine whether or not the stopword or stop-phrase is meaningful enough to include in search results shown to a searcher.

Apparently, at least to Google, stop word warnings are a thing of the past.

Hello, my name is Jeff Atwood, and I'm an addict.

I'm addicted... to video cards.

In fact, I've been addicted since 1996. Well, maybe a few years earlier than that if you count some of the classic 2D accelerators. But the true fascination didn't start until 1996, when the first consumer hardware 3D accelerators came to market. I followed their development avidly in newsgroups, and tried desperately to be the first kid on my block to own the first one. And boy did I ever succeed. Here's a partial list of what I remember owning in those early days:

• Rendition Verite V1000
• 3dfx Voodoo
• 3dfx Voodoo 2
• ATI Rage Pro
• NVIDIA Riva 128
• Matrox G400
• NVIDIA Riva TNT
• NVIDIA GeForce 256

(This is only a partial list, ranging from about 1996 to 2001 -- I don't want to bore you. And believe me, I could. I mean more than I already am.)

These were heady times indeed for 3D graphics enthusiasts (read: PC gamers). I distinctly remember playing the first DOS-based Tomb Raider on my 3dfx Voodoo using the proprietary GLIDE API. Sure, it's pathetic by today's standards, but the leap from software 3D to fast hardware 3D was quite dramatic from the trenches -- and far more graphically powerful than any console available.

This was a time when you could post a thread on a usenet newsgroup about a brand new 3D card, and one of the creators of the hardware would respond to you, as Gary Tarolli did to me:

I first want to say how rewarding it is to read all your reviews after having worked on the design of Voodoo Graphics (the chipset on the Orchid Righteous 3D board) for over two years. I am one of the founders of 3Dfx and one of our goals was to deliver the highest quality graphics possible to the PC gamer. It was and still is a very risky proposition because of the cost sensitivity of the marketplace. But your reviews help convince me that we did the right thing.

I thought I would share with you a little bit about what is inside the 3Dfx Voodoo Graphics chipset. There are 2 chips on the graphics board. Each is a custom designed ASIC containing approximately 1 million transistors. Although this number of transistors is on the order of a 486, it is a lot more powerful. Why? Because the logic is dedicated to graphics and there's a lot of logic to boot. For example, bilinear filtering of texture maps requires reading four 16-bit texels per pixel (that's 400 Mbytes/sec at 50 Mpixels/sec) and then computing the equation red_result = r0*w0+r1*w1+r2*w2+r3*w3 where r0:3 are the four red values and w0:3 are the four weights based on the where the pixel center lies with respect to the four texels. This is performed for each color channel (red, green, blue, alpha) resulting in 16 multiples and 12 additions or 28 operations per pixel. At 50 Mpixels per second that is 1,400 Mops/sec. The way this is designed in hardware is you literally place 16 multipliers and 12 adders on the chip and hook them together. And this is only a small part of one chip. There are literally dozens of multipliers and dozens of adders on each of the two chips dedicated only to graphics. Each chip performs around 4,000 million actual operations per second, of which around one third are integer multiplies. These are real operations performed - if you were to try to do these on a CPU (or a DSP) you must also do things like load/store instructions and conditions. In my estimation it would take about a 10,000 Mip computer (peak) to do the same thing that one of our chips does. This is about 20 of the fastest P5-200 or P6-200 chips per one of our chips. Not exactly cost-effective. So if you want to brag, you can say your graphics card has approximately the same compute power as 40 P5-200 chips. Of course, these numbers are more fun than they are meaningful. What is meaningful in graphics is what you see on the screen.

Now of course, if you were writing a software renderer for a game, you wouldn't attempt to perform the same calculations we perform on our chip on a general purpose CPU. You would take shortcuts, like using 8-bit color with lookup tables for blending, or performing perspective correction every (n) pixels. The image quality will depend on how many shortcuts you take and how clever you are. Voodoo Graphics takes no shortcuts and was designed to give you the highest quality image possible within the constraint of 2 chips. As your reviews have shown, it is evident that you can see the difference in quality and performance.

There's nothing quite like having a little chat on usenet with the founder of the company who created the 3D accelerator you just bought. Like I said, it was a simpler time.

Just imagine something with the power of forty Pentium-200 chips! Well, you don't have to. There's probably a CPU more powerful than that in your PC right now. But the relative scale of difference in computational power between the CPU and a GPU hasn't changed -- special purpose GPUs really are that much more powerful than general purpose CPUs.

After that first taste of hot, sweet GPU power, I was hooked. Every year since then I've made a regular pilgrimage to the temple of the GPU Gods, paying my tithe and bringing home whatever the latest, greatest, state-of-the art in 3D accelerators happens to be. What's amazing is how often, even now, performance doubles yearly.

This year, I chose the NVIDIA GTX 280. Specifically, the MSI NVIDIA GTX 280 OC, with 1 GB of memory, overclocked out of the box. I hate myself for succumbing to mail-in rebates, but they get me every time -- this card was $375 after rebate.

$375 is expensive, but this is still the fastest single card configuration available at the moment. It's also one heck of a lot cheaper than the comically expensive $650 MSRP these cards were introduced at in June. Pity the poor rubes who bought these cards at launch! Hey, wait a second -- I've been one of those rubes for 10 years now. Never mind.

This is the perfect time to buy a new video card -- before Thanksgiving and running up to Christmas is prime game release season. All the biggest games hit right about now. Courtesy of my new video card and the outstanding Fallout 3, my productivity last week hit an all-time low. But oh, was it ever worth it. I'm a long time Fallout fan, even to the point that our wedding pre-invites had secret geek Fallout art on them. Yes, that was approved by my wife, because she is awesome.

I must say that experiencing the wasteland at 60 frames per second, 1920 x 1200, in high dynamic range lighting, with every single bit of eye candy set to maximum, was so worth it. I dreamt of the wastelands.

In fact, even after reaching the end of the game, I'm still dreaming of them. I've heard some claim Fallout 3 is just Oblivion with guns. To those people, I say this: you say that like it's a bad thing. The game is incredibly true to the Fallout mythos. It's harsh, gritty, almost oppressive in its presentation of the unforgiving post-apocalyptic wasteland -- and yet there's always an undercurrent of dark humor. There are legitimate good and evil paths to every quest, and an entirely open-ended world to discover.

No need to take my word for it, though. I later found some hardware benchmark roundups that confirmed my experience: the GTX 280 is crazy fast in Fallout 3.

Of course, we wouldn't be responsible PC owners if we didn't like to mod our hardware a bit. That's what separates us from those knuckle-dragging Mac users: skill. (I kid, I kid!) First, you'll want to download a copy of the amazing little GPU-Z application, which will show you in real time what your video card is doing.

A little load testing is always a good idea, particularly since I got a bum card with my first order -- it would immediately shoot up to 105 C and throttle within a minute or two of doing anything remotely stressful in 3D. It worked, but the resulting stuttering was intolerable, and the fan noise was unpleasant as the card worked overtime to cool itself down. I'm not sure how I would have figured that out without the real time data and graphs that GPU-Z provides. I returned it for a replacement, and the replacement's behavior is much more sane; compare GPU-Z results at idle (left) and under RTHDRIBL load (right):

Fortunately, there's not much we need to do to improve things. The Nvidia 8800 and GTX series are equipped with outstanding integrated coolers which directly exhaust the GPU heat from the back of the PC. I'd much rather these high powered GPUs exhaust their heat outward instead of blowing it around inside the PC, so this is the preferred configuration out of the box. However, the default exhaust grille is incredibly restrictive. I cut half of the rear plate away with a dremel, which immediately reduced fan speeds 20% (and thus, noise 20%) due to the improvement in airflow.

Just whip out your trusty dremel (you do own a dremel, right?) and cut along the red line. It's easy. If you're a completionist, you can apply better thermal paste to the rest of the card to eke out a few more points of efficiency with the cooler.

Extreme? Maybe. But I like my PCs powerful and quiet. That's another thing that attracted me to the GTX 280 -- for a top of the line video card, it's amazingly efficient at idle. And despite my gaming proclivities, it will be idle 98% of the time.

I do love this new video card, but I say that every year. I try not to grow too attached. I'm sure this video card will be replaced in a year with something even better.

What else would you expect from an addict?

In The Programming Aphorisms of Strunk and White, James Devlin does a typically excellent job of examining something I've been noticing myself over the last five years:

The unexpected relationship between writing code and writing.

There is perhaps no greater single reference on the topic of writing than Strunk and White's The Elements of Style. It's one of those essential books you discover in high school or college, and then spend the rest of your life wondering why other textbooks waste your time with all those unnecessary words to get their point across. Like all truly great books, it permanently changes the way you view the world, just a little.

Wikipedia provides a bit of history and context for this timeless book:

[The Elements of Style] was originally written in 1918 and privately published by Cornell University professor William Strunk, Jr., and was first revised with the help of Edward A. Tenney in 1935. In 1957, it came to the attention of E. B. White at The New Yorker. White had studied under Strunk in 1919 but had since forgotten the "little book" which he called a "forty-three-page summation of the case for cleanliness, accuracy, and brevity in the use of English."

A few weeks later, White wrote a piece for The New Yorker lauding Professor Strunk and his devotion to "lucid" English prose. The book's author having died in 1946, Macmillan and Company commissioned White to recast a new edition of The Elements of Style, published in 1959. In this revision, White independently expanded and modernized the 1918 work, creating the handbook now known to millions of writers and students as, simply, "Strunk and White". White's first edition sold some two million copies, with total sales of three editions surpassing ten million copies over a span of four decades.

This is all well and good if you plan to become a writer, but what's the connection between this timeless little book and writing a computer program?

Writing programs that the computer can understand is challenging, to be sure. That's why so few people, in the big scheme of things, become competent programmers. But writing paragraphs and sentences that your fellow humans can understand -- well, that's even more difficult. The longer you write programs and the older you get, eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.

Of all the cruel tricks in software engineering, this has to be the cruelest. Most of us entered this field because the machines are so much more logical than people. And yet, even when you're writing code explicitly intended for the machine, you're still writing. For other people. Fallible, flawed, distracted human beings just like you. And that's the truly difficult part.

I think that's what Knuth was getting at with his concept of Literate Programming (pdf).

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

This is, of course, much easier said than done. Most of us spend our entire lives learning how to write effectively. A book like The Elements of Style can provide helpful guideposts that translate almost wholesale to the process of coding. I want to highlight the one rule from Elements of Style that I keep coming back to, over and over, since originally discovering the book so many years ago.

13. Omit needless words.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.

What does this say to you about your writing? About your code?

Coding, after all, is just writing. How hard can it be?

My recent post on netbooks reminded me of Alan Kay's original 1972 Dynabook concept (pdf).

We now have some reasons for wanting the DynaBook to exist. Can it be fabricated from currently invented technology in quantities large enough to bring a selling (or renting) price within reach of millions of potential users? The set of considerations which pertain to the more practical aspects of the device (such as size, cost, capability, etc.) are just as important as the more abstruse philosophy which prompted us in the first place. The next few pages discuss some of the tradeoffs involved, and will attempt to convince the reader that a target price of $500 is not totally outrageous. The current cost trends and size of the various components do offer considerable hope that the target can be reached. The analogy to color TVs which can be sold for under S500 is also important to keep in mind.

Now, what should the DynaBook be?

The size should be no larger than a notebook; weight less than 4 pounds. The visual display should be able to present at least 4000 printing quality characters with contrast ratios approaching that of a book. Dynamic graphics of reasonable quality should be possible; there should be removable local file storage of at least one million characters (about 500 ordinary book pages) traded off against several hours of audio (voice/music) files.

The active interface should be a language which uses linguistic concepts not far removed from the owner of the device. The owner will be able to maintain and edit his own files of text and programs when and where he chooses. He can use his DynaBook as a terminal when at work (or as a connection to the library system when in school).

When he is done perusing and has discovered information that he wishes to abstract and take with him, it can rapidly be transferred to his local file storage. The umbilical connection will supply not only information but also extra power for any motors the device might have, allowing high bandwidth transmission of about 300K bits/sec to the file storage, or one 500-page-book in 1/2 minute. The batteries will also be automatically recharging during this connection.

A netbook with a 3G wireless / wifi internet connection is almost eerily close to Kay's original Dynabook concept. It only took, what, thirty-six years?

Most netbooks have coalesced around these rough specs, as documented on the excellent netbook-centric website Liliputing:

• 1.6GHz Intel Atom CPU
• 9 or 10 inch, 1024 x 600 pixel display
• high capacity hard drive or relatively small (and cheap/slow) solid state disk
• 802.11 b/g wireless
• 2.5 hour battery life with standard size battery
• 2 to 3 pounds
• approximately $350 - $399

Do netbooks meet the criteria outlined in Kay's original 1972 Dynabook paper? To my eye, yes. They're far cheaper once you factor in inflation relative to his original $500 price point in 1972 dollars. I referred to netbooks as portable web browsers and I stilll believe that is in fact what they are -- inexpensive, ubiquitious, (mostly) full featured portals into the larger internet.

But Kay, in a recent interview with Wired, isn't so sure this is a good thing:

Wired.com: What do you think of netbooks? They're lightweight and small -- pretty close to two pounds. Do they still need work before they can meet your definition of a Dynabook?

Kay: I'd like to think that they are finding a form factor and weight that fits human beings better, but I'm presuming that it is because many people use only a small part of what they could do on their larger machines, and much of what they do use computers for can be done through a browser or a few simple apps. So this would be somewhat similar to the limited uses of computing that fit into other even smaller devices such as phones and PDAs. If so, then this is more disappointing than something to be cheered about.

I cringe every time I use a browser for many reasons. The browser people had a chance to make a more integrated UI and functionality, but really did pretty much the opposite in almost all respects. But, because of the attraction, and even some real value of stuff on the internet, there is more pressure to do better. I would expect to see some real alternatives to the typical "bad defacto standard" browsers we've had to put up with.

There is much to be done here, and to even get back to a number of important integration and workflow ideas that were part of the PARC UI.

Apparently Kay doesn't think much of the current status quo, where you define the status quo as OS X, Windows, or Linux. I suspect much of Kay's objection to the web browser interface is the general passivity of browsing the web; bear in mind that Kay is an educator and originally intended Dynabooks as tools for children to create and explore with something like Logo.

Personally, my only objection to current netbook platforms is the stupidly huge power draw of the creaky old Intel 945 motherboard chipset they are typically built on.

Looking at these results, one can't help but think that the Atom could be an astoundingly power-efficient processor when coupled with a chipset and platform with a lower power use floor. Intel, of course, has such things in the works for other markets.

This is why most current netbooks have mediocre 2 to 2.5 hour battery life -- unless you pick up the mongo extra-large extended batteries, which of course increase size and weight.

I hooked up my trusty old kill-a-watt to my wife's netbook and measured almost no difference at all in power consumption between idle and full Prime 95 load. Intel's Atom CPU is truly astonishingly efficient -- a feat all the more impressive when you realize that on most laptops the CPU is, by far, the number one consumer of power. On our netbook, only 1 or 2 watts of the total ~25 watt idle power draw is attributable to the CPU, a tiny fraction of the overall power consumption. I tried turning off wireless and dimming the screen, but I couldn't get the power draw floor below 18 watts -- that's all attributable to the chipset.

Intel did a fantastic job on the Atom CPU, but they completely phoned it in on the chipset. The next generation of netbooks with more power efficient chipsets should easily double battery life. No question.

I think netbooks will be as revolutionary as Kay originally predicted with his DynaBook concept. Though we have only seen the beginning of this trend, I'm not sure the big players really understand how much these early netbooks have already changed the game. It'll probably take several more years for the rest of the market to catch on.

I like to take one or two books with me when I travel, and one of the books I chose for this trip is HCI Remixed.

Sometimes the books I choose are a bust. Fortunately that didn't happen this time.

HCI Remixed covers all the major milestones in the field of human computer interaction. And when I say major, I mean it: things like Douglas Engelbart's famous demonstration, now referred to as The Mother of All Demos:

On December 9, 1968, Douglas C. Engelbart and the group of 17 researchers working with him in the Augmentation Research Center at Stanford Research Institute in Menlo Park, CA, presented a 90-minute live public demonstration of the online system, NLS, they had been working on since 1962. The public presentation was a session in the Fall Joint Computer Conference held at the Convention Center in San Francisco, and it was attended by about 1,000 computer professionals. This was the public debut of the computer mouse. But the mouse was only one of many innovations demonstrated that day, including hypertext, object addressing and dynamic file linking, as well as shared-screen collaboration involving two persons at different sites communicating over a network with audio and video interface.

So, all those trappings of modern computing that we take for granted today? Engelbart demonstrated them all two years before I was born. It just took a while for the rest of the world to catch up to his vision.

That's the lesson of many of the groundbreaking HCI discoveries presented in this book. Some people see further. Engelbart was so far ahead of his time in 1968 that his demonstration wasn't taken seriously -- it seemed absurd and impractical. It really makes you wonder which of today's HCI researchers we're ignoring but shouldn't be.

The book also takes an interesting approach; it doesn't summarize the papers, instead, it presents the reflections of current working HCI professionals on the papers. It's a little bit meta. You're hearing the impact of these HCI discoveries -- some big, some small -- as related by young researchers who were heavily influenced by them.

As a primer and overview of the field of human computer interaction, it's tough to beat. Reading this reminds me how far we've come, and yet how far we have to go.

URLs are simple things. Or so you'd think. Let's say you wanted to detect an URL in a block of text and convert it into a bona fide hyperlink. No problem, right?

Visit my website at http://www.example.com, it's awesome!

To locate the URL in the above text, a simple regular expression should suffice -- we'll look for a string at a word boundary beginning with http:// , followed by one or more non-space characters:

\bhttp://[^\s]+

Piece of cake. This seems to work. There's plenty of forum and discussion software out there which auto-links using exactly this approach. Although it mostly works, it's far from perfect. What if the text block looked like this?

My website (http://www.example.com) is awesome.

This URL will be incorrectly encoded with the final paren. This, by the way, is an extremely common way average everyday users include URLs in their text.

What's truly aggravating is that parens in URLs are perfectly legal. They're part of the spec and everything:

only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL.

Certain sites, most notably Wikipedia and MSDN, love to generate URLs with parens. The sites are lousy with the damn things:

http://en.wikipedia.org/wiki/PC_Tools_(Central_Point_Software)
http://msdn.microsoft.com/en-us/library/aa752574(VS.85).aspx

URLs with actual parens in them means we can't take the easy way out and ignore the final paren. You could force users to escape the parens, but that's sort of draconian, and it's a little unreasonable to expect your users to know how to escape characters in the URL.

http://en.wikipedia.org/wiki/PC_Tools_%28Central_Point_Software%29
http://msdn.microsoft.com/en-us/library/aa752574%28VS.85%29.aspx

To detect URLs correctly in all most cases, you have to come up with something more sophisticated. Granted, this isn't the toughest problem in computer science, but it's one that many coders get wrong. Even coders with years of experience, like, say, Paul Graham.

If we're more clever in constructing the regular expression, we can do a better job.

\(?\bhttp://[-A-Za-z0-9+&@#/%?=~_()|!:,.;]*[-A-Za-z0-9+&@#/%=~_()|]

1. The primary improvement here is that we're only accepting a whitelist of known good URL characters. Allowing arbitrary random characters in URLs is setting yourself up for XSS exploits, and I can tell you that from personal experience. Don't do it!
2. We only allow certain characters to "end" the URL. Ending a URL in common punctuation marks like period, exclamation point, semicolon, etc means those characters will be considered end-of-hyperlink characters and not included in the URL.
3. Parens, if present, are allowed in the URL -- and we absorb the leading paren, if it is there, too.

I couldn't come up with a way for the regex alone to distinguish between URLs that legitimately end in parens (ala Wikipedia), and URLs that the user has enclosed in parens. Thus, there has to be a handful of postfix code to detect and discard the user-enclosed parens from the matched URLs:

if (s.StartsWith("(") && s.EndsWith(")"))
{
    return s.Substring(1, s.Length - 1);
}

That's a whole lot of extra work, just because the URL spec allows parens. We can't fix Wikipedia or MSDN and we certainly can't change the URL spec. But we can ensure that our websites avoid becoming part of the problem. Avoid using parens (or any unusual characters, for that matter) in URLs you create. They're annoying to use, and rarely handled correctly by auto-linking code.