Supersonic Feet

A few weeks ago I returned to the world of hiring a full dedicated server for running my websites. The extra control and stability (and resources!) convinced me to make the switch back from shared hosting.

The one downside is that unless you're paying the extra for a managed server, you then have to know what you're doing in terms of system admin, which I can just about handle, but I'm no expert. This weekend I finally got around to start moving this website to the new server, which after a brief problem with a dodgy CPanel install, went fine (though I'm still having email trouble, so may not be able to read/reply to emails for the next day or so).

With this blog up and running, it came time to make sure the Rails CMS I'm developing would work too. This is the one downside of Rails - it's never simple to move a Rails app to a new server. After getting frustrated with FastCGI setup for an hour or two, I decided to try this Mongrel lark that people have been on about so much recently.
Mongrel is basically a fast little server for Ruby aimed at running web applications without the need for FastCGI or SCGI. You can run it alongside Apache/lighttpd in order to get the best of both worlds. lighttpd seems to be the server of choice for Rails devs, though my server runs CPanel and I didn't want to have to confuse things any more than necessary (plus Mongrel devs seem to advise against lighttpd these days as they've stopped work on mod_proxy).

Nonetheless, it looked like getting Mongrel going would involve all kinds of weird and (not so) wonderful custom modifications on my server to get it playing nicely with CPanel (a great server admin system, but does limit adding things that might conflict with Apache). Despite a few stages of utter confusion on my part, in the end it was extremely simple, so to save a few people some time (hopefully), here's a bit of a newbie's guide to getting mod_proxy and Mongrel running on a CPanel server. I did this on a CentOS 4 machine.

Installing Mongrel

This, amazingly, is a really simple three-step process as described on the Mongrel homepage:

1. $ sudo gem install mongrel
2. $ cd /home/USER/myrailsapp
3. $ mongrel_rails start -d

I was expecting to need to do more, but this much seriously will give you a mongrel server running in three commands. There's presumably lots of clever configuration you can do to improve performance, but this works for the basic server.

Step 1 installs mongrel as a Ruby Gem.

Step 2 gets you into your Rails app's directory

Step 3 starts the mongrel server daemon to run in the background (you can stop it with mongrel_rails stop)

If you've just done the above, you probably want to stop the mongrel server and restart it as I did to run on a different port so that it'll play nicely with Apache:

$ mongrel_rails start -d -p 8000

This will start the mongrel server running on port 8000 (choose whatever you want).

What we can now do is set up Apache with mod_proxy and point the relevant part of our website at the Mongrel server...

Setting up mod_proxy

This again turned out to be easier than expected, though I think CentOS helps by having the module readily available. I'm not sure if all CPanel setups on other distros will have the same luck, though I would imagine they should.

The steps to install/set up mod_proxy are as described in this post on CPanel's forums:

1. $ cd /home/cpapachebuild/buildapache/apache_1.3.37/src/modules/proxy/
2. $ /usr/local/apache/bin/apxs -i -c *.c

The above two steps generate the libproxy.so file and place it in the libexec directory for Apache's use.

With this done, you're ready to edit Apache's config file, httpd.conf. You'll find it in /etc/httpd/conf/httpd.conf

Open in a text editor (vi, pico, etc. - pico's easiest for beginners), i.e. pico /etc/httpd/conf/httpd.conf and search for 'LoadModule' (ctrl+w in pico) to find the section where all the modules get loaded.

At the end of the LoadModule lines, add yours:

LoadModule proxy_module libexec/mod_proxy.so

Below this, you should see a list of lines starting 'AddModule'. Again, go to the bottom and add your own line:

AddModule mod_proxy.c

Save the file and return to the shell. You can now restart Apache to make sure it's working:

/sbin/service httpd restart

As long as it tells you it's restarted OK, you're ready to point Apache at your Mongrel server. I set mine up as a sub-domain, so I'll use that as an example (you can set the sub-domain up via CPanel).

Pointing Apache at Mongrel

Let's say I want my app at adamsapp.supersonicfeet.com. I've already created the sub-domain via CPanel, so I just need to edit the Apache config, which means opening httpd.conf again:

$ pico /etc/httpd/conf/httpd.conf

Do a search in the file for the sub-domain, 'adamsapp.supersonicfeet.com' and you should find a section of code wrapped in tags, e.g.

ServerAlias www.adamsapp.supersonicfeet.com
...
...

There'll probably be quite a lot of stuff in there, possibly including some IfModule tags. Find the /VirtualHost tag and insert these two new lines just before (above) it:

ProxyPass / http://www.supersonicfeet.com:8000/
ProxyPassReverse / http://www.supersonicfeet.com:8000/

In the above, you'd replace supersonicfeet.com with your own domain name (not the sub-domain you've just created for the app) and 8000 with whatever port you started your Mongrel server on. These two commands tell the server to forward all requests to '/' on the current VirtualHost (adamsapp.supersonicfeet.com) to the address http://www.supersonicfeet.com:8000/.

In other words, if a visitor enters http://adamsapp.supersonicfeet.com/ into their browser, Apache will see that request and forward it to http://www.supersonicfeet.com:8000/ (the Mongrel server), before returning the result to the visitor's browser. The visitor will just see that they're looking at http://adamsapp.supersonicfeet.com/ - they'll see no trace of the weird port number.

Equally, say they went to http://adamsapp.supersonicfeet.com/news/2006/08/21 - Apache would be showing them the result of http://www.supersonicfeet.com:8000/news/2006/08/21 but without changing the address that the visitor sees at the top of their browser. Apache is basically handing off control of any address under adamsapp.supersonicfeet.com to the Mongrel server running on port 8000 (our Rails app).

By my count, that's seven basic steps to set up Mongrel and mod_proxy on your server as well as point a sub-domain at the Mongrel server you're running. All this extra text has just been me rambling (and hopefully explaining some things a bit better). Feel free to ask any questions, please just bare in mind that I quite possibly won't know the answer if it goes beyond the above steps :)

Orange M3100My new Orange SPV M3100 arrived today.

All seems very good so far, but haven't had much chance to use it yet.

microSD cards are also seriously tiny. It's not right for a card that small to hold gigabytes of data!

As I mentioned in my previous post, at work we're moving a lot of clients to new hosting. Due to a very silly system at the old hosts, that means we have to transfer the domain names to a new registrar as well as they won't let us just point at another host's servers. We're using 123-Reg to transfer the domains to, and today I logged in to find a new site design.

It's quite a pleasant design, but what really got me is that it still uses frames. The layout is such that frames aren't even a natural thing to use. It looks like what's happened though, is that while their front-end site has been re-designed in nice tableless code with CSS to handle presentation as should be, the back-end domain management area isn't so easy to re-code/-style. So they stuck it in a frame.

I'm hoping that is the reason and that they're working on doing the management area properly, because if they've actually chosen to use frames on a fresh build, especially with the new layout they've used, it's madness. It does (hopefully) drive home the point about writing semantic, valid code though. If the original site was written semantically, they could just write a new stylesheet and have their new design implemented much more easily and quickly (aside from any actual content/functionality changes of course).

123-Reg have made a good step forward with their new site, the main 'sales' part being mostly valid HTML, with 'skip to content' links, etc. so they (or their designers) do seem aware of the need for standards-based coding, let's just hope the job gets finished :)

Philipp Lenssen just posted a nice short piece on how Google's homepage would stack up in filesize when written in XHTML Strict compared to its current invalid HTML, Google Strict vs. Google Deprecated.

I have to second what he says - any argument for keeping deprecated code based on filesize is quite silly. Valid XHTML (almost?) always reduces file size and both download and render times. Philipp's XHTML version comes in smaller than the current live Google version at 2.86k compared to 3.08k. Not a big difference, but multiple it a few million (billion?) times for all the traffic Google gets and it mounts up.

Where I think you'd see a much bigger difference is on the actual search result pages. With much more data (all in tables, which beef up code size quite a lot), the difference should be much more marked. Aside from that, I imagine that the results pages are seen much more often than the homepage. With more and more browsers having search bars alongside their address bars, people will increasingly not use the actual front page of search engines as they go from a small input box in the browser itself to the results page.
The results page would be harder to code in XHTML with CSS and still degrade properly in very old browsers (something Google has to think about more than most), but I'm sure it could be accomplished. Things are mad at work as we move a couple of hundred websites to a new server, but if I get the time and inspiration before someone else does, I might have a go at it as it's very interesting.

Forget my previous want for the Sony Ericsson W950i, I think I'm gonna try and get the Orange SPV M3100 this weekend. It basically seems to be a new version of my O2 mini, with all the niggles fixed and some great new tricks added.
A couple of bits had been nagging at me with the W950i while I waited for its release, largely the fact that it runs on Symbian OS rather than Windows Mobile. The Nokia 7710 that I had before getting my current O2 XDA mini ran on Symbian and while it was quite good, I've really grown to prefer Windows Mobile over it. Windows Mobile just seems to work better as a PDA OS to me (though I do think the 7710 probably had some PDA bits pulled out) and one major factor is that I have TomTom for Windows Mobile. If I got a Symbian phone I'd have to buy a new copy of TomTom. That's more a gripe at TomTom for not allowing/providing software for both on the same discs, but it's a big thing anyway.

The W950i also lacks a camera. At first I didn't really think that would bother me, but then when I thought about the number of times I've taken quick snaps with my phone because I didn't even have my little IXUS with me, it was also going to be a miss. It's a shame as the W950i looks like it's had a camera area designed and kept out, probably to release a higher model later or to prevent it being an uber-phone and making the 990i pointless. The 2mp camera on the M3100 should do nicely as the 1mp job on my o2 mini is a bit iffy. The M3100 tops it off with a second front-facing camera for video calling. Both the W950i and M3100 are 3G phones, but only the M3100 will do video calls and they thankfully haven't skimped, as many 3G phones seem to, by making you turn the phone round to use a single camera on the back and then stopping you seeing the person you're talking to. Now I just need to find some friends with 3G camera phones :D

Both phones have a touch-screen (something I've got very used to with the Nokia and then O2 mini) with stylus and the M3100 also seems to have a selection wheel like the Sony jog-dial, but I haven't found out exactly what it's for yet. The M3100 tops things off with a slide-out QWERTY keyboard for writing messages, documents, etc. which should be great.
The M3100 has a very similar set of keys on the front to my O2 mini, with two added. The Sony uses the new fashionable touch-sensitive keys which seem to be turning out to be more style over practicality judging by people's experiences with them on other new phones. They look a nice gimmick and certainly aid the aesthetics, but if they're gonna be too easy to activate by accident then I won't miss them.

Next plus for the M3100 is wi-fi. It's one major thing I was disappointed not to have on the O2 mini so it's great to see it on the M3100. Find a wi-fi hotspot and you can get online with the wi-fi either for free or for whatever rate the hotpsot charges. It should also make for quicker synchronisation with PCs.

The major bonus the Sony has over the Orange is it's 4GB built-in storage. I don't imagine a 4GB microSD card will come cheap for the M3100, but then if I'm honest I don't feel the need to listen to my music that often when away from a computer. A very quick check found a 2gb microSD for £53 which ain't cheap, but I can leave that until later when I have a bit more cash. A 1gb card is about £26 which would probably do me fine to be honest.

So all the above, plus the fact I can get the M3100 now and probably some stuff I've missed, is why I'm going for the SPV M3100. Hope my little comparison is of help to someone else - it's just how I've weighed up the pros/cons. Who knows, when I get an M3100 in my hands it might feel horrible, but based on my O2 mini, I'm pretty confident it's the phone for me.