Day of Ruby Bugs

Learned a lot today.

  • Created and deployed a migration
  • Created my desired JSON format
  • Updated rails on dev machine and server.
  • Configured’s rails server to talk to the PHP update server using JSON over REST

hit a lot of bugs too

  1. reload! doesn’t reload the console in 3.0.0 and 3.0.4
  2. as_json is not processed correctly in 3.0.0
  3. dump format :sql support is not really as seemless as it sounds

I used sudo gem update rails to update rails, and got an error needed to be worked around (by going to directory cd /Library/Ruby/Gems/1.8/gems/rails-3.0.4/ and creating the ‘lib’ directory). Probably better to use bundle update rails instead…

I learnt a bit about Ruby hashes (aka hash tables, dictionaries). Including that in the latest version of ruby, the hash-rocket syntax has been replaced with the much nicer colon.

Believe it or not, I had not added any class members before today, since rails does this for you from your DB schema.

Rails has some useful from_json and to_json functionality, but they assume model objects. If you just want to parse from JSON into a plain hash, you can use the JSON gem.  Yahoo has a decent example of making a HTTP call to a REST API in ruby, and the relevant API docs are useful too.

If you want to share code between controllers, helpers are not the way, as rails designates them for Views. You could create stock standard modules, but since everything inherits from ApplicationController, I think that’s not a bad place to put stuff.

Appending objects to arrays is easy, with the << operator.

Updating rails on the server is straight forward with capistrano, as long as you require "bundler/capistrano" in your deploy.rb. Simply:

#from the project directory...
bundle update rails
# now edit the projects Bundle file and update the referenced version of rails
bundle package # package up the updates for version control. ref:
git commit -a  # commit  the package
cap deploy # since you committed the bundle the gems will now be available on the server
cap deploy:migrate # if you have any db changes...

The jury’s out on our form views (which are very incomplete). But some tips are here, for future reference.

An interesting day of learning. Those API bugs stumped me for a bit – as being new to rails, I often first assume that the mistake is my own. But they are nothing in the face of just how powerful Rails is.  One great example is how capistrano behaved when I hadn’t done the bundle update and commit.  I was deploying to staging – so no worries even if it did break – but it basically realised that Rails 3.0.4 wasn’t available on the server (specifically, not available in my bundle – as bundled gems are no longer server-wide, which itself is awesome) and rolled back the deploy.  Given that my method of deploying PHP was (and still is) using FTP uploads… this level of automation and environment sanitiy checking is unreal.  In fact, the last PHP project I deployed was developed on a new version of PHP but running on a slightly older one (thanks to RHEL…). Rather than gracefully telling me that the environment wasn’t correct (as per rails with capistrano), I had to execute every line of code to see which ones failed…

Leave a Reply

Your email address will not be published. Required fields are marked *