2006
03.24

I’m migrating my website from PHP to Ruby on Rails. Last night, moved the PHP source code form my old hosts to RailsPlayground. Whilst good value (they do Rails, and have about 10 times the bandwidth/storage/features as my old host for less money) their site/support forum seems to have very dodgy availability. So was largely on my own for figuring out how to host PHP as I’m not that experienced in remote barebones hosting.

Turns out Rails routing applies across the whole site, not just in the railsapp directory, so PHP has to end in .php, and it has to go into the public folder, which in hindsight makes sense (most PHP apps live in the public area of a site).

Here’s the roadmap:

  • I have until the nameservers update to arrange for pretty URLs like vodex.net/goalpost to point to dirty ones like vodex.net/goalpost/index.php – don’t want to mess with visitors/search engines. This is a temporary kludge, so I’ll probably just alter Apache conf. a bit. I only have one Rails app live at present (Universe on Rails) and it’s low profile so it’s not important as I’ll…
  • Install a Ruby CMS/blog like Typo, and use it instead of the custom PHP setup I used to have.
  • Develop something like my current Wordpress Livejournal importer for Typo, using the LiveJournal Ruby module, thus standing on shoulders of giants (LJ’s XML-RPC API seems a little counter-intuitive).
  • Move on from there.

In related news, work upon a mockup document management system at the University proceeds apace, partially due to productivity gains from said Ruby on Rails. It’s true – Rails encapsulates best practice out of the box, leading to much better overall progress despite the learning curve. It’s all about the framework – Stuff that would have taken me months in PHP (even with PEAR) has taken just days in Rails. It’s also giving me experience in tools I didn’t make use of when developing GoalPost – Subversion version control, test-driven development, and similar agile methodologies.

At present I’m changing the view from an initial makeshift scaffold layout involving fieldsets to a much solider layout. Changing layout in rails is a snap, much easier than, say, in PHP, where you ended up with HTML-producing code inside logic classes *cough*.  Good workflow here – determine a view/layout (separate from the concerns of the logic creating it), then produce the current design in Dreamweaver or Nvu, say, and then componentize it into layouts. Much cleaner.

  1. You’re making me very very tempted to give Ruby On Rails a go. How easy is it to set up on Apache? I’m quite curious about what the performance is like as this seems to be the main debating point about it, and it’s one of those things where you don’t want to put lots of work in and then discover that it’s way too slow as soon as you have a few users.

  2. Apache, it can be done but I’ve had no luck with an existing stack. There is http://instantrails.rubyforge.org/wiki/wiki.pl which installs a WAMR (as in LAMP) stack for you though.

    I hear good things about its scaleability (beating JSP, etc.). I’m in the position of prototyping with Rails so I’m not too concerned with it. My advice is to ‘prototype’ something in Rails instead of whatever you’d build the ‘real thing’ in, and be open to being pleasently surprised how good a adaptable the prototype is into being said Real Thing…

  3. I might have a go with that this weekend then if I’ve got time.

    Good point about the prototyping. I was thinking that about Coldfusion (which we use for our intranet here) the other day in fact.

  4. I have little experience with Coldfusion – it has always seemed like a proprietary form of ASP to me, complete with same point in technology lifecycle.

  5. Don’t have any experience with ASP at all so don’t know how it compares. I do find it quicker than PHP for doing lots of stuff though, but the proprietary nature means I wouldn’t want to use it for anything that was going to be reused elsewhere.

blog comments powered by Disqus

Switch to our mobile site