Coding Horror

One of the best things – if not the best thing – about Firefox is the rich, vibrant ecosystem of add-ons that has grown up around it. Almost anything you could possibly want to do with a web browser can be done with Firefox... if you're willing to hunt down the necessary extension. In Buy the Community, not the Product, I argued that this made Firefox the better browser. That's still true today.

But relying on extensions and add-ins isn't the whole story. Not by a long shot. Consider the average user who has no clue how fabulous those Firefox extensions may be, much less where to find them or how to install them. I'm not saying it's complicated, but any installation at all is too much work for a sizable percentage of the audience. They'll use the browser as it was supplied to them, forever. That's the power of defaults.

In 9 things Firefox should steal from Safari, Des highlighted some of the unique and innovative features in the Safari web browser:

• Improved current field highlighting
• Alternate font rendering
• Cleaner downloads dialog
• Faster HTML rendering
• Simple, painless bug reporting
• Visual incremental find
• Detachable tabs
• Draggable images
• Resizable text areas

All of these features are well worth copying and including in the core Firefox browser. Despite Des' thoughtful analysis, the avalanche of comments across Digg, Reddit, and Des' own site had one universal, monotonous response:

It seems the author simply hasn't really tried to use Firefox. 5 points can be changed by extensions, two are non existent, one is a Windows issue, and one is disputable.

Extensions, extensions, extensions. Indeed, why bother improving the core browser when you can force the user to install five extensions to duplicate that same functionality? This approach doesn't make any sense to me, and I think Des agrees:

Every day I see little things in Safari that could and should be copied. In Safari if I type destraynor.cmo into my url bar, it realises that there is no .cmo, and looks at previous sites I've visited, and sends me to destraynor.com. Firefox doesn't do that. Not without installing extensions. The majority of internet users, surprisingly, do not feel the need to install custom browser components. When they see Safari do something clever like this they don't think "Hey, that's cool, I better check mozilla.org to see if anyone has written an extension to spell check urls", they just think "Hey that's cool", or maybe "Hey that's cool, I wish firefox could do that." That's why you have to fight for every inch.

Since Des' initial post, Safari 3.1 was released with even more features. Firefox 3 isn't quite out yet, but Firefox 3.0 beta 4 offers a fairly complete picture of what the final version of Firefox 3 will look like later this year. The only feature that is no longer an issue on Des' original list is HTML rendering speed. All the others remain.

Extensions, as a solution to general software and productivity problems, have both dark and light sides.

Extensions offer wonderful enhancements to Firefox. It's a huge credit to the Firefox development team that they made extensions both easy to create and incredibly powerful. This is something that the Safari and IE teams appear incapable of doing. We can't even have this discussion about those browsers because their add-on ecosystems are pale shadows of the massive Firefox extension community. The Firefox team absolutely deserves all the market share they've earned from that one crucial decision.

But extensions are also an indictment of Firefox. If an extension is wildly popular and everyone urges you to install some "crucial" or "essential" extension in Firefox – shouldn't that extension have been baked into the browser in the first place? If I ran the Firefox development team, every new development cycle, I'd take the list of top 5 Firefox add-ins and demand that we fold that functionality into the core product.

Half the value of a robust add-in ecosystem lies in product guidance – users are taking it upon themselves to fill the gaps and holes in your product, and audience metrics tell you exactly which holes truly needed filling. Sure, there are some oddball extensions that only a few users might care about – but when extensions reach critical download mass and the same extensions appear repeatedly on best Firefox extension lists, they're filling a universal need. Ignoring that is just irresponsible software development, pure and simple.

If software developers were doing their jobs properly, an extension ecosystem wouldn't be necessary – 99% of the features users want and need would be already baked into the shipping software. And yet without a robust, powerful extension ecosystem, I suspect developers have a terrible idea of what features users actually do use and want. They're guessing.

It's sort of a Catch-22.

So when I see a user post an enormous list of Firefox extensions they've installed, as in the comments of this lifehacker post:

Or when I hear, as I often do, how someone couldn't possibly imagine using Firefox without the three or four extensions that they absolutely must have... I'm torn. How many of those nifty extensions are specialized functionality – and how many are crude spackle over missing features that really should have shipped in the box?

I've been a multiple monitor enthusiast since the dark days of Windows Millennium Edition. I've written about the manifold joys of many-monitor computing a number of times over the last four years:

• Multiple Monitors and Productivity
• Multiple LCDs
• Joining the Prestigious Three Monitor Club
• The Large Display Paradox
• LCD Monitor Arms

I have three monitors at home and at work. I'm what you might call a true believer. I'm always looking for ammunition for fellow developers to claim those second (and maybe even third) monitors that are rightfully theirs under the Programmer's Bill of Rights.

So I was naturally intrigued when I read about a new multiple monitor study from the University of Utah:

Researchers at the University of Utah tested how quickly people performed tasks like editing a document and copying numbers between spreadsheets while using three different computer configurations:

1. single 18-inch monitor
2. single 24-inch monitor
3. two 20-inch monitors

Here's what they found:

• People using the 24-inch screen completed the tasks 52% faster than people who used the 18-inch monitor
• People who used the two 20-inch monitors were 44% faster than those with the 18-inch ones.
• Productivity dropped off again when people used a 26-inch screen.

I dug around a bit and found the actual study results (pdf) or something very close to it, if you're looking for more detail than the summary I've presented above. This isn't the first time the University of Utah has conducted a multiple monitor study. It's very similar to the multiple monitor survey they conducted in 2003, also under the auspices of NEC. I agree it's a little sketchy to cite a study from a display vendor that advocates-- surprise-- buying more and bigger displays. But bear in mind they did find diminishing productivity returns with 26 inch displays. This is something I personally experienced, and I dubbed it the The Large Display Paradox. That finding isn't exactly going to endear them to display vendors.

Patrick Dubroy took a skeptical look at the multiple monitor productivity claims and found several credible sources of data. I'll combine his finds with mine to provide a one-stop-shop for research data supporting the idea that, yes, having more display space would in fact make you more productive:

• The Virtues of a Second Screen
• A Comparison of Single and Dual Traditional Aspect Displays with a Widescreen Display over Productivity (pdf)
• Toward Characterizing the Productivity Benefits of Very Large Displays (pdf)
• The 30-inch Apple Cinema HD Display Productivity Benchmark (pdf)

Patrick, despite his skepticism – and remember, this is a guy who didn't see a productivity difference between a 14 inch laptop display and a "big ass LCD" – came away convinced:

After looking at the studies, I think it's fair to say that some tasks can be made significantly faster if you have more screen real estate. On the other hand, I think it's clear that most programmers are not going to be 50% more productive over the course of a day just by getting a second monitor. The tasks that can be improved are not the bottleneck to programmer productivity.

I'm not sure what Patrick was expecting here. Let me be perfectly clear on this matter: more is more. More usable desktop space reduces the amount of time you spend on window management excise. Instead of incessantly dragging, sizing, minimizing and maximizing windows, you can do actual productive work. With a larger desktop, you can spend less time mindlessly arranging information, and more time interacting with and acting on that information. How much that matters to you will depend on your job and working style. Personally, I'd be ecstatic if I never had to size, position, or arrange another damn window for the rest of my life.

Choose own your path to happiness, whether it's upgrading to a single 30" display, dual 24" widescreen displays, or three standard 20" displays. As long as it results in more usable desktop space, it's a clear win. I support all of the above scenarios, and more importantly, the existing research does too. The price of a few monitors is negligible when measured against the labor cost of a programmer or information worker salary. Even if you achieve a meager two or three percent performance increase, it will have more than paid for itself.

What does get a little frustrating is when people claim that one large monitor should be "enough for anyone". This isn't a zero-sum game. Where there is one large monitor, there could be two large monitors, or three.

Sometimes, more is more.

Software internationalization is difficult under the best of circumstances, but it always amazed me how often one particular country came up in discussions of internationalization problems: Turkey.

For example, this Rick Strahl post from mid-2005 is one of many examples I've encountered:

I've been tracking a really funky bug in my West Wind Web Store application that seems to crop up only very infrequently in my error logs. In a previous post I mentioned that I had instituted some additional logging features, specifically making sure that I would also log the locale of the user accessing the application.

Well, three bug reports later I noticed that all errors occurred with a Turkish (tr) browser. So I changed my browser's default language to Turkish and sure enough I could see the error occur.

Or, say, this 2005 post from Scott Hanselman:

I had blogged earlier about a bug in dasBlog that affected Turkish users. When a Turkish browser reported an HTTP Accept-Language header indicating Turkish as the preferred language, no blog posts would show up. As fix, I suggested that users change their blog templates, but I knew that wasn't an appropriate fix.

I understand that Turkish prisons are not to be trifled with, but the question remains: why do Turkish people take such cruel and perverse delight in breaking our fine software? What's wrong with Turkey?

As with so many other problems in software development, the question shouldn't be what's wrong with Turkey, but rather, what the hell is wrong with software developers? Some of this is sort of obvious if you have any cultural awareness whatsoever.

• In the United States, we would typically format today's date as 3/14/2008. In Turkey, they format it as 14.3.2008.
• In the United States, we use commas to group digits, like so: 32,768. In Turkey, they group digits using a period, so the same number would be entered as 32.768.

These minor formatting differences are usually not a big deal for output and display purposes, but it's a whole different ballgame when you're parsing input. You'd naturally expect people to input dates and numbers in the format they're used to. If your code assumes that input will be in typical American English format, there will be… trouble.

Most languages have this covered; there are functions that allow you to read or write dates and numbers appropriately for various cultures. In .NET, for example, it's the difference between these two calls:

int.Parse("32.768");
int.Parse("32,768", System.Globalization.NumberFormatInfo.InvariantInfo);

Because no culture is specified, the first call will parse the number according to the rules of the default culture that code is running under. Let's hope it's running under a Turkish version of Windows, so it can parse the number correctly. The second call, however, explicitly specifies a culture. The "invariant" culture is every American programmer's secret dream realized: we merely close our eyes and wish away all those confusing languages and cultures and their crazy, bug-inducing date and number formatting schemes in favor of our own. A nice enough dream while it lasts, but instead of rudely asking your users to "speak American" through the invariant culture, you could politely ask them to enter data in ISO international standard format instead.

Anyway, point being, this kind of culture support is baked into most modern programming languages, so all you need to do is make sure your developers are aware of it – and more importantly, that they're thinking about situations when they might need to use it.

But all that date and time formatting stuff is easy. Or about as easy as i18n ever gets, anyway. Strings are where it really starts to get hairy. Guess where this code fails?

switch (myType.ToLower())
{
case "integer" : ;
}

If you guessed Turkey, you're wrong! Just kidding. Of course it fails in Turkey. When we convert the string "integer" to upper and lower case in the Turkish locale, we get some strange characters back:

"INTEGER".ToLower() = "ınteger"
"integer".ToUpper() = "İNTEGER"

It's sort of hard to see the subtle differences here unless we ratchet up the font size:

There's obviously no way these strings are going to match "integer" or "INTEGER" respectively. This is known as the Turkish I problem, and the solution should feel awfully familiar by now:

"INTEGER".ToLower(System.Globalization.CultureInfo.InvariantCulture)

That will produce the expected output, or at least, the output that matches the comparison in the original code snippet.

This is, of course, only the tip of the iceberg when it comes to internationalization. We haven't even touched on the truly difficult locales like Hebrew and Arabic. But I do agree with Jeff Moser – if your code can pass the Turkey test, you're doing quite well. Certainly better than most.

If you care a whit about localization or internationalization, force your code to run under the Turkish locale as soon as reasonably possible. It's a strong bellwether for your code running in most – but by no means all – cultures and locales.

The Choose Your Own Adventure book series was one of my favorites as a young reader.

The Choose Your Own adventure books are still around; modern versions can be found at your local bookstore. I bought one today at a local Barnes & Noble to refresh my memory, and although the overall experience is intact, I'm not terribly impressed with the updated art. The original illustrator, Don Hedin (using the pseudonym Paul Granger) had quite an eye for the often fantastic and surreal topics depicted in these books. Here are two illustrations from the first book in the series, The Cave of Time.

The cover art is just as brilliant, and in full color. Joey DeVilla put together a great montage of the original 66 Choose Your Own Adventure book covers. You can pick up the original Cave of Time – with funky, freaky late 1970s art intact – for a mere penny.

The Choose Your Own Adventure series are early programmer books, I'd say. Whether reading the modern updates, or through inheriting a worn hand-me-down copy, it's encouraging to think that future generations can have the same fun pseudo-programming experience I had reading and re-reading these classic books. Every few pages you make a decision, which leads to a different page in the book. If that sounds like branching and if-then logic – maybe even recursion and stacks – well, it is. Here's a diagram of all possible outcomes in the original Cave of Time book:

Although it's fun to explore and test all the permutations, the book is also a little bit grim.

Of the 39 possible outcomes in the book, only 11 are positive. More than two-thirds of the outcomes either result in the player's death, or being trapped somewhere in time, leading out an alternate life.

I suppose this is on my mind today because 28 years later, I feel like I'm still playing Choose Your Own Adventure:

You have landed your dream job as a technical evangelist for Vertigo Software. It is by far the best job you've ever had. Every day is fun. You've become close friends with your coworkers, who are all as passionate about software development as you are. However, over the last three years, the growing online popularity of your blog has eclipsed everything else you do, and opened up many new – but risky – opportunities.

---

If you choose to continue working and having fun with your friends at Vertigo, turn to page 8.
If you choose to quit your job and wholeheartedly pursue blog-related opportunities, turn to page 10.

I've spent the last six months staring at this page trying to figure out what to do. With some trepidation, I'm now turning to page 10. Thursday will be my last day at Vertigo. I will sorely miss the camaraderie and the many close personal friends I've made at Vertigo. Vertigo remains a fantastic place to work, and if you're a Microsoft ecosystem developer, I can't recommend it highly enough. I'm proud to be a distinguished Vertigo alumnus.

Sometimes choosing your own adventure means closing one door to open another. And I have to close the door on Vertigo, however reluctantly, to fully and wholeheartedly explore the alternatives. It would be unfair to Vertigo and to myself to do anything less. I'm not sure what exactly lies on page 10. I won't lie to you. It's scary to trade the security of a safe, salaried job for the unknowns of your own small business. But the way I look at it, if it's not a little scary, then it's not the right choice. Failure is always an option.

I can tell you that Coding Horror will continue, with a slightly increased emphasis on advertising – but always tastefully. I don't like ads any more than you do, even if I am now relying on them for a substantial part of my income.

But I refuse to become a full-time blogger. I think that's a cop-out. If I look at the people I respect most in the industry, the people I view as role models – Paul Graham, Joel Spolsky, Steve Yegge, Eric Sink, Rich Skrenta, Marc Andreesen, Wil Shipley, Douglas Crockford, Scott Guthrie – they all have one thing in common. They're not just excellent writers and communicators. They build stuff, too. The world has enough vapid commentary blogs. I want to build stuff – and talk about it. I have a little micro-ISV startup opportunity I'll be working on, a web property I'm building out with one of the above people. I'm not ready to announce the details yet, but when I do, you'll read about it here.

I can't guarantee I'm making the right choices, but nonetheless, I am choosing my own adventure. I invite you all to read along with me.

Like many programmers, my first exposure to ray tracing was on my venerable Commodore Amiga. It's an iconic system demo every Amiga user has seen at some point: behold the robot juggling silver spheres!

Thus begins the article in the May/June 1987 AmigaWorld in which Eric Graham explains how the Juggler was created. The program ("with full Intuition interface") promised at the end of the article was Sculpt 3D for the Amiga, released in the fall of 1987. Byte by Byte sold Amiga and then Macintosh and Windows variants of Sculpt for more than a decade.

Eric rendered the frames in a raytracer he wrote called ssg, a Sculpt precursor. The rendered images were encoded in the Amiga's HAM display mode and then assembled into a single data file using a lossless delta compression scheme similar to the method that would later be adopted as the standard in the Amiga's ANIM file format.

Eric and his wife Cathryn actively promoted raytracing on the Amiga. Cathryn wrote the Amiga Sculpt 3D user manual and compiled an electronic newsletter distributed on a series of disks. Raytracing 1.0, the earliest of these, contains both ssg and the static geometry of the juggler object, along with the Juggler image data and the player program.

Juggler was an astounding demo in its time. I personally remember staring at it for several minutes through the front window of a local Amiga dealer, wondering how it "worked." Many people were inspired by Juggler, and by the Amiga animations that followed, to pursue a career in 3D graphics. Nothing like it could have run on any other stock personal computer in 1986.

In fact, Eric recalled recently, the Commodore legal department initially "thought it was a hoax, and that I'd done the animation on a mainframe." He sent them his renderer so that they could generate and compile the frames themselves.

The juggler may seem primitive by today's standards. Maybe it is. I've been subjected to forum signature images with more frames of animation. But it was revelatory back in 1986. The Amiga brought 3D raytracing graphics to the masses for the first time. Ray tracing is extremely computation intensive, but hyper-realistic. It's essentially calculating the result of every individual ray of light in a scene.

Given the explosion of computing power in the 22 years since Juggler was released, you might think all 3D graphics would be rendered via ray tracing by now. To a certain extent, that is true; many computer animated films are rendered through ray tracing techniques, such as Pixar's PhotoRealistic RenderMan.

Pixar has done some incredible work on 3D rendering, but it's not exactly what I'd call real time. Courtesy of Chris Anderson, here's a little Pixar quiz:

On 1995 computer hardware, the average frame of Toy Story took two hours to render. A decade later on 2005 hardware, how long did it take the average frame of Cars to render?

1. 30 minutes
2. 1 hour
3. 2 hours
4. 15 hours

Answer: D. The average Cars frame took 15 hours, despite a 300x overall increase in compute power. The artists have an essentially infinite appetite for detail and realism, and Pixar's resources have grown over the decade so it can afford to allocate more computers to the task, allowing each to run longer to achieve the artist's and animator's ambitions for the scenes.

Surprisingly, Cars was the first Pixar movie to be rendered with the slower, more accurate ray tracing techniques; previous movies used mostly scanline rendering. There's an excellent presentation from Pixar's Per Christensen (ppt) describing the differences in some detail, if you're curious. And if you want to experiment with ray tracing yourself, there's always POV-Ray, which produces some impressive results as well.

Movies, of course, don't have to be rendered in real time. But even with the freedom to take as much time as necessary per frame, ray tracing is often too expensive. Imagine the difficulty, then, of shoehorning ray tracing into real time 3D engines. Modern GPUs are impressive pieces of silicon, but they cheat mightily when it comes to rendering a 3D scene. They have to, otherwise they'd never be able to generate the 30 or 60 frames per second necessary to provide the illusion of an interactive world.

Of course, this doesn't stop people from trying. The most impressive real time ray tracing attempt I've seen is from Daniel Pohl and his OpenRT real-time ray tracing project. Daniel has done some fascinating proof of concept work with Quake 3 and Quake 4.

But performance remains a problem, even on the latest and greatest hardware:

So why don't we see raytracing right now in games? The problem is still performance. Rendering all these effects through the CPU is not as fast as using special purpose hardware like current graphic cards for the rasterization algorithm. But the evolution of CPUs is fast. Q3RT speed has increased by more than a factor of 4 since 2004. Intel's new quad core is out and the efficiency using the same CPU clock rate is about 30% higher.

One big advantage of raytracing is that it is perfect for parallelization. As explained in the introduction, a ray is shot through the 3D scene for every pixel. If you render an image with 640x480 pixels, you have about 300,000 rays. Each of them can be calculated independently of the others. This means the image could be split up into four parts and every core of a quad-core CPU can calculate the color values of the image without waiting on any of the other cores for intermediate results. Therefore the scaling of performance with the number of cores in Quake 4: Ray traced with OpenRT on Intel's quad-core CPU is great. The following benchmarks were taken at a resolution of 256x256 pixels on the Quake 4 map "Over the Edge (Q4DM7)".

4 cores	16.9 fps	3.84x scaling
2 cores	8.6 fps	1.96x scaling
1 core	4.4 fps	1x scaling

It's difficult to find much software that scales beyond two cores. So the emergence of a many-core future is a boon to ray tracing algorithms, which scale nearly perfectly.

The dimensions of the original juggler are 320 x 200. That's roughly the same number of pixels as the 256 x 256 Quake 4 benchmark presented above. It's possible we could render the ray traced Amiga juggler today in real time at close to 30 fps-- but barely. Despite many hyperbolic marketing claims of "rendering Toy Story in real time", real time ray tracing remains something of a holy grail in practice-- considering Toy Story was rendered at 1536 x 922. Who knows what we'll be able to render in the next 20 years?