Flash assets like an FLV­Play­back skin will typ­i­cally be located in your pub­lic folder. How­ever, accord­ing to http://kb2.adobe.com/cps/608/608abffd.html, “in a load­ing sce­nario, the skin SWF for the FLV­Play­back com­po­nent must be rel­a­tive to the load­ing HTML file con­tain­ing the par­ent SWF on the server, not to the loca­tion of the loaded SWF.” This is bad, since when you load a page, the URL will typ­i­cally be /:controller/:action, which means the FLV­Play­back skin URL will be /:controller/myskin.swf even if your par­ent SWF is in /public. You can ver­ify this in Fire­bug on the Net tab. The prob­lem will man­i­fest itself with a loaded Flash movie with no con­trols. You can fix this by cre­at­ing a rewrite rule in your .htac­cess file.

RewriteRule ^.*/myskin.swf$ /pathto/myskin.swf

Any request end­ing in myskin.swf will be redi­rected to /pathto/myskin.swf under the pub­lic folder.

So I had to move an appli­ca­tion that I’m devel­op­ing from a Medi­aTem­ple (dv) Dedicated-Virtual to a Ruby on Rails Grid­Con­tainer run­ning on a Medi­aTem­ple (gs) Grid-Service. Most of the tuto­ri­als I found that cov­ered installing a Rails app on a Grid­Con­tainer were some­what dated. Things that were dif­fer­ent than expected include:

1. Rails, a few pre­com­piled gems (like RMag­ick), and a test app are auto­mat­i­cally installed for you. Most of the tuto­ri­als walk you through installing Rails and the skele­ton app from SSH. That’s no longer necessary.
2. For Capis­trano, you need to set the syspath option (“Sys­tem” in the con­trol panel) to /home/[xxxxx]/containers/rails/[app_path]/current where [xxxxx] is your Grid­Con­tainer num­ber and [app_path] is where you want your app located. I kept the app path and app name the same.
3. You can’t edit appli­ca­tion options from the web con­trol panel. You have to do this from a SSH ses­sion using mtr set_option. You may need to do this to change the syspath or to set the environment. For exam­ple, to set the envi­ron­ment to “stag­ing” you use the fol­low­ing com­mand: mtr set_option [app_name] environment=staging.
4. If you change the syspath make sure to update the sym­bolic link to the app’s pub­lic folder under your app’s domain, oth­er­wise you’ll get an app not found error. In other words, ~/domains/example.com/html should point to /home/[xxxxx]/containers/rails/[app_path]/current/public.
5. When an appli­ca­tion fails to start, you get no feed­back about the cause. Check log/mongrel.log for details as to why your appli­ca­tion fails to start.
6. After chang­ing the syspath, the app may not restart. You may get an Address already in use - bind(2) (Errno::EADDRINUSE). To resolve this, I ended up hav­ing to reboot the container.
7. For some rea­son, rake gems:install didn’t work. I had to man­u­ally install each gem.

I def­i­nitely had a lot more con­trol over the instal­la­tion when I had the appli­ca­tion run­ning on the (dv) using Pas­sen­ger Phu­sion, espe­cially hav­ing the abil­ity to com­pile soft­ware. How­ever, the Grid­Con­tainer runs a lot faster.

After many false starts, I decided that I really needed to wrap my head around unit test­ing when writ­ing Rails appli­ca­tions. I more or less com­pleted a Rails 1.2.3 appli­ca­tion with­out any for­mal tests, and I would like to upgrade it to 2.0.2 and make it REST­ful in the process. At the same time, I’ve moved from a Win­dows devel­op­ment envi­ron­ment to a *nix one after installing Xubuntu on my lap­top (an old Com­paq Pre­sario). I’ve also switched from Cream to Emacs. Despite my Win­dows desk­top being more than twice as fast as my lap­top, I just could not stand not being in a true *nix envi­ron­ment. Too much of the Win­dows idio­syn­crasies got on my nerves. And my switch from Cream to Emacs was because I just didn’t like the insta­bil­ity of the hacks required to make Vim less of a modal edi­tor. If I tire of Emacs, I may try pure Vim instead, but I remem­ber installing Cream sim­ply because I didn’t like pure Vim to start with. So with these var­i­ous changes going on with my Rails pro­gram­ming envi­ron­ment, I fig­ured it was an ideal time to learn to for­mally test my appli­ca­tions. Of course the first part is set­ting up the test­ing envi­ron­ment so that it is easy to use, stays out of your way, and is informative.

(more…)

Inspired by a cou­ple of arti­cles and even a screen­cast, I wrote a short batch file that cre­ates a Rails appli­ca­tion and auto­mat­i­cally loads it into a sub­ver­sion repos­i­tory. It works by first cre­at­ing a temp folder, gen­er­at­ing the rails app there, renam­ing the app folder to trunk, cre­at­ing the accom­pa­ny­ing branches and tags folder, and then deleting/renaming a bunch of non-essential files. Once that’s done it imports the three fold­ers into a spec­i­fied sub­ver­sion repos­i­tory. Once the import is com­plete, the temp folder is deleted and then the trunk is checked out. Finally it cleans-up by copy­ing the database.yml file and ignor­ing the tmp and log fold­ers. That’s it.

(more…)