Archive for March, 2009

I finally got around to down­load­ing the iPhone SDK to see what I can do with it. Since I’ve dab­bled in game devel­op­ment back when I worked with Flash and Direc­tor, I fig­ured I’d see what I can do with the iPhone. I wanted to start with a frame­work and I looked at Torque and Unity. Though inex­pen­sive by game engine stan­dards, dur­ing a reces­sion­ary time of cost cut­ting, it’s hard to val­i­date a nearly $1000 pur­chase, espe­cially if you don’t know yet if that invest­ment would pay off. So I finally set­tled on the cocos2d-iphone frame­work which is based on the cocos2d frame­work for Python. There is lit­tle to no doc­u­men­ta­tion, so be pre­pared to read source code. Mon­o­cle Studio’s whitepa­per will def­i­nitely help you boot­strap your project. In the spirit of that paper, I thought I’d share my trans­la­tion of the cocos2d “Hello, World” exam­ple adapted for the cocos2d-iphone framework.


Dru­pal has a Tax­on­omy mod­ule for cat­e­go­riz­ing con­tent. The mod­ule can gen­er­ate a select box based on the defined tax­on­omy. How­ever, it does not sup­port option groups. I fig­ured I’d share my mod­i­fi­ca­tion for those who’d like to do the same. It was based on code from a Dru­pal forum post which I think was based on Dru­pal 5, not 6.


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/ 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.