Category: Technology

Dreamhost Out, TextDrive In

You might have noticed that this site is much faster than it used to be. The reason? I moved it from DreamHost to TextDrive.

TextDrive costs more, its “control panel” is not as good as DreamHost’s, and its bandwidth/storage limits are lower. But my site is far faster, hasn’t had any downtime or email downtime since the switch (during which DreamHost had an email outage), and TextDrive support responds much sooner.

I have a few TextDrive nitpicks though: there is no built in web-stats system (I’ll need to install one), and they apparently don’t have a backup system working at the moment (!). I’ve set up a nightly rsync to a machine here for backup purposes, but I sure hope they don’t intend this as a long term situation.

Update: Jason at Joyent/Textdrive noticed this post, and added a comment that the backup problem is long fixed.

Update: A complaint without data risks sounding like a whine. So I’ll add some data. Today I noticed that sites I still have on DreamHost are slow. Why? let’s look:

$ date
Fri Sep 8 15:56:14 PDT 2006
$ uptime
15:56:18 up 5:31, 3 users, load average: 103.41, 95.54, 181.86

Update: Some months later, TextDrive has turned out to have approximately at much, or more, downtime as DreamHost. It’s still fast when it’s up, and the TextDrive guys are helpful, friendly, and responsive. But the shared hosting they offer has frequent downtime.

Aiming for Mainstream

Over on defmacro today, a new article appeared: defmacro – Why Exotic Languages Are Not Mainstream in which the author laments that while there appear to be various choices to use Haskell on Windows, it turns out that all of them are, in some way, not ready for prime time… or even for effective hobbiest use.

I’ve noticed this myself, in my last few forays in to esoteric languages: the illusion of plenty of choices, runs in the the reality of no good choices.  This is not a universal problem; I’ve had great results with Ruby, Python, and Lua, all of which are to some extent esoteric.  The thing that those languages have in common is that there is at least one (and generally, only one) robust, production grade implementation with a community actively supporting it.

If you want to see your favorite language gain acceptance, spend your time creating / maintaining / vigorously supporting a production-ready implementation.

Long Rails Stack Trace

I was looking at the RailsConf schedule, and saw the Rails web app that runs it fail with this longish stack trace. A few Rubyists sitting nearby commented that the application was not well configured, that usually Rails apps are configured in deployment to store such traces to a log, rather than spit them at the user. Their mistake is my gain though, as it provided fodder for this post.

This stack trace is considerably shorter than a typical Java web app stack trace. But it is not so good either, and it is an ominous sign that excessive complexity is making its way in to Rails.

How To Do Deployment (Dave Thomas RailsConf Keynote)

I just attended Dave Thomas’s keynote at RailsConf. He had many interesting things to say, most notably that 60%+ of his Java-centric conference-circuit friends, mostly people who have written books on Java, speak regularly on Java, and have lots of experience as Java “architects”, are now making a living with Ruby / Rails.

Dave talked about 3 key areas where Rails should improve. The one I want to focus on is deployment. Rails has Capistrano, a slick tools for deployment automation. Capistrano is great, but it misses the boat in one key way: it is push-based. It assumes a world where the developer sets up, controls, and performs deployment to production servers. That is of course the case at the start of a small operation, but it doesn’t scale; in large organization, or even in small growing ones, sooner or later there is staff dedicated to production deployment and monitoring, separate from development.

One way, to me right way, to handle deployment is push / pull:

For the “push”, a developer uploads a new version to a storage site somewhere. It travels in the form of an archive file (ZIP, tgz, whatever) which contains all of the needed artifacts, as well as metadata about the required libraries, pre- and post-install steps, etc. for the new version. It has a unique name; it lands at a URL. Normal, off the shelf technology (FTP, web servers, etc.) can be used to serve and secure this storage, implement policies about who can upload new versions, etc. This upload happens with some simple one-line command (or as part of an auto-build); it does not actually put a new version in production, but only makes it available for pulling.

Then, on a production machine, someone with software installation rights on that machine (administrated by the normal tools – not by any special feature of the deployment mechanism) runs a command (something like “deploy staging http://ourserver/project1/project1-build-3453.tgz”) which downloads the new build, runs various sanity checks, deploys it to a staging area, and makes it available to try out. Once the staging is verified, a similar command brings it in to live production. These builds refer as needed to configuration data on the deployment machines (such as production DB access credentials); the build archives are generic, not specific to any particular production machine.

The main idea behind this is that each person has the rights they need for the work they need to do, and these rights don’t need any special help or support from the deployment mechanism. Developers don’t need any special rights on deployment machines, nor to deployers need any special rights on development machine

I wrote this in the context of a Rails / Ruby talk, but it’s at least as relevant in Java and Delphi world; in fact at Oasis Digital we need something like this on a Java project and a Delphi project right now.

At RailsConf, Sitting Around Ignoring Each Other

I’m at RailsConf. In a flagrant attempt to be one of the cool kids, I’ve set up a Flickr account to share my RailsConf Photos.

Of the few dozen conference I’ve attented, this one has the highest incidence so far of people sitting around, in large groups, working alone on their notebook computers; some of the groups are having conversations, but most of the attendees (including me, as I type this) are staring intently at their own PCs. It makes me wonder why we are all here – are we all so accustomed to interacting online that we don’t bother to interact offline, even when sitting in the same room (and at considerable expense?)

Take control of Delphi forms in your multimonitor application

The authors of the the VCL helpfully added multi monitor “support” a few versions back. Somewhat less helpfully, this support is very limited – it has no way to say “create form X on monitor 3”, which is a very useful thing to do in some kinds of applications – those intended to run on a multimon system in a specific configuration.

You can readily move forms around (with .Left, .Top, etc.) on to specific monitors after a Form is open, but not while it is opening (in OnShow or OnCreate), because a fine method TCustomForm.SetWindowToMonitor will jump in and undo your work.

Not surprisingly, most of the obvious methods to override to fix this, are not virtual. (An aside – I think the bias toward final methods in Delphi, C#, and some other languages, is a poor idea, and I think the guideline of “design for overriding, or prevent it” is even worse.) With some looking, I found a workaround, shown here somewhat mangled by WordPress:

private

FSetBoundsEnabled: boolean;

public

procedure SetBounds(ALeft, ATop, AWidth, AHeight: Integer); override;

…..

procedure TSomeForm.SetBounds(ALeft, ATop, AWidth, AHeight: Integer);

begin if FSetBoundsEnabled then inherited;

end;

FSetBoundsEnabled will be False by default. Sometime after your form is loaded (use a Timer or a windows message to signal this), set FSetBoundsEnabled := True then set your .Left and .Top to put your form whereever it needs to be.