Via a link in my facebook, I came across:
It’s the I.P.O., Stupid!.

My first job from college (actually helped start, and got credit for it as a senior project) was as the original programmer for theglobe.com.

I remember long hours back in the CS lab at Cornell getting our version of web based chat (one of only 3 at the time )running on our PowerMac 6100 pizza box machines. And the random outages we had whenever we decided to play a networked game of Marathon.

After the earlier news of Evil, Inc. coming on board, Brad has now also moved Courting Disaster, his relatioship comic; and Phables, about life in Philly; over to Dumbrella Hosting.

Check them out!

I'm a little late getting around to posting this, but my latest client is Brad Guigar, talented creator of Evil Inc..

Due to the lack of a better excuse, I'm going to say that the delay is because I thought that this announcement was really best scheduled for Halloween, given his comic's theme and color scheme.

I encourage you to jump on over, read through his archives, and let us know about any bugs you find.

Internationalization isn't something I've really had to deal with before. Trust Greg Dean to force my hand.

For most of my hosted sites, it's not an issue. The templating is entirely under the creators' control, so if they want to be in French, German, Canadian, or whatever, then most of the work is just making sure that their templates are in the right language.

However, parts of the site that are "functional" (registration/log-in, forums, etc), tend to be auto-generated, and that's where problems start.

I have some ideas of how to get this working on a larger basis, and have done the minimal research to get an idea of what best practices are. The big thing with the launch of Greg's german site, was that I had to have timestamps, for both his strips and his rants to auto-generate in the right language.

Luckily, at some point in the past couple of years, I had decided to standardize all my date manipulation on the perl DateTime module. This was great when I started setting Greg up initially, and also when Dave Kellett moved over, because midnight too these Californians (for comic updating) is apparently a few hours off from my east coast sensibilities.

DateTime also has built in, and easy, support for Locales. I had already started to throw together support for that, knowing that whatever solution I ended up with would have some basis in that area, but little did I know that a simple function call, right when my "site" variables are being created would automatically make all dates show up correctly for all page rendering.

It's so nice when something that looks to be a pain in the ass just suddenly "works". And more importantly, let's me delay implementing all the other hard bits for another day.

The servers have been under a lot of stress pretty much since Project Wonderful took up residence. The web servers tend to be ok-ish, but the database is under a lot of load. Serving ads requires a fair amount of work, you need to update the database for every ad viewed and clicked on, and use that data to decide what ad to show. For PW, you also need to keep track of the ever-changing bids and such associated with the ad campaigns.

Ryan North seems to always be tinkering with the underlying code, trying to optimize the database pieces to be friendlier, but there's only so much (even) he can do, until we can afford some heftier database boxes.

While I leave him to his own devices, I'm stuck trying to make sure that my clients' sites are still reasonably responsive even when the database is slow.

The solution, obviously, is to cache that data locally, so I have to re-fetch as little as possible as infrequently as possible. There's different ways to do this, and I use a combination of solutions.

While there are solutions out there to pseudo-automate this, layers that sit between your code and the database and try to store the results of queries for you, I tend not to trust these. I have a lot of intertwined tables, and most of my queries end up getting data from multiple places, I feel I would end up spending more time telling this intermediate layer when to expire old/stale data is worth the effort.

I use a (sort of) MVC set up on the servers. Most "real" work is done in perl libraries, and then display is left to HTML::Mason. Those are my two best options for caching.

In the past, I've almost exclusively used Mason's built-in caching. It's great because it makes it easy to store rendered HTML, which means that I get two wins for one: reduced load on the database, and less computation on the web server (assuming that the HTML requires more resources to render than the caching takes to retrieve the data, which generally it does). I use this for most elements of clients' homepages, for things like "todays comic", the list of news posts, &c.

The down-side is that the reason I have a dynamic site, is because it's dynamic. There are a lot of places where it just doesn't make sense to cache the HTML. Take the Goats Forums, for example. Not only is there a lot of database work there (each comment, its text, info about the user who posted the comment, &c.), but it can be views approximately 3.8 zillion different ways. Users ca choose a flat, threaded, or nested view, that view can be ascending or descending over time. Users can jump to specific comments, meaning that previous comments won't get seen. Users can set a "threshold" to block lower rated comments, &c.

The code is loosely based on an old version of Slash. They solve this (or at least they did back when I was looking at the code) by just outputting a rendered version of the entire thread, and ignoring user preferences for old/archive/locked discussions. This probably saves a lot of server resources, but it felt "wrong" to me, I'm weird like that.

So last week, I finally did what I should have done ages ago, and wrote the caching into the back-end libraries. I now cache the fetched "Comment" objects to disk (using Cache::FileCache, and expire the cached version any time there is any kind of update to a discussion. This required some fairly extensive changes to the way the underlying code worked, although I tried to isolate it as much as possible, especially since some of that is pretty old and crufty.

I expected this to break immediately and spectacularly, and cause me major headaches, but so far no one has commented. Hopefully that's a good thing, and not bad. Changes like this are always interesting, because if they work, no one notices, and then you just get emails complaining that you wasted a week not working.

Probably, they're just bitching and moaning in the forums, and I'm just not updating the cache with those comments. I choose to think that not seeing those is feature, not a bug.

I just got back from a week in Scotland, working hard at visiting a few distilleries. However, the week before I left was somewhat more eventful, from a work perspective.

Some background. Back in February of 2005, when I was still part of Goats, we moved to new servers hosted by voxel. All has been well and good, and they continue to be an amazing company. I recommend them to anyone, primarily because they're the first hosting company I've dealt with that doesn't treat me like a idiot... which may or may not be a mistake on their part.

When we moved over, our machines were put in a hosting facility in Parsippany, NJ. After taking on Real Life Comics as my first non-Goats client, I had to expand my server pool. The new servers were in a facility in NYC. I moved over the database and the web severs, but since setting up a high quality email solution is such a pain in the ass, I left that on the old machine.

Unfortunately, they were closing their Parsippany location at the end of August, and losing the machines in it. So while I got a much better machine for a much cheaper dollar price in exchange, the "real" price was that I had to re-set up the mail server.

Since I (for now) remain a qmail fan, I started with the directions at qmailrocks.org. However, since:

1. the directionds and dowload havn't been updated since early 2006
2. I've learned a thing or two (barely) since then

I also supplemented it with newer versions of almost every piece of software mentioned, and used the excellent information available at John Simpson's qmail site.

I hate messing with the mail server, because there's so many independent pieces that are supposed to work together, from the various pieces of qmail (including config files for all the various patches and enhancements like validrcptto and rblsmtpd), to getting SpamAssassin and ClamAV scanning incoming messages, to getting SSL/TLS version of SMTP, POP and IMAP all working, to having some sort of functional webmail client in place.

Having finally gotten all this working, I promptly jumped on a plane to Glasgow, hoping for the best, or at least a somewhat functional internet connection. Luckily, I had the latter; so all seems to be working pretty well right now.

I may be a week late getting my SDCC wrap-up posted, but I'm still ahead of some of the other folks I was there with, so it's not a total loss.

Overall, I was tremendously happy with how this year went. The booth ran better than it ever has before, and I think that made everyone a little less stressed.

Jeff gets mega-props for taking the lead on booth design/set-up, shipping, and social arrangements. I think that our after-con evenings were more fun than they have been in a while. For my part, that was made possible only with the help of Gary. Like last year, having him come back and help with the daily money counts, report generating, etc for each of the artists meant that I actually got out in time to eat dinner, which is a welcome improvement over two years ago. The booth itself was a lot calmer with the help of non-artists Ferocious J and Bort, both excellent t-shirt-wranglers, which keeps everything running more quickly.

A week later, I'm almost caught up on the stuff I should have been doing that week, and now I can get back to doing the stuff I should have been doing the month before that.