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.