Hello, Ruby Wednesday

As a ruby hacker... This is not something that somebody can write an idiot-proof guide for. RoR is, as a platform, infinitely more flexible than Wordpress, and ruby hackers fucking love exploiting that flexibility. The database will need to be migrated, and migrated correctly in order to function. Dependencies and infrastructure services will need to be migrated. Because of this flexibility, I can't tell you what needs to be migrated. I mean, it probably needs the SQL database schema replicated across, the data repopulated, the HTTP server strategy migrated (with mongrel and nginx or whatever half-ass server they're using) or a new rack stack built, the ruby environment replicated, and the application code copied over. But, he could have chosen to use redis instead of SQL. Or he could be running in JRuby even, making the whole process totally different. You say you don't want to learn an entire language just to migrate a website. But, in the world of rails, that's pretty much necessary. We rubyists prefer to write *everything* in ruby. So, that Rakefile? That's ruby. The .ru (rackup) script? That's ruby. Config files? Probably ruby, but maybe YAML instead. And all of it is specialized into domain-specific languages. So, it'll share ruby syntax and semantics, but will have a whole bunch of pseudo-keywords defined by the tool in question (rake, for instance). This is the cat's pajamas if you're a ruby hacker. This is not so friendly if you don't want to learn the language. Even worse, depending on how much of a circlejerker the previous dev was, you may have to learn the language at a *deep level* in order to successfully diagnose errors arising from unfulfilled conditions in the new environment. This is because many rubyists are more in love with writing elegant "magic" than they are with writing readable code. Bugs can and will present themselves during migrations. You need to hire a professional. Somebody who knows what they're doing should be able to achieve this in a couple of days for a few hundred dollars. It's an easy job if you know enough to easily diagnose problems. It's going to be virtual hell if you have to google every error.

It actually wouldn't be an outrageous idea to go through a tutorial and set up a toy Rails app to get some of the ideas -- part of the point of Rails is that it makes the easy really, really easy and it's dominated by conventions that make it relatively easy to know where to look for things. You could do this in a couple of hours. Rakefiles are sort of like Makefiles -- they define lists of tasks and are invoked with the 'rake' command. You configure your database in config/database.yml, and then say 'rake db:migrate' and pouf -- your db exists with the up-to-date schema. Then manually with mysql or psql or whatever import the data. If you have the right version of all the ruby gems (and if you're lucky, the gems your app depends on were 'frozen' into the vendor directory before your zip file was made) then, yeah, once you set up the db, you have a shot at it just running. (But the real world usually isn't that simple.) Note that the Rails world is all-too-comfortable with backwards-incompatibility and Rails 2 apps can be expected to break in Rails 3. If you're lucky, your app specifies the exact version of things it depends on. If you're not lucky, you're in for some pain there.

Ohh boy, you're asking for a lot here. /app is where the webapp code goes. If your familiar with the MVC paradigm then /app/controlers, /app/models, and /app/views makes sense. There's also now /app/assets for stuff like JS and CSS that has bits of Ruby code in it and needs to be "compiled". /lib is where non webapp code, yet still app code, goes. For example, I've but in here code to clear out sessions and code to extend the system's net-ldap module. It's used by the webapp but not part of the webapp logic directly, if that makes sense. /config is where config goes (duh). You should have a /config/database.yml that tells the RoR app how to connect to the database. /Gemfile lists the apps external dependencies /Rakefile sets up tasks that run from the CLI. Like, create the database schema and upgrade/populate it. Ruby on Rails apps don't run in the webserver (Apache I'm assuming) like most apps you're familiar with. They're not PHP or Perl or CGI. What almost everyone does is run a seperate, Ruby based webserver through Mongrel or Unicorn on an internal port (127.0.0.1:3000 for example). Then configure the frontend webserver (Apache) to proxy all requests for Rails stuff to the backend server. Static files like JS and CSS are mapped into the Apache space and served directly by the frontend. This is very much like common configurations for Tomcat and Java Servlet containers. All in all, if you got lost then I think you need to hire someone to help you move this to a new service. It's much more complicated than a collection of PHP files or Perl scripts.

Hrm, I was afraid of something like that. I doubt I'll be able to convince the bosspeople to shell out money to hire a contractor... Think I'll just pitch to speed up launching the new site in lieu of moving the old one. Thanks for taking the time to explain the reasoning to me, everyone. And thanks for all the linked resources!