Changing Infrastructure - and "Mea maxima culpa *thwack*"

(which I remember from a Monty Python sketch but can't find attribution. Oh well; please feel free to comment and enlighten me.)

About a week ago, I switched my domain hosting for my Web/mail domain, seven-sigma.com, from Simplehost Limited of New Zealand to WebFaction, based in the UK. Now, Simplehost are a good bunch of guys; their customer service is very responsive and you get knowledgeable, thoughtful answers to questions. On most things, they're very willing to work with people to help them resolve issues. If you're looking for a host in this general slice of the planet, put them on your list of providers to have a good look at.

The deal-breaker for me, though, after two years or so with them, was that I need to be able to develop and demonstrate Web sites using the latest and greatest variety of tools, in particular PHP 5.3.x, which introduces important new features (in addition to fixing numerous bugs).

WebFaction, on the other hand, offer PHP 5.3 support (as well as numerous other tools, such as Ruby on Rails, have good pricing on their shared-hosting packages (as does Simplehost, honestly), and fantastic self-help and support options - video tutorials, Twitter feeds, and so on. Also, doing the obligatory Googling for dissatisfied-customer reactions mostly brings up hits like this one, talking about how (except for a couple of brief periods), the only hits were from reviews pointing out how few hits there were. Chatting on IM and IRC with a few customers also helped.

So, a process that I'd been poking at for a couple of months, with three weeks of serious effort, is done with, hopefully for several years to come.

However, there was a silly-me postscript to all of this: For several days after I made the switch, I just wasn't able to get email working. I went onto the WebFaction email-support forums, flipped through a few messages that described solutions to problems other users had had, tried them, and no luck. Then, tonight, I came across the answer that had been staring me plain in the face from the very first message telling me that my account had been set up.

You folks who have your own domains can probably imagine what went wrong; suffice it to say that the difference between what I was reading and what I was thinking was sufficient that over 1,300 email messages have downloaded in less time than it took me to write this post. So if you've been emailing me and wondering why I haven't answered, I apologize. It's unlikely to happen again — hopefully for several years.

And to the Simplehost support guys, thanks very much for your help. This was not in any way at all Simplehost's fault.

So why would I write something like this, showing a fairly major screwup? Because... I'd rather deal with people who admit their faults and publicly commit to do better, than with people who are infallible legends in their own mind. This industry has far too many of the latter sort. I'm hoping that enough other people feel the way I do that I can continue to do great work for my clients.

Thanks for reading.

EDIT:Years on, never mind how many, I discovered that I'd mistyped "WebFaction" when I meant "Simplehost" three paragraphs earlier. Heartfelt apologies to both. Mea maxima culpa *thwack!*

Tools, Continued

UPDATED 2 November 2010; see last paragraph.

---

This blog, fairly obviously, is published on blogger.com, which is now owned by Google. Blogger.com is geared primarily towards people who want to write but don't want to have to worry about the nitty-gritty technical details involved (such as HTML, CSS and so on). Sign up, click the 'New Post' button, and off you go...almost easier than falling out of your chair.

For the Web wizards among you, you can get into the guts of how your blog and posts are laid out and formatted; there are several in-the-tin and numerous third-party templates that can be used to style your blog any way you like it, and those can then be hand-tweaked by you to get things just so.

As with any click-and-go interface, the Blogger new-post window (what I'm typing in right now) has a "Preview" button (or actually, link); click on it and you'll see a more-or-less-reasonable facsimile of what your breathless prose will look like to the next visitor who stumbles across your blog. I did say "more-or-less-reasonable"...

One thing the preview area doesn't do — sensibly in hindsight — is to apply your template's formatting to the post being previewed. So that, for instance, if your template specifies that you want 9-point Gentium Book Basic, Times New Roman or Times (in that order) for your body, you won't see it that way in the preview.

What you also won't see — and this is what tripped me up for the longest time — is other styling for the post body, particularly justification. You may notice that all my posts are displayed with justified left and right margins; the default, and most commonly used setting, is for a justified left and ragged right margin, which I find unattractive. I've tweaked the template I use several times over the years to try and get the effect I was looking for. Each time, the post-preview showed no changes to the text formatting, and so I undid the change without viewing the entire blog normally. I have been instead hand-wrapping the content of an entire post in a <div>...</div> element pair whose only reason for existence was to set text-align: justify;.

This isn't the first time I've blogged about my learning-experiences-that-shouldn't-have-been, and just to be perfectly clear about this, I'm not trying to dis Blogger.com about this. The preview-while-composing feature is merely to let you see the content of the post you're working on without all the editing framework around it. It won't, and arguably shouldn't try to render that content in its final form. You do, after all, have the ability to go back and edit posts you've already published.

This is, at its heart, a cautionary tale for those of us tasked with making the Web easier to use for a wide variety of users. Be careful especially with interface design. Recognise that, barring explicit cues to the contrary, people's assumptions about How Things Work on your site may have only a nodding acquaintance with your own — but if you have some appropriate description in the right place, users are often happy to adjust. But there has to be a balance, or your 'power users' will feel like they're being stifled. How you achieve that balance is, of course, up to you to find out. Good luck.

UPDATE: Blogger have, since I wrote the original post, changed their preview feature (at least for "Blogger in Draft," their next-gen interface, which I use and recommend.) When you click the Preview button now, Blogger opens a new tab (or window, if you're old-school enough not to use tabs) with the preview of your draft post. This preview is exactly as a visitor to the published post would see it, with the exception of a great big Preview stripe in the upper-left corner. A wonderful improvement; thanks, guys!

Mac OS X is BSD Unix. Except when it's Different.

One of the things that a BSD Unix admin learns to rely on is the "ports" collection, a cornucopia of packages that can be installed and managed by the particular BSD system's built-in package manager: pkgsrc for NetBSD, pkg_add for FreeBSD, and so on. In nearly all BSD systems, the port/package manager is part of the basic system (akin to APT under Debian Linux).

Mac OS X is BSD Unix "under the hood," specifically Darwin and, indirectly, FreeBSD.

This provides the Mac user who has significant BSD experience with a nice, comfy security blanket. This blanket has a few stray threads, however. One of these is the package-management system and ports.

Software is customarily installed on Mac OS X systems from disk images, or .dmg files. When opened, these files are mounted into the OS X filesystem and appear as volumes, equivalent to "real" disks. The window that the Finder opens for that volume customarily contains an icon for the application to be installed and a shortcut to the Applications folder. Installation usually consists of merely dragging the application icon onto the shortcut (or into any other desired folder). Under the hood, things are slightly more complex, but two points should be borne in mind.

First, there is no true Grand Unified Software Manager in Mac OS that is comparable to APT under Debian Linux, or even the "Add or Remove Programs" item in Microsoft Windows' Control Panel. Uninstalling a program ordinarily consists of dragging the program icon to the Trash or running a program-specific uninstaller (usually found on the installation disk image).

Second, while there is a "ports" implementation for Mac OS X (MacPorts), it isn't a truly native part of the operating system. More seriously, the versions of software ports which are maintained in its ports list are not always the most recent version available from their respective maintainer. Installing an application via MacPorts, installing a newer version through the customary method, and attempting to use MacPorts to maintain the conflated software can quite easily introduce confusing disparities into the system, with potentially destabilizing effect.

Go back and read that last paragraph again, especially the final sentence. Mac OS X, meet BSD Unix. Touch gloves, return to your corners, and wait for the bell.

Most users will never run into any problems, simply because most Mac users make little or no use of MacPorts (or any other command-line-oriented system management tool). MacPorts users are (almost by definition) likely to be experienced Unix admins who pine for the centralized simplicity of their workhorse software-management system. Informal research suggests that many, if not most, MacPorts users are active developers of Unix and/or Mac software. In other words, we're all expected to be grown-ups capable of managing our own systems, trading away the soft, easy-to-use graphical installation for a wider variety of nuts-and-bolts-level packages.

So why is any of this a problem for me? Why am I consuming your precious time (and mine) blathering on about details which most interested people already know, and most who don't, probably aren't? As a bit of a public mea culpa and a warning to others to pay attention when mixing installation models.

I had previously installed version 8.2 of the PostgreSQL database server on my Mac via MacPorts. Returning to it later, I realized that the installation had not completely succeeded: the server was not automatically starting when I booted the system, and the Postres tools were not in my PATH. After a bit of Googling, I came across a few links recommending the PostgreSQL 8.3.6 disk images on the KyngChaos Wiki. The server failed to start as expected.

Remembering that I had previously installed 8.2 the "ports" way, I first uninstalled the newly-installed and -broken 8.3.6. I then ran port uninstall postgresql82 && port clean postgresql82 in an apparently successful attempt to clean up the preexisting mess, after which the KyngChaos disk images installed correctly and (thus far) work properly.

This once again points out the usefulness of keeping a personal system-management Wiki as a catchall for information like this — both to help diagnose future problems, and (especially) to avoid them altogether. These can be dirt simple; I use Dokuwiki, and have for over a year now. Forewarned (especially by yourself) is forearmed, after all.

Just thought I'd get this off my chest.