Coding Horror

Robert J. Lang isn't just a physicist and a software developer-- he's also one of the world's foremost paper-folding artists:

The laser cutter was growling away, scoring one of Lang's Hanji sheets. He twiddled with his computer. On the screen was a lacy geometric pattern. Lang had designed it with software he started writing in 1990 called TreeMaker, which is well known in origami circles; it was the first software that would translate "tree" forms -- that is, anything that sort of resembles a stick figure, such as people or bugs -- into crease patterns. Another program he wrote, ReferenceFinder, converts the patterns into step-by-step folding instructions. This secured his position as the most technologically ambitious of the origami masters. In 2004, he was an artist-in-residence at M.I.T., and gave a now famous lecture about origami and its relationship to mathematical notions, like circle packing and tree theory.

On Mr. Lang's website, you'll find the amazing crease patterns produced by his software.

To the non-origami person, the sequence that transforms a sheet of paper into a beautiful folded object can seem miraculous. Even to the origami aficionado, however, the idea that a single drawing of the creases conveys the full folding sequence can seem equally miraculous. But in fact, a crease pattern can sometimes be more illuminating than a detailed folding sequence, conveying not just "how to fold," but also how the figure was originally designed. And thus, it can actually give the folder insight into the thought processes of the origami composer in a way that a step-by-step folding sequence cannot.

The crease patterns are almost as beautiful as the origami art itself:

It's fascinating stuff. And the science of folding isn't just art; it has numerous real-world uses:

For centuries, origami patterns had at most thirty steps; now they could have hundreds. And as origami became more complex it also became more practical. Scientists began applying these folding techniques to anything -- medical, electrical, optical, or nanotechnical devices, and even to strands of DNA -- that had a fixed size and shape but needed to be packed tightly and in an orderly way.

Lang provides three practical implementations of Origami on his site: the design of laser optics, car airbags, and telescopes.

(via Jason Kottke)

Unless you've been living under a rock for the last few years, you've probably heard about the game Katamari Damacy. The gameplay consists of little more than rolling stuff up into an ever-increasing ball of stuff. That's literally all you do. You start by rolling up small things like matchsticks, thimbles, pushpins, and so on. As the ball gets larger, you roll up ever larger and larger items. Eventually, your Katamari ball gets so large you end up rolling together cities, mountains, clouds-- eventually entire planets. It's unbelievably fun, and completely mesmerizing.

After I played for a while, I realized that Katamari Damacy is a game about the scale of life, reminiscent of the classic Eames powers of ten movie.

As Bob Koss points out, code has a natural tendency to become a giant Katamari ball of "stuff", too:

I travel a lot and I get to visit a lot of different companies. No matter which industry a company is in or which programming language a team is using, there is one commonality in all of the code that I see – classes are just too damn big and methods are just too damn long.

We programmers must take matters into our own hands and become masters of our domains. Unless we take action, things are just going to get bigger and bigger until we have a real mess on our hands.

Bob's article is about managing the scale of your code:

This notion of breaking a class into smaller and smaller pieces is exactly opposite to what I learned when I first started studying OO. Way back when I worried about bad-hair days, people believed that a class should encapsulate everything that concerned it. A Customer class would know the business rules of being a Customer as well as how to retrieve itself from the database and display it's data. That's a fine idea, provided the database schema never changes, the display never changes, or the business rules never change. If any one of those responsibilities change, we are at a high risk of breaking other things that are coupled to it.

So many aspects of software development can be summarized as small is beautiful:

• The odds of failure for a software project are directly proportional to the size of the project. Slicing a large project into several smaller subprojects is the single most direct way to increase your project's chances of success.
• The relationship between lines of code and bugs is completely linear. Fewer code means fewer bugs.
• Smaller code avoids TL; DR (Too Long; Didn't Read) syndrome. The less code there is to read, the higher the odds are that someone will actually read it.
• If you keep your dependencies to a minimum, your code will be simpler and easier to understand.

It's up to us to resist the natural tendency of any project to snowball into a giant rolling Katamari ball of code. Code smaller!

It's the classic achilles heel of web applications-- without an internet connection, they're useless. It's why both Firefox and Internet Explorer still have Work Offline under the File menu, hanging there like a vestigial tail.

But do you know anyone that actually uses work offline? Is there anything more futile than a web browser without a connection to the internet?

By now, more than 50 percent of Americans have broadband internet. Add the ubiquity of WiFi access points, and the increasing availability of high-speed 3G cellular networks, and it's difficult to find any place that you can't be online, if you really want to be.

And people, not just geeks, really want to be online. We've long since reached the critical mass that Metcalfe's Law predicts-- as greater numbers of people gain access to the internet, the more inexorable the draw is on everyone else to get connected. Asking someone if they have an email address these days feels almost as ridiculous as asking them whether they have a telephone. Of course they do. How could they live without one?

Which leads me to wonder: does offline mode still matter in an increasingly online world? I can definitely see value in building an occasionally connected app. The network isn't always reliable. Or fast. But the idea that an application has to be completely functional with no connection to the internet grows more and more absurd with every passing year.

I think Dare Obasanjo put it best:

For a lot of computer users, their computer is an overpriced paperweight if it doesn't have an Internet connection. They can't read the news, can't talk to their friends via IM, can't download music to their iPods, can't people watch on Facebook or MySpace, can't share the pictures they just took with their digital cameras, can't catch up on the goings on at work via email, they can't look up driving directions, can't check the weather report, can't do research for any reports they have to write, and the list goes on.

I already feel like my home computers are nearly useless without a connection to the internet. And internet connectivity is an absolute requirement when I'm on-site with customers; without it, I can't research any problems I might encounter. Lack of internet connectivity is a major impediment today. But in another five or ten years, it'll be paralyzing.

If you think you need a pure offline mode in your application, consider carefully. Do you really want to bet against the internet?

My home theater PC is set to automatically enter a low-power sleep mode after 25 minutes of inactivity. This works well with Vista's Media Center, which wakes the machine up when it's scheduled to record. This way I can avoid the additional electricity cost of a computer turned on around the clock. My HTPC doesn't use that much power, but even at a miserly 60 watts idle, that still works out to about $80 per year here.

This arrangement works out fine most of the time. I don't mind waking the machine manually when I want to watch television-- after all, I'm in the same room and I'm walking towards the couch anyway. It's on the way. But a sleeping PC can be incredibly annoying when I'm sitting at my desk and I need to access that machine remotely. I use my HTPC as my digital media file server, so I often need to transfer files back and forth. But now I can't, because the machine is often asleep. Zzzzz. I desperately need it to WAKE UP. This always reminds me of ToeJam & Earl on the Sega Genesis. If you left the controller alone for a minute, your character would fall alseep.

You had to frantically bash all the controller buttons to wake your character up, which he did only reluctantly. Unfortunately, mashing all the buttons on my keyboard didn't seem to work. What I need is a way to remotely wake a sleeping computer.

Fortunately, one already exists: it's called Wake-on-LAN. Most modern motherboards have integrated ethernet ports that support Wake-on-LAN. Here's how to tell if yours does: put your computer to sleep, then take a look at the ethernet port and see if the transmit and receive LEDs are still blinking. If they are, it's likely you can use Wake-on-LAN. That was true in my case, so I figured it should work.

I downloaded a few Wake-on-LAN tools, but the one I liked most was Vitaly Evseenko's small, free command-line utility, mc-wol.exe. These utilities send a specially crafted "magic ethernet packet" to the target PC which initiates the wake-up sequence. Note that you have to identify the target PC by MAC address, not IP address. I checked my router's DHCP tables, which included the following MAC entry for my HTPC:

00:01:80:5c:d3:24

Armed with that information, I gave it a shot. But nothing happened. Zzzzz. Darn! I checked the PC's BIOS settings, but there was nothing relevant. And then I remembered the properties page for the network adapter in Device Manager:

Bingo. It's in two different places under Device Manager, Network Adapters, Properties:

• Advanced tab, Wake from Shutdown property, Value = On
• Power Management tab, Allow this device to wake the computer, check

I'm not sure which one is the "right" one to set. I set both just to be sure. Once did, I was able to wake up the machine remotely exactly as desired:

C:UsersJeffDesktoptest>mc-wol 00:01:80:5c:d3:24
WakeOnLAN v1.0 Copyright (c)2001, MATCODE Software.
Web: http://www.matcode.com
Author: Vitaly Evseenko, ve@matcode.com
Sending "Magic Packet" to 00:01:80:5c:d3:24 - Success!
C:UsersJeffDesktoptest>ping mce
Pinging mce [192.168.0.110] with 32 bytes of data:
Reply from 192.168.0.110: bytes=32 time<1ms TTL=128
Reply from 192.168.0.110: bytes=32 time<1ms TTL=128
Reply from 192.168.0.110: bytes=32 time<1ms TTL=128
Reply from 192.168.0.110: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.0.110:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

You know, I think there's an inspiring moral to this story: why get out of your chair and walk 20 feet when you can spend two hours figuring out how to do it without moving at all? It's a symbolic victory for lazy people everywhere.

It's common knowledge that Mac users prefer Safari to Firefox. It is the browser bundled with the OS – and we know how that generally works out. But it's not just a monopoly play; there are legitimate reasons for Mac users to choose Safari:

Mac users favor [Safari] for its rendering speed, clean interface and fast launch times.

Safari is, of course, a completely competent browser that stands on its technical merits, very much unlike IE6. But if you ask Mac users why they chose Safari, and if you keep pressing them, you'll probably find the deciding factor was that Safari feels like a native Mac app.

The next version of Firefox will use some native UI elements in OS X. But it's still not a native Cocoa app. The lack of a completely native UI on OS X may seem like a minor implementation detail, but it's actually a showstopper for a lot of people, like this commenter:

"Native cocoa widgets" refers to the use of the natively rendered components such as scroll bars and submit buttons. These are the same buttons and scroll bars used in nearly all Cocoa apps for OSX (basically every program you've ever used). The default theme for OSX FF2 uses these really ugly widgets that are really blocky and Netscape 4-y looking.

As vain as it may sound, those ugly widgets are actually one of the major reasons I use Safari instead of FF on OSX.

When two applications with rough feature parity compete, the application with the native UI will win. Every time. If you truly want to win the hearts and minds of your users, you go to the metal and take full advantage of the native UI.

Java has struggled with this problem for years, producing results spanning the continuum between "terrible" and "awful", depending on who you ask. Most Java developers have given up completely on GUI applications:

Me, I defected long ago. I'm another of those Apple Java engineers who dropped out. I spent five years as a raving Java fanboy, but I gave up after optimizing AWT, implementing drag and drop, and trying to make 1,200 pages of crappy APIs do the right thing on the Mac. Then I took a one-week Cocoa training course, and wrote the first prototype of iChat.

Desktop Java never worked because Sun tried to build their own OS on top of the real OS, duplicating every API and feature. This led to terrible bloat, making every app as heavyweight to launch as Photoshop. Worse, the GUI portions of the Java platform are awful, because Sun is a server company with no core competency at GUIs. The APIs are too clumsy to code to, and compared to any decent Mac app, the results look like a Soviet tractor built on a Monday.

Ultimately, the best any Java app can do is pretend to be a native app. To fake it. And more often than not, it can't even manage to do that:

This project should be a cautionary tale for people who think programmers should be interface designers. Apple and Microsoft at least recognize that these are different skill sets, and that looks and feels should be created by a team of programmers, graphic designers, and interaction designers. Sadly the Linux and Java communities haven't really figured this out yet, and are still trying to have programmers do it all, with predictable results. The bottom line is that we don't really need different look-and-feels in Java. The best Java can or should do is faithfully mimic the native user interface. Unless your name is Bruce Tognazzini or Kai Krause, you almost certainly won't do better than that; and you'll be very, very lucky if you don't do worse. Pluggable look-and-feels are necessary in Swing only because Swing apps have to run on multiple platforms. They should be changed only from operating system to operating system, not application to application. The goal of a Java application is to fit in with other native applications, not to stand out.

GAIM has a cross-platform UI based on GTK, which produces predictably bland, least-common-denominator results:

Most of all, I find myself empathizing with Mac Safari users because I haven't been able to switch away from IE7 on Vista. Firefox feels so dowdy in Vista. It just doesn't fit in. It scrolls very slowly, the keyboard stops working at random, and the overall GUI is jarringly out of place, including the legacy main menu. There's no doubt whatsoever that Firefox is a vastly superior browser for web development, with a vibrant developer community. Firefox absolutely should be a part of every developer's core toolkit.

But when it comes to day-to-day browsing, I'll always pick native speed and native look and feel over the ability to install a dozen user extensions, or the ability to run on umpteen different platforms. Every single time.

If that makes me shallow, then I'm in good company. Non-native UI sucks.