supersonic feet

The official Rails blog has the announcement that Rails 2.0 is done and great news that is too. Now I just need to find the time to eventually catch up on all the changes and start playing with it!

Not quite but Derek Sivers, an early proponent of switching to Rails for large-scale websites, has written a post on his O’Reilly blog about why he just gave up on 2 years’ work in Rails on his CD Baby project to switch back to PHP.

It’s a very sensible article looking at the fact that Rails isn’t always the answer, much as it may pain us to admit, and that when PHP (or any other language) would actually be easier to use, we just should.

That said, I haven’t been tempted back to PHP for anything just yet

At Gottabet we’re looking for a ‘web application designer’ to join the team. The job entails a range of web dev, from helping design various sections/features of the website to implementing them in HTML and CSS.

There’s a full job spec on the website, so if you’re a developer who’s big on web standards looking for an exciting, fast-paced job working on a big social website, check out the job spec and get in touch with Wim and Bertrand (email addresses on the linked page).

The top-secret project I’ve been working on since moving down to London at the end of October had a still-quite-secret launch late last week and now we’re ready to tell a few more people.

Without further ado, I present Gottabet.com!

Gottabet.com is a social networking site where people exchange challenges and bets on any event they can think of, from “I bet it’ll be a white Christmas this year” to “Nobody can catch a pigeon” (thanks to my brother, Christian for posting those two).
I say a ’still-quite-secret’ launch last week, but only in as much as it was limited to a small number of people. The launch itself was far from secret, held in a pub where we got drunk people to take part in silly bets and dares. The result was a set of photos that I’ve added to flickr under a new Gottabet-specific account. There are some pretty funny pictures (especially the two people racing to fit the most Maltesers in their mouth), so check ‘em out.
On a more techy note of possible interest, the site has been developed entirely in Ruby on Rails by a team of 5 developers (including me, though I’ve worked much more on the HTML/CSS side of things). The site was built in around 6 months, which is even more impressive when you find out that for the first few months there was only one developer (Peter) working on it. The other three (Rich, Ken and Phil) joined within a few weeks of each other around September time and I joined at the very end of October.

The team is completed by (and indeed started with) two Belgians: the founders Wim Vernaeve and Bertrand Bodson. They came up with the idea around a year ago and have gone from simple idea to launched website in that time. There’s a team photo on the ‘about Gottabet.com‘ page. Mini-profiles of each of us will be added soon too.

To get you started, have a look at my latest bet: I bet at least one of the presents I’ve ordered won’t arrive in time. It’s just for peanuts, no money needed

I’ve spent a good portion of my weekend banging my head against the desk after getting the hare-brained idea, following my success in setting up Apache 1.3.x with mod_proxy and Mongrel, to get Apache 2.2 running on my server so that I could then use mod_proxy_balancer and therefore mongrel_cluster.

As anyone who’s ever asked the question “How easy is it to install Apache 2 on a cPanel server?” knows, the answer has always been “don’t bother”. In the past couple of weeks however, CPanel finally added support for Apache 2 in their latest EDGE builds. After a quick bit of reading of the cPanel forums, it seemed people had it working well enough and so I embarked, without much forethought, on the upgrade.

A day or so and many, many hours of frustration later and I have it working, so I thought I’d round up my experience as before to try and save some poor souls the same experience. (more…)

Found via Ruby Inside, Chris Wanstrath has posted a great round-up of a developer’s options for session management within Rails.

Stefan Kaes’ solution looks like the one I’m gonna go for in the near future.

Something I check on the status of now and then is the ability to have a nice upload progress bar for uploads via the browser. Sean Treadway’s initial example looked great but required special server setup.

Support was added to Mongrel recently, but I never got around to properly investigating as there was no documentation of it, which didn’t help. A random check of the Mongrel site has just revealed they’ve finally added some instructions for upload progress on Mongrel.

I haven’t tried it yet (it’s late, must sleep), but at least there’s a base to work from now.

My previous post mentioned FireBug and how handy it is in tracking/debugging AJAX requests and code. This was particularly important as the problem I’m having is with Sortable lists (in tree form) and child elements not being serialized when they’re added via AJAX. To explain a bit further, I’m using the technique to list the pages of a site, with sub-levels loaded in via AJAX so that you don’t get loaded with a few hundred pages listed all at once when you only want to get to the home page. That bit’s fine though - works perfectly. The problem is with the sortable part - here I’ve had no end of troubles.

My first problem is that I’m no JavaScript god. I can generally figure out just about what’s going on and write my own simple code, but I’m at no kind of level to be doing clever debugging. Doing sortable lists with a tree requires much clever debugging.

Problem two lay in my use of semantic XHTML markup and the result that the sortable list items also include lists that shouldn’t be sortable (lists of options). This initially breaks Sortable.serialize as the non-sortable list items don’t have IDs in the form tag_x for serialization, which in turn makes the serialize function skip anything below that level. Not good.

I tried adding in code to the serialize function to make it ignore the non-sortable lists, but this is where my JS skills hit a wall and in the end I’ve had to assign the option list items unfeasibly high ID numbers based on the page they’re associated to (something along the lines of page_pageID000000000x).

With that done (still working on the list starting showing two levels deep), the serialize function would get the whole lot and briefly I was happy. Alas, I then tried to add the code to load in sub-levels of pages via AJAX and of course the serialize function didn’t see the ‘new’ list items as the Sortable had been created before them. A quick search of Google and a common sense approach of re-creating the Sortable at the time the new list items are inserted seemed the way to go. I found someone claiming it worked to just re-declare the Sortable.create but no luck for me.

I’m still working on it

Another area I was having trouble with in Rails and found a simple plugin solution - switching layouts depending on whether you’re logged in and which theme you’ve chosen if you are.

Matt McCray comes to the rescue with his Rails Theme Support Plugin. It allows you to have multiple themes in their own sub-directories and only having copies of templates that actually differe from the application default - if there’s no theme-specific file it’ll just use the default one.

It also has Liquid templating support, though that’s not something I’m using at the moment. Might come in handy in the future though.

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