What I learned in the process of its deployment was particularly interesting. There was a huge disparity in understanding between roles - the role of myself, these people we pay to host the site, and this sysadmin who we just spontaneously hired. The sysadmin, who was solely a consultant, didn't know about the background of the old site's setup any more than I did. (Both of us knew nothing about the old site.) And I thought all I had to do was develop the code and then just pass it off to someone who would then set it up. It turned out that I had to actively engage in some parts of the deployment too... like setting up capistrano (http://help.github.com/capistrano/) and sshing and public key stuff and ladeedah.
I guess the experience was quite the eye-opener...
Bottom line: If you're a Rails developer, or perhaps any developer, it's really important to have a clear understanding of what is expected of your developed application on the production end of things. Don't just assume you can make the app and hand it off to someone who'll set it all up for you.
(...now that might come off as a rather obvious bottom line but hey it's important...)
Now, one other point (which is more on the technical side): I encountered an encoding issue in the database transfer of the old site. Apparently, the database went from sqlite3 to mysql... UTF8 encoding wasn't used properly on the old site, so when the database transfer was made, the new site had odd things like...
- "| instead of :
- – instead of -
- ’ instead of '
- “ instead of "
- †instead of "
In my case, it wasn't difficult to manually go in and change things, but it's probably a good idea to take note of encoding before making any database transfer.
