I’ve been having a lot of problems with comments on this blog taking forever to post, being silently rejected, etc. After lots of messing around, I found it to be a combination of a) A theme that doesn’t handle problems with comments being locked and b) the built in anti spam protection making comments take 30 seconds rather than half a second to post.

I never want to calculate how much of my life I’ve lost to spam or spam filters, doesn’t bare thinking about.

Apologies to anybody who tried to post a comment.

Whilst doing this, I used a great new feature of the absolutely essential web development plug in for Firefox, Firebug. One of the new views, network activity monitoring, shows all the files loaded (the contents of the request and response) and how long overall the process took.

Absolutely essential for debugging AJAX code, but also brilliant to see where you can speed up your page load times. The following shows me debugging some time issues on one of a site using Virtual Earth. Watching some of the files load from Microsoft’s site, and take 10 seconds, suggested I make key files local. This massively reduces the load times, and makes the whole site feel much nicer.

I cannot recommend Firebug strongly enough !

After all the effort of changing Weblogs, I’ve realised that Typo ‘out of the box’ does not support comments added to its syndication streams. I’ve hacked around in the code and managed to get something working. Rails XML helpers make this stuff pretty easy.

Weirdly there does not seem to be an agreed format for doing comments in ATOM at all, where as RSS has various different comment tags. I’ve used wfs:commentsRss and slash:comments nodes in both formats, with the comments just in Rss 2. The Feed Validator seems happy.

Anyway the following work well with my aggregator, Rss Bandit, as well as IE 7. If anyone has any problems with other aggregators, can you let me know. Thanks.

Local feeds:

• Rss 2.0 (all)
• Rss 2.0 (Just Delphi articles)
• Atom 1.0 (all)
• Atom 1.0 (Just Delphi articles)

What

I’ve moved my blog away from Blogger.com and on to a Typo installation hosted ourselves. Typo is a weblog application that runs on top of Ruby On Rails, the latest posterchild of the open source community. I chose a rails based blog because I’ve been doing work with rails recently, I understand it, and I really like it (I’m half way through writing up an entry about why I like it).

Why

The main reason is that blogger feed does not include comments people make. I personally read most blogs in an aggregator, and without comments being included, its only one half of the conversation.

For the last year we have been working on a product for a client that uses Queuing Theory to model how servers operate under load, an area known as ‘Capacity Management’. Performance agents log ongoing behaviour on the server, and then the results are plugged into various mathmatical formulae that show how the server will work if your email doubles, your websites have 10 times as much load, etc.

Here at Concept First we have a data centre hosted server that handles email, ftp, and various client’s websites. In the spirit of ‘dog-fooding’, I’ve been running monitoring software on our hosted server, and building models of its spare capacity.

The results are: we have stupid amounts of spare capacity. The server is a 1U rack mounted server from Dell, 1G of RAM, mirrored RAID disks, a single 2Ghz processor. A fairly low spec machine these days, we bought it about 3 years ago. And basically it never does anything. I’ve never seen the CPU loads rise about 5%, same for disk utilisation. Modern hardware is so fast, that a few web requests and a bit of email are not not giving it much of a workout.

For that reason, I’m happy to run an interpreted language framework for this blog, because we really do have CPU cycles to waste, and I don’t have time to waste. Having a Rails app running on my server full time will also allow me to understand if it’s stable under Windows.

How

Style

Typo is easy to install if you’ve worked with Rails, its just a load of files in a directory. You can choose from 2 built in themes or download lots of others. I’ve taken one of the built in ones and just changed it to make use of the full screen.

I hate fixed width websites. What is the point of my lovely 1920 wide screen laptop if the site is only 500 pixels wide !! Adjusting to the display has always been a key strength of HTML. Too many people are still designing for the web as though it was a piece of paper !

However the move away from fixed width has caused a small bug to display in IE 6, when using the search box in the top right hand corner. There is flickering as the AJAX call is done. However the issue does not occur in IE 7 or Firefox so it is no doubt one of the boatload of IE 6 rendering bugs, so i’m not going to pursuit it. Life is too short.

Database

Typo supports just about every database, but I’ve just left it running on a simple SQLite database. Typo caches everything so i don’t really need the hassle of putting it in a real RDBMS. The server is already running SQL Server, MySQL and Oracle XE. Maintaining what apps use what databases, where, is a bit of a headache. A file based database is just easier to manage if you can get away with it.

Webserver

Our server is running, or has run in the past, various different websites running on lots of different technologies: ASP, Websnap, Coldfusion, Zope, Php, Perl. To manage all this, we use Apache 2 running on Windows Server 2000. Apache has been good to us. Its very flexible, well documented, secure, and scalable. It is our Internet facing webserver. It handles SSL, compression (via mod_deflate) and virtual hosting.

To connect our hosted sites up to the Apache ‘gateway’ we’ve tried various things. We’ve tried Apache modules, ISAPI, FastCGI, SCGI, mod_php.

Apache modules / ISAPI: Nice and fast, but too tightly bound. When Apache versions change a recompile is required. Restart the server and you lose server state, like current sessions. Bugs can jeapodise the server stability.

FastCGI: Works well, we have various websnap sites running over FastCGI. However the protocol is complex, binary, and the whole FastCGI protocol is not actively developed any longer.

SCGI: A simpler version of FastCGI, I’ve run a couple of Rails sites on SCGI. The protocol is easier to understand, but its another set of config to learn, and not all technologies support SCGI.

With this in mind, we now use simple HTTP proxing. Each different application runs its own webserver on an internal port number, the firewall preventing any access to the outside world. Apache then uses its mod_proxy settings to pass the request to the applications webserver, before passing it back to the web browser.

Advantages:

• Debugging is simple. Just fire up a copy of Fiddler.
• All applications support SSL, Apache handles it.
• All applications support compression, Apache handles it.
• All application logged in same format, I can use the same tools.
• Apache can use its redirect rules to enforce my rules (e.g. admin in Typo must be secure).
• Upgrading any individual application has no effect on the others, everything is loosly coupled.
• Most importantly: One set of syntax for me to remember.

It all works beautifully. It’s happily proxing to Rails, to web services exposed in Indy components. It’s fast, and it ‘Just Works’, not often you get to say that in the world of computing ...