Totally obscure pro tip: If you own a spyder2express monitor calibration thingy you may have been annoyed that the software only allows you to target 65k as your white point rather than using the native white point of your LCD screen, but felt that this wasn't enough reason to spring for the pro version. Turns out you can still download the old (2.2) software that defaulted to native white point if you go and register for their support site.

Now you can launch either version of the software to select the "option" of which white point you want.

Nifty.

I've become convinced that those flashy blinking ads are designed to drive page hits. How? I just found myself reloading the New York Times web page five times in a row in the hope that I'd get an ad that wouldn't compel me to hold my hand over the screen so I could read the actual content without being distracted.

(And yes, I know there's software to fix that.)

I don't think most ducks migrate, but this mallard has just about finished migrating tapirtype over to the new Joyent shared accelerator "Myrtle".

Just a couple more things to test (this post included) and I'm going to declare it done and switch the DNS over.

Ok, I think I have the caching thing figured out. Seems that Smarty (which handles the dynamic publishing--and caching--for Movable Type) defaults to a one hour cache timeout. What Smarty does is write the time-stamp in a header on the cached file along with an expire time-stamp computed by adding an interval determined by the smarty variable $cache_lifetime which defaults to 3600 seconds (or one hour). When retrieving a page, smarty compares the expire time with the time the cached file was built and retrieves the cached file only when the cache has not yet expired.

Why it does this is another matter. One hour seems either far too long or far too short for the life of a cache. It especially makes no sense in the context of Movable Type which seems to clear the cache whenever there is a change to the database, such as saving an entry--whether or not the entry is published--or making a comment (although, not, for some reason, when comments are deleted). Incidentally, I haven't yet figured out how Movable Type achieves this. I can't seem to find where in the code it flushes the cache or checks the modification date on the database, however I have empirically determined that this is the behavior.

This caching behavior especially makes no sense for me, since this blog changes, at most, daily. Fortunately, the default cache lifetime can be changed by editing the smarty.class.php file (found at mt/php/extlib/smarty/libs/). At the top of the file, which defines the smarty class, a bunch of default values for variables are set, some of which are overridden by Movable Type when it creates an instance of the smarty object and uses it to display dynamic content, notably the $caching variable which defaults to 0 (off) is flipped on later if you have enabled caching enabled via publishing preferences.

Setting $cache_lifetime = -1 results in a cache that never expires until the Movable Type database is changed, the setting that makes sense (to me, anyway) assuming that the only way the content displayed for a given page will change is if a change is made through Movable Type. This does bring up an important caveat however (although one I haven't verified), which is that if you have dynamic content on a page that changes based on input other than the Movable Type database, it may not work, or may take some extra effort to ensure that it works.

As I mentioned previously, I recently switched a good portion of Tapirtype Blog--everything other than the front page index and the entries themselves--to dynamic publishing. I've been collecting my impressions, although I'm generally waiting for the upcoming move on to Solaris at TextDrive, my hosting provider for any final judgments about performance.

I like the idea of it, but I'm still not sure on all the details of the execution. This is partly because Movable Type uses Smarty for it's template system, so in order to understand what's going on, I have to understand both what Movable Type is doing and what Smarty is doing. Note, this isn't a criticism, I think Smarty is perfect for the job, and I'm glad they didn't try to reinvent the wheel, making their own php template compiler. The biggest concern when switching to dynamic publishing is that the efficiency equation shifts. During static publishing, it makes sense to make trade offs that make build time just slightly longer for the sake of convenience, simplicity, or feature-fullness. Using dynamic publishing, however, this could lead to intolerable page load times, so caching becomes very important in order to make only the first load any slower.

Smarty has two levels of caching. First it complies the templates into php files on the first request. In theory this should eliminate any disadvantage of a template based system as compared to Wordpress style php "templates". Second, as pages are requested the output is stored in a cache folder, so the second request for a given page should be able to simply echo that cache file with no computation necessary. Actually there's a third level of caching, though I'm not sure whether it is a Smarty or a Movable Type feature, which is that the blog will instruct the web browser that the page has not changed since the last request, allowing the browser to fetch it from it's own cache.

But the difficulty with caching is that any caching system is only as good as it's ability to tell when it needs to recompute the content. Preferably, the system would be smart enough to understand which pieces of the content have updated and which are still the same, but at the bluntest it must flush the entire cache every time any change is made. And here's where things have been falling down for me. In a given session, I can sit at the blog, load a bunch of pages, and see that after the first load, the loads get much quicker. However, inevitably, the next day, with no changes made the the blog, I'd find the caches recomputing. With no changes published to the blog, I can't see why this would be the case. The only thing I could think of was the fact that several trackback requests had come in and were marked as junk, resulting in no changes to the published blog. It would be quite silly if that was causing the cache to reset, but just to test, I've disabled trackbacks now. As much as I like the idea of trackbacks, they've never really worked out, anyway, and since adding a captcha to anonymous comments, they are my only current source of spam (although none ever get published due to the insistence that the trackback request come from the same IP address to which it points).

Hey, I just noticed that I missed this blog's birthday.

Sad blog. I'll have to send it flowers.

I just discovered something odd... MT used to use SmartyPants to translate typography elements (such as quotes and em dashes) when using Textile 2 text formatting (as well, of course, as when using Markdown).

For a moment I thought it had stopped when I saw –– in one of my old entries instead of the — that they should have been translated into. But it's stranger. Turns out all my static pages, get the Textile right, but don't use SmartyPants (or any other html entities translator). However, my dynamic pages get it right.

Ummm... Hopefully someone will get on that real soon now, so as to not force me to learn about Movable Type text formatters and take matters into my own hands.

Also, MT seems to think I'm in Mountain time in spite of my best efforts to convince it that I'm in Pacific. Or maybe it stopped respecting daylight savings... Interestingly this only applies to the date applied to entries. The "Last auto-save" message tells me the correct time. shrug

Update (typography fixed): I fixed the typography problem by manually turning SmartyPants on in all of my static templates, adding smarty_pants="1" to the tags that write out content that might have typography elements in them (MTEntryTitle, MTEntryBody, and MTEntryMore). This should have the side benefit of ensuring that all entries get the best possible typography translation no matter the text formatter used. Also of note is that SmartyPants is smart enough to not process within html comments or php code blocks so it won't break javascript or php code in entries which is important for my galleries.

Still no idea what the time shifted-by-one-hour time-stamp thing is all about, though.

Subtitled: woot, no spam!

So spam was getting kind of silly. Akismet was not catching, well, anything.

Enter the new MT4 options.

I've upgraded to MT 4.0.

I thought I'd been smart by trying it locally before upgrading online, but it turned out to be a bit more difficult that I thought it would be. To be fair that's mostly because I took the opportunity to make a couple of changes. MT 4 has Textile and Markdown built in, including as dynamic php scripts. I know you could install them that way before, but I didn't want to go to the trouble and that provided a block to using dynamic publishing. So now I've enabled dynamic publishing for most indexes and archives other than the entries themselves. I can't have the entries themselves published dynamically for now because I use php inside entries to publish my photo galleries and that won't work in dynamic publishing.

I've also switched from MTKeyValue to CustomFields. Custom fields isn't compatible with dynamic publishing either, but it is a bit slicker and I'm working around that for now because I'm only using it to publish the recent photos feature which I publish as a static file that is php-included.

I also started using MTFastsearch and even got it working along side dynamic caching, using mod_rewrite to redirect requests to fastsearch directly to a custom mtview.php script which has the caching disabled. In the process I found out that I don't entirely understand what is going on with the .htaccess created by dynamic publishing. Many things that I thought should work would not (for instance I had to put the rewrite I just mentioned up at the top right after turning rewrite on), and some things wouldn't work at all. I seem to have everything but the redirect form the .org site working now.

I also disabled fastcgi for the moment. It seemed to work out of the box, however the memory requirements seem to be even worse than before and I was getting the strange out of memory errors very frequently. The CGI performance doesn't seem to be too bad right now and we'll see how things are after the eventual TextDrive transition to Solaris.

All in all, so far, so good. I'll have to spend some time investigating some of the new features. I got the updated authentication options working (with some difficulty involving the __trans business) except for the option to register directly with the blog, for instance.

Update: One more dynamic publishing snag. It seems that when I delete a comment via the admin interface, the change won't be reflected on dynamically published pages. It is reflected on static pages, so the actual comment disappears from the entry. But the indexes still publish the cached version with the comment total unchanged. The work around seems to be to jog MT to clear the cache by turning caching off and then back on after deleting a comment. I haven't tested this with deleting other content, but the process of actually making a comment on the page seems to work just fine.

I was recently trawling through our site logs when I noticed that an IP address registered to Google had been doing an awful lot of searches on this blog lately, which made me think: "Hey, I haven't googled myself lately. Maybe this site's gone up in page rank."

And sure enough, I came to a most startling revelation. Not only is this blog the top result when searching for tapirtype blog (and believe me, this was not always the case), but by at least this one measure, I now appear to be the most prominent Michael Boyle in the blogosphere.

I'm as shocked as you are. All I can really say is: "Listen up, all you other millions of Michael Boyles out there. Men, get cracking. I mean, I don't update nearly often enough to qualify as the representative Michael Boyle blog."

I've been meaning to collect my impressions of the different blogging systems I've tried for a while now, but I've never seemed to get around to it. But today via Daring Fireball I noticed a little post from Joe Trotter that neatly sums up my conclusions and the reason why I've stuck with Movable Type. So now's as good a time as any to quickly throw in my two cents.

I wouldn't go so far as to say that "I hate Wordpress," and Gruber's response is correct, we shouldn't confuse templates with blogging systems. You could undoubtedly make just about any site in just about any of the top blogging systems currently in use. But just because you can do something doesn't mean that your experience doing it will be pleasant. The key observation is in Trotter's final paragraph:

I think the problem is that Wordpress themes (and to a greater extent the entire system) are so designed that modifications stick out like a sore thumb - the themes never strike a good balance between flexibility and aesthetics. I’m thinking more and more to switch to Movable Type. The cachet of Wordpress just doesn’t appeal to me anymore.

Of course if you are a skilled Wordpress template designer you can make beautiful completely original or tastefully modified templates, but it isn't what Wordpress is good at. What's made Wordpress so popular -- and what has, in part, made Movable Type less popular in contrast -- is that Wordpress makes it very easy to do single click design changes. Whether or not this was inevitable, that (among other things) has made it conversely more complicated to implement templates yourself and encourages (though it doesn't demand) even original templates to conform to a certain "Wordpress way of thinking."

In order to make a new Wordpress template you have to know way more about how Wordpress itself works than you have to know about Movable Type. If you want to do anything beyond the standard you will quickly find yourself thinking about the mechanics of the database queries going on in the background, and if I wanted to think about that, I'd write my blogging software myself. In contrast, Making a Movable Type template is, simply, making a website. Not much different from designing a static page.

Therefore, I'd heartily recommend Wordpress over Movable Type to anyone who just wants to choose an existing template, maybe change a couple of colors and pictures, and get blogging. But anyone interested in the ease of customizing the design would be better served by Movable Type. People talk about how they love Wordpress in contrast to Movable Type because they always feel like they're fighting with Movable Type. But while the vanilla install was easy, designing my own templates in Wordpress felt like as big or bigger of a battle.

I think that explains a lot. Wordpress may have a somewhat slicker application, but if the design is what you care about, Moveable Type is an easier, more elegant, sandbox to play in. I'm sure that has something to do with why people who are primarily interested in design often choose Movable Type (or Textpattern or ExpressionEngine), even as the rest of the world is moving over to the plug and play "good enough out of the box" simplicity of Wordpress.

PS And yes, I know that my own blog looks fairly "Movable Typeish" as it has evolved from the standard templates.

I just tweaked the design of the blog a bit. One of the remaining hold overs from the standard design that I wasn't happy with was the way the bottom of the entries were handled. It placed the authorship and date of the articles at the bottom, meaning that you had to look get through the entire thing to see who wrote it and when, and almost worse, the horizontal lines got very repetitive and harsh. Hopefully this update addresses this.

Incidentally, I made the design changes with using Bare Bone's free TextWrangler and MacRabbits's appropriately named CSSEdit 2 which they sell online for about $30. TextWrangler is about as good as it gets for a free text editor and is really useful for editing files in place on sftp servers.

I adore CSSEdit for so many reasons. First off, you've got to love a company named MacRabbit who, when they charge you for their software, have the transaction be with "Space Carrot." The real reason I love them, though is that when I originally bought CSSEdit 1 it was full of bugs and I kind of regretted it. But just when I was about to give up on them, they sent me an email telling me that they were giving me a free upgrade to CSSEdit 2 which fixed almost all of my problems.

CSSEdit has a few killer features. First, it allows you to instantly preview the changes you make to the file as you type (though it still seems to get out of sync occasionally and require a manual reload of the preview). Even better it allows you to look at any web page, extract the css files it uses and override them with the version you are editing. This makes tweaking existing styles very easy, as any new page you preview that references the same css will preview with the new overriding file. It also allows you to click on any element, see it's bounding box--with padding and margins--and see all the classes it has inherited. It's hard to overstate how useful it is to be able to see the bounding boxes of your elements as you edit, because, love style sheets as I do, it isn't always very clear how the bounding box will end up. It also does a good job of making it easy to switch back and forth between editing the code and using their own GUI.

Anyway, I'm a fan, and between those two tools, for under $30 I've pretty much completely replaced my need for an expensive web editing program from Adobe.

I think I've fixed comments under FastCGI. I added one line from the Bootstrap module to the dispatch.fcgi that wasn't in Brad Choate's original instructions and that seems to have done it. I'll update with better instructions soon.

Update put up some more details at the top of the old instructions. I promise I'll get around to putting up comprehensive updated instructions one of these days.

Well, I did the update and basically seem to be back at status quo. Comments are still flaky under fcgi, so I'm still using normal cgi for them. That may be because I'm not using the Bootstrap module right, this way works for now.

Well, looks like Six Apart has released a new version of Movable Type with increased FastCGI support. Presumably this means they've finished tweaking the whole MT::Bootstrap setup, etc. Well, I'm glad I didn't get around to revising my instructions yet.

Hopefully this update will fix the remaining stability problems I've been having with my FastCGI setup. Of course they recommend using Apache and Textdrive previously frowned upon that to me, so we'll see. First I'll just try the update with my current setup and then I might try it under Apache again to see if that'll work now. Either way, a more public, stable, and accessible way to use Movable Type under FastCGI is a very good thing if for no other reason than that there will be just that many more people noticing bugs and clamoring for fixes.

Ok, yes, I know that's tautology, but usually spam at least has a chance of benefitting the spammer somehow. But why, oh why, did I get trackback spam pointing to, and only pointing to, google?

Update 1/27/07: MT 3.34 is out with improved FastCGI support and between that and some experience, I've tweaked my setup some. I need to write up a better set of instructions, but right now my computer is in for repairs and I'm not up to writing a lengthy entry on a borrowed computer right now. The main things that I've changed are that I'm now having LightTPD spawn only one dispatch process and I've added one important line to the dispatch script as follows:

Just inside the eval block right above the line that reads: while (my $q = new CGI::Fast) { I've added in require MT; and right above the line that reads: $app->init_request(CGIObject => $q) unless $app->{init_request}; I've added the line: MT->set_instance($app);

These changes are to more closely match how the bootstrap module handles starting up a script and adding that line seems to allow comments to be reliably published through FastCGI.

However I am still getting periodic out of memory errors when I do more than a couple of big actions in a row such as a rebuild a comment and another rebuild. That makes me worry about what will happen as the blog grows.

Original text below:

Since it seems to be a bit of a moving target (and just so I remember myself), I thought I'd share what I did in order to get my Movable Type installation running with LightTPD and FastCGI at TextDrive. Needless to say, your milage may vary, especially at other hosts (and really I'm not sure that any other host will let you make this setup).

Why did I do this and was it worth it?

If you want to skip the background and get straight to the step by step instructions skip to the extended entry.

Unfortunately the real answer is probably a not so high minded "because I could" or "to see if I could" but in general if there's a better way to do things, I like to at least try to take advantage of it. To be certain, I'm seeking to solve a problem that I don't suffer from all that much. The problem being that standard CGI is slow. Every request for the CGI program will cause the perl (in this case) script to be compiled and loaded into memory even if you just used the same program a few seconds ago. This means that the user waits and the server gets the load of repeatedly starting new processes. It's easy to see how a stateless protocol like http would encourage this, but it can suck, especially when your blog gets hammered by spammers (or users for that matter) generating a huge number of requests to the comment or trackback script in quick succession. Even in normal operation, it simply slows things down and is one reason some people may find Movable Type less appealing than blogging applications which take a different approach, such as using php. The "standard" approach for fixing this in recent years has been to compile a script interpreter into Apache via a module like mod_php, but for a number of reasons that I don't entirely understand, mod_perl is not as secure or common as mod_php. FastCGI seeks to remedy this problem by starting one or more persistent processes which start up once and handle requests for scripts, staying active between requests. Unfortunately, Apache's implementation of FastCGI isn't very good (again for reasons that I do not entirely understand), however LightTPD was designed with good FastCGI support built in. Some people may favor using LightTPD anyway, even for serving static content because it apparently scales much better than Apache for handling high levels of traffic without requiring unreasonable amounts of resources.

So... Was it worth it? Well, as I said, I have neither a high traffic site nor one that has so far attracted (much) spamming, but the second at least is inevitable with time, and who knows, I could see more traffic someday. The bottom line, though, is that where I see the most difference is in the responsiveness of the application, and there you really can tell the difference. You click and the new page pops open. To be sure, there are still delays sometimes, and it isn't as if the rebuilds have gone away, but I never, anymore, have to wait for a link to open longer than I would expect from any static website.

Disadvantages? Well, anytime you stray out of the standard or increase the complexity of your setup, you do risk something unforeseen going wrong. You should probably keep a bit of a closer eye on things set up this way than you would otherwise. At first I did have a couple of major ongoing complaints with my setup: If you want to avoid having the port number in all of your links to the Movable Type application, you will need to proxy through from Apache to LightTPD which, in my hands anyway, causes Movable Type to see all incoming connections to be from localhost, confusing the spam filters. Also, the proxy setup means that you can't adjust mod_security yourself (you'd have to file a ticket to get them to disable it or modify the rules for you). Because of these problems, I've scrapped the proxy setup and simply have links to the application go directly to my LightTPD port. I'm waiting to hear from anyone about whether this could be a bad idea for some reason, but I'm happy so far.

Update 12/10/06: Thanks to a comment from Brad Choate, I've now fixed the problem with Movable Type seeing the wrong IP address and so I am now using the proxying method instead of pointing directly to the LightTPD port, and I've described that setup below.

Ok, here's the goods. Read on for the detailed version of how I got things set up:

Thanks to Textdrive, I've now got my Movable Type application running under fastcgi using lighttpd. All the normal serving of the pages generated by Movable Type is still going through Apache. More about what I had to do to get it to work shortly...

Update: I'm just testing out a new feature... Nothing to see here... Move along... Did it work now...?

My second pre-paid year of web hosting is coming to a close this December, so I figured I should re-evaluate my choice of service provider. Two years ago when I first investigated buying hosting for Sasha to put up Tapir Type I chose, somewhat at random, to go with OLM. When I say randomly, that isn't entirely true because I agonized over the choice somewhat, never having signed up with a hosting provider or registered a domain name before and having for the most part dropped out of exploring the nuts and bolts of Internet hosting before the bubble had even peaked. But they had a good recommendation from CNET and seemed to offer a lot for a little (but not so much so as to be too good to be true) so I jumped on them feeling they were a safe bet.

And they were. They've served me well over these first two years, never giving me much trouble and generally allowing me to do what I wanted to do. But they weren't very exciting or flexible and the few times I did want to do something different or figure out how something was working on the servers I didn't feel I had good options to turn to. And in general they didn't seem to have given too much though or put much interest in how they had things set up, they just made it work--a perfectly valid business model.

But since I got more involved with Tapirtype after setting up this blog, I became interested in going with a host that seemed to have a little more spirit and flexibility. Fortunately, naive as I was when first signing up for hosting, I did get the message that it was a good idea to register your domain name with a different company, so I had the flexibility to jump ship. When I started researching alternatives, TextDrive seemed like a good fit from the beginning. They don't offer the most raw numbers for the money, but on the other hand they were more than just an upgrade in power. Several things got me excited as I explored their website:

• They have a focus on free software and web standards and have a good Mac OS X community.

• They have a strong community with forums where people can and do help each other hash out their problems.

• They have clearly put real thought and pride into how they have set up their systems and have already thought of and come up with solutions to most common and many uncommon problems.

• There is a decent amount of documentation about how things are set up.

• Finally, while I might not need it now, they have many powerful options and are staying on top of the most current advances, giving me many opportunities to play with new technologies and expand my horizons, should I, say, get the desire to write my own app in Rails.

So I copied my files and databases over, tweaked things a bit, and pointed the domain over to their nameservers, so this is now being served up from Textdrive.

The move went pretty smoothly. I'll write more about the process and my impressions later, but I got it all done in under a week (and it was a very busy work week with only a little time every day to pay attention to hobbies) and I've only got one strange lingering issue--not TextDrive's fault--that doesn't seem to cause any real problems (for some reason the Movable Type summary screen thinks I have two identical weblogs even though in all other lists there's only the one).

I've already benefitted from the move in one concrete way. One of the problems that I had earlier while decrufting my links was that I was getting some strange behavior related to doing URL rewriting from the sub domain (probably to be expected). At TextDrive I was able to set up blog.tapirtype.com as an independent virtual domain from tapirtype.com giving me the ability to do redirects from mod_rewrite without bouncing back to www.tapirtype.com instead of blog.tapirtype.com.

So my rewrite rules now look like this, as they should, neatly funneling requests to entries in 2006 that might link to the old ".../basename.suffix" to ".../basename" and bouncing direct requests to the index back to the directory:

RewriteRule ^(.*)/index$ $1 [R=301]
RewriteRule ^(.*)/index\.(.*)$ $1 [R=301]
RewriteRule ^(2006/[\d][\d]/)([^/]+)\.(.*)$ $1$2 [R=301]

[this is good]
michael-james-
boyle.vox.com

Sign Up Now

I didn't get it...

I got into blogging almost by accident when I decided on a whim to downloaded Movable Type and install it on a subdomain of the website that I'd gotten set up for Sasha. Since it worked so well and turned out to be such a rewarding experience, I've kind of taken off with it and in the last few months I've done a great deal of exploring the world of writing and reading blogs. I'd kind of sat on the sidelines of the whole "blog revolution," reading a few from time to time, but never participating and never taking the time to explore things more than briefly. The last time I'd done any serious web authoring myself, frames were the next big thing. As a consequence I didn't really get it on a number of levels.

I didn't understand how the technology worked any more. I didn't understand why blogs had become such an effective and popular mode of communication on the internet. I didn't understand the shear breadth of kinds of blogs. I didn't even get what the deal with Flickr was, thinking that it was trying to be some kind of iPhoto replacement only slower and over the internet. And although I still think that the term "Web 2.0" is about the stupidest thing ever, I certainly didn't get what made it different from "Web 1.0."¹

Now, I think, I do get it. And playing around with Vox in the last few days, I think it has the potential to have a very important place in it all.

I wrote a whole entry about my solution to the footnote problems that I'm having since I de-crufted my links. Basically I worked out that it isn't that hard (or long winded) to use Textile directly to make footnotes instead of using the specific Textile footnote syntax. It was great, a little longer than the simple [1] type of input you are supposed to use, but it worked... Except it didn't work¹.

Ok, so I went and did the whole "cruftless links" thing and no sooner had I finished writing the post but I found about a million little reasons why what I did and had just described didn't quite work.

I'm still not quite sure what the deal with some of the behavior I'm seeing is, but I've got things to a somewhat stable point now. This is what I've settled on:

Update, the second: Well, so it's not perfect after all. I'd figured that some of the problems encountered by other people had been fixed in the current version of Movable Type. However it looks like for some reason it still insists on sending you trackbacks to the "/index.php" and on sending you back to "/index.php" upon completing a comment. And for some reason it seems to break autodetection of trackback URLs as well. There is no reason for any of this to be the default behavior!

Update: Oh, crap, this seems to break trackback autodetection...

Ok, so at least 90% of the point of this blog so far has been as a tool for me to learn by doing how modern web apps and design works. Sure this is also a great creative outlet and a great way to share little tidbits with friends and family that are far away. As a consequence I find myself being interested in things that are really the purview of much larger sites. Sites that aren't so obscure that they don't even get spammed.¹ But because the whole point is for me to learn, and because who knows, if I keep at this for years (and I don't see why I won't) this site might grow, I want to set things up as much "the right way" as I can while it is still relatively easy to make changes.

I don't own a Windows machine or have access to one on a daily basis, so I took an opportunity to check out the blog from Microsoft Internet Explorer, and man, does it not render right! Of course, it also choked on the New York Times website, so we're not alone. Unfortunately I forgot to check what the version was (it isn't by any means guaranteed that the computer I was using was up to date), but it was under XP. Most of the main site was at least readable, but it couldn't handle the photo galleries at all. It didn't seem to get css widths right and it didn't even seem to be trying to display the pngs.

Anyway, I can't really bring myself to care. I develop this site on a mac and use Safari as my main browser, resorting to Firefox on the rare occasions that Safari can't handle. So I check the site in Firefox before I make anything really new and as long as it works there I'm happy. That said, if you are wondering why this site looks so broken, please do yourself a favor and use something other than Internet Explorer.

Update: Well, it looks like MSIE is back to being able to render the NYT website ok. Must have been a one day thing. The bottom line still applies, though, that imperfect as this site is, I'm going to use standards compliance and how it renders in Safari and Firefox as my target and not worry about whether that breaks things for MSIE (which I can't check easily anyway).

I just migrated the blog to php so that I can later take advantage of php inside our pages. This means that if, by some chance, someone out there has linked to a page here ending in ".html," they should now be going to the same page but ending in ".php" instead.

You may of noticed that I kind of petered out on my last post about our Saturday morning tradition. That's largely because I spent all day working on a convenient way to format entries in Movable Type with multiple pictures and text flowing around them. We're using Movable Type here at Tapirtype, and largely I couldn't be happier. I looked into it the other day and discovered that I could set up a non-commercial blog for free, which is great, and I downloaded it, expecting to quickly run into a snag that I couldn't resolve. To my surprise, after creating a new subdomain on our webserver, I was able to install and set up the software very easily.

Furthermore, they've set up the software to be almost infinitely flexible, taking care of all the drudgery of blogging, while still allowing you to make your site look and behave pretty much any way you want. I've only done mild re-formatting so far, but I could, and probably will, do much more eventually.

Furthermore, publishing and management is very easy. The software is set up to easily manage publishing text based entries, comments, searching, trackbacks, and the like, and you can easily upload a picture and write an entry around it. But it is just flexible enough to encourage you to want to do more, and produce a well formatted photo essay like the one I wanted to make. Unfortunately, there things get more difficult...