|Oh well, at least it's
Everything here is
my personal opinion.
I do not speak
for my employer.
On urban planning
Stationnement de Montreal has off-street parking sites available for a monthly fee. "52 lots!" they proclaim. "A network of 4000 parking spaces!" Those numbers surprised me a bit, given Montreal's 1.8 million residents.
It sounds like a Microsoft interview question. If there are 1.8 million people in Montreal and 4000 city-provided parking spaces, how long will the waiting list be? (Of course, you'd have to estimate the number of cars per person, number of private lots, etc.)
Answer: about four years.
Suggestion: park elsewhere.
Commentary: At least they're not building lots of ugly parking lots just
because of massive demand. This is just one more part of the apparent
Montreal policy of punishing people with cars.
-- Colin Powell, via Pmarca
True Love, Revisited
Last year at NITI I did a presentation I called True Love. It was about Lotus Domino. Follow the link if you don't believe me.
So how weird is it when, more than a year later, a review of Domino for Linux (which mentions Nitix) talks about true love in its first paragraph?
I knew it wasn't my imagination.
I'm not lazy, I'm forward-thinking!
Apparently allowing blog comments is passé, according to people in the know.
I don't allow them on my site, but I thought it was just because I was too lazy to screen them, fight spammers, etc. As it turns out, allowing comments would restrict my freedom of speech! Holy cow! Who knew?
(As usual, people who want to email me or link to me about anything they
find here are more than welcome to do so.)
One of these sponsors is not like the others
Forget Web 2.0, it's Banking
The horrors of Setup.exe
Recently Jeff Atwood wrote about Mac software installation, complaining that it's not as easy as Windows setup.exe. There followed a barrage of comments, but I think most of them miss the point.
The point is that "installing" software is a very suspicious exercise anyway. What exactly is it doing to my computer that takes half an hour or more to install Microsoft SQL, for example? Why can't it just copy some files around and then run the server daemon?
Installers are arbitrarily slow
Since the ancient DOS days, this question has always been very mysterious to me. Once upon a time long long ago, I was installing a game (Wing Commander II, I think) from floppies on my 386, and wondering why it took absurdly long to do compared to, say, good old diskcopy.exe. There was no good reason; a few months later, I built an installer for an app I wrote, and it could copy itself from a floppy in a fraction of the time. And I didn't do anything special to achieve it; I just used plain fread() and fwrite().
To this day, programs like InstallShield continue to astonish me. Have you ever watched the installation log messages as they scroll by? They sometimes say things like "Creating registry key HKEY_LOCAL_blah\blah\blah\blah" - one per registry key. That's fine, but why do I have time to read them as they go by? On a dual-core 2 GHz processor, creating registry keys happens in a timeframe humans can see? How? I'm sure it's the same reason as Wing Commander II was slow, so many years ago.
InstallShield, by the way, is the worst offender I've ever seen. For some reason, it's also the most common installer platform. If you're writing an installer, take my advice: just use NSIS instead. It's awesome. We used it to build the ExchangeIt Plugin installer for Outlook. It writes registry keys during the installation process too. Know how long it takes? Me neither - it's immeasurably fast.
Actually, the entire ExchangeIt install process takes as long as it takes you to press Enter-Enter-Enter-Enter. I can't quite figure out what I'm doing right.
"Install" is the wrong concept
But there's another, more fundamental problem with all this: installers are doing too much stuff. "Install" is completely the wrong word for the operation we want to be doing. I don't "install" a toaster or a TV - I plug it in and push the button and it works. Anybody can do it. But you "install" a kitchen sink - and it's a scary operation, best done only by experts, because it involves plumbing and might spew water everywhere and ruin your whole house if you do just one thing wrong.
There's a reason people are scared to install Windows software - because it is like plumbing, and you might screw up and ruin your whole computer if you do it wrong. That's scary!
On Windows, installing software involves copying DLLs around (sometimes into the Windows directory where it overwrites ones from other apps), changing registry keys (sometimes ones that conflict with other apps), and creating Start Menu shortcuts. The installation process takes forever and has lots of unfriendly status messages just to underscore the fact that you should thank goodness for setup.exe, because you sure don't want to have to do all that stuff by hand.
On a Mac, most of those problems are solved. An application is actually a "package" folder containing all the app's critical files; most applications don't need to put any files outside that package. The "Start Menu" is the same thing as the Applications folder; unlike Windows, there's no need to create "shortcuts" to make the program visible. No user should ever have trouble figuring out the new application is in the Start Menu, because they're the person who put it there.
And you know what's cool? If they don't put it there - if they don't drag it anywhere at all - clicking on the application will work just fine. They never actually need to install it. And furthermore, they can drag it anywhere they want - to another disk, to their desktop - and it'll work fine there too. It's right where they left it.
Okay, how does uninstalling work? Well, you go to the applications folder and delete it, just like any other file. In Windows, users try that too: deleting the icon from the Start Menu to make the application go away and free up some disk space. In fact, they must have tried it a few too many times, because when you try it in Windows XP, a dialog pops up warning you that it won't work. Yeah, too bad about that.
The whole Mac thing with the .dmg files and virtual disks and needing to "eject the application" afterwards is mysterious to me, though. The design of application packages is extremely clever - but the front end to it is clunky. Why does the package need to be in a virtual disk at all? I'm not sure. At least it's just a UI issue and can be fixed in a future version.
(Incidentally, in .NET Microsoft is trying to do roughly the same thing as Mac packages: they call it Xcopy Deployment.)
Next time, some advice on how to write a better setup.exe. Because it doesn't really matter if setup.exe is a good idea or not; we're stuck with it.
6 Steps to Writing a Better Windows Setup.exe
Yesterday's post on software installers mostly explained why the Windows software installation process is gross. But when I've written installers, even for Windows, they're not too gross. Here's some advice you can actually use.
If you follow all the above steps carefully, you should be able to get your installer down to its bare minimum: copy your .exe file to Program Files somewhere, create a Start Menu entry, and register the uninstaller. The Uninstaller does exactly the opposite, of course.
Exactly one test case, and it's trivial to verify if you got it right. And you know your app works identically with the installer and without, because the installer doesn't do anything.
Even if you assign a total newbie developer to that, he shouldn't be able to
screw it up.
Linus Torvalds discusses version control
It's not very often that you get to see Linus Torvalds discussing anything at all for a full hour. Follow the link for a discussion about version control, git, and why CVS sucks.
Surprisingly to me, he's a bit of an unexciting presenter. The content is interesting, though.