A few years ago, we had some issues with hosting the Cincom Smalltalk Non-Commercial downloads - the server they were on didn't have sufficient disk space to hold everything, so we got a new one. In order to keep things running, I hacked together a"temporary" application that would keep the downloads flowing.

Well, that temporary application is still running, nearly 4 years later. It was never written to be permanent, and the way data was being stored made duplicate entries pretty much inevitable. Well, today I finally got around to weeding those dupes out - on the live server. If you tried to login or register for the NC in the last little while, you might have gotten an "application maintenance" screen. That's done now, and things are cleaned up.

The lesson? No application is every temporary. Does that mean that you need to do the whole enterprisey design up front and set it to scale to the hilltops? No, but it does mean that you shouldn't have delusions of temporariness, either :)

I was interested in the presentations here - they are from the MS PDC, and one covers dynamic languages on the CLR. However, much to my surprise, when I hit the link I got a dialog popped in Firefox:

How bogus is that? What kind of browser check are they doing over there?

I think the upshot of this Typepad story is that upgrading a service that needs constant uptime is a completely non-trivial thing. Most businesses don't have the sheer volume that Typepad does, which is probably fortunate.

There's been some good work on making deployment easier in the upcoming VW 7.4 release - I'm going to walk through the process using a simple UI application later this morning in a screencast. I have to get the family moving out the door first though :)

Every so often, I make a mistake in the deployment of code from my test server to the production server (the Smalltalk image that runs this and the other blogs here). In those cases, I go back to the methods I updated and look to see what's different. Now, I'd rather not take the server down for this kind of thing, so instead I do something like this and load the patched method into the system:

[self codeThatMightBeWrongHere]
     on: MessageNotUnderstood
     do: [:ex | Transcript show: ex errorString; cr].

Then I do something with the server that will exercise the modified code, and watch the Transcript (scrolling to a file) to see what happens. Once I figure that out, I restore the original code, do more testing on the test server, and deploy the needed fix. All without taking the server down. It's one of the cooler aspects of having a full development system available as your deployed server.

Don Box's post on creating proper build scripts in his environment (MS tools, inside MS) reminded me of something - as much as I have complained about the build process for Smalltalk applications, it's just not a simple problem for anyone. This doesn't mean that we can't do better - it's one of my top priorities as product manager. What it does mean is that it's not a cakewalk for developers anywhere.

It's starting to look like the term "beta" is being bent completely out of shape. Witness what Google has done with it over the last few years - services that are, for all intents and purposes "production" status, are still labeled beta.

Underscoring the trend, Google co-founder Larry Page on Wednesday told investors that the beta, or test, stage for its products would last as long as its engineers expected to make major changes to them--a process that has already taken years, in some cases.

"It's kind of an arbitrary thing," Page said. "We could take beta off all of our products tomorrow, and we wouldn't actually have accomplished anything...If it's on there for five years because we think we're going to make major changes for five years, that's fine. It's really a messaging and branding thing."

This is another instance of a perfectly good word being co-opted out of existence. If the word ever meant anything, it means less than that now.

Chris Petrill makes a good point about some of the more bizarre numbering schemes used by open source projects (Firefox, anyone?)

Please, if you release software to the public and consider it usable and reasonably stable, do not number it some absurd 0.3.1, or whatever. If you release it to the public, it's a 1.0 release to start with. From Charles Miller:

Too many Open Source projects treat Version 1.0 as some kind of Holy Grail that can only be reached when the project is perfect. I find that highly annoying, because it makes it really, really difficult to tell a sketchy alpha from production code that is just still in pre-1.0 because the author wants it to do everything.

Nothing is ever "feature complete." Nothing is ever "bug free." Don't pretend you'll ever finish the project, and certainly not without people actually using it, if that's your goal. If it's not your goal, don't release it.

I've learned a lot about this through doing BottomFeeder. The temptation to muck with the version numbers for reasons that have nothing to do with the code are just amazing...