The Joy of Rails
I wrote this list/post as I worked through Rails 3 as a newbee (not new to systems, development – just new to Rails 3.) I am working through The Ruby on Rails 3 Tutorial and touching on issues/resolutions as I encounter them. Note that as a Newbee my comments/solutions may not reflect ‘the Rails Way’ of doing things; also note that any solutions that I present may or may not work for you (best I can tell this is simply part of the Joy of Rails…) 
Consider some sort of Development User Sandbox
Sand-boxing development environments (isolating non-production code) is hopefully familiar/common to you. Sand-boxing your user accounts may be less familiar but it may provide you similar isolation from ‘bad things’…
If you plan on using Online services for serving/storing data/apps etc. then here are a few items that most online tutorials don’t tell you about but they are simple things that you should consider:
- create unique user_accounts on your local Linux Server specifically when using any online account/service where ‘keys’ are shared between two or more systems, especially for ‘test’/'trial’ services – i.e. at this time I have one GitHub account with two ‘users’ from my Linux system.
- use unique emails (aliases are fine) for each such account – I have been using email aliases for years – when you are done with the alias you can safely delete it since you only use it for one thing; if you start getting SPAM to any email address you can easily change it without affecting your ‘normal’ email address that you use for sending messages.
- use unique ssh keys if any are required – i.e. as noted above I use two local Linux accounts with unique SSH keys to work with GitHub projects; when I am working on a particular project I either login to the needed account on the local system OR I use ‘su – Account_name’ (the ‘-’ is required for this type of use) to ‘become’ the user. While it is possible to use multiple keys with one user account I find that it is simpler to create unique users with unique keys.)
While using the above approach adds some potential complexity it may help insulate you from future issues. If you are using a Linux/*nix type operating system then you could simply create a dedicated user for use with Open Source type projects (where you expose your information on a global scale.) After creating the user on your local machine simply login to the account using your GUI login process. Opening a terminal using your ‘normal’ login and then using sudo/su is possible but can lead to gotchas like:
- login as normal user using the GUI
- start a terminal session
- use su/sudo to change to a new user_account in the terminal session (i.e. su – dev_user)
- if you now try to start a GUI process it *should* fail unless you have configured your GUI to allow direct access via a second user account (probably a very, very bad idea…)
A Sandbox Virtual Machine – A simpler approach (provided you have adequate hardware)
- login as normal user using the GUI
- create a dedicated Virtual Machine with a dedicated development user account and all development software/tools installed (with or without GUI support)
- start the VM and login as the dedicated development user
- limit ‘public projects’ to this dedicated VM
In the book Ruby on Rails Tutorial: Learn Rails by Example Michael Hartl he writes: “Also beware that lots of little things can go wrong….”, and a few sentences later on the same page, “When things like this happen to you, it’s always frustrating, but at least you know that it happens to everyone…“ [ Note that I purchased both the book and video combo product and liked them enough to become an 'affiliate' so clicking the link above AND purchasing help support this site - of course you could also hit the donate button...:) ] BTW – if you are using the book/videos then you need to review the updates on the site – Chapter 13 covers Rails 3.1 and notes many of the items in this post (and possibly more.)
Rails Touts ‘Test Driven Development‘
Where is the Test Driven Install?
Start with a ‘clean install’
- to avoid system-level trouble shooting don’t use a ‘system install’; instead install Rails and related tools as a specific user (while I prefer a ‘system’ install, and that is what I am using, I will guess that you may have fewer ‘version’ related issues if you install as a specific user, especially if you are the only user on the machine…)
- use rvm – Rails Version Manager – it can help limit the version-type problems that you will encounter (this tool should or something similar should be part of the Rails base install.)
- consider using a virtual machine just for Rails development (requires a PC/system with adequate computing resources; provides another layer of isolation.)
- realize that if you use the default ‘settings’ for Rails 3 then EVERY new project will download the latest code from the Internet – this may not be the best approach for real projects… (do you really want to add more potential issues with ‘new code’ in your project?)
- start with simple projects.
I don’t want to re-install!
- then expect to spend excessive amounts of fruitless effort searching for a solution (the most likely outcome.) [I note that the 're-install fix' is currently the standard approach for highly complex systems, i.e. any recent version of the Windows operating system - it is simply faster to start over than it is to figure out what is 'wrong' and resolve...] Search engines will most likely provide many ‘hits’ for your error message and few, if any of those ‘hits’ will contain a real solution/explanation – they may contain work-arounds that worked-for-the-poster who is using OS Version YadaYada with Rails Version XYZ; my experience is that such work-arounds lead to additional issues or the time spent trying them is simply wasted time.
- re-install… If that does not ‘fix’ the issue then you will have to dive into the cycle:
- search engines – hoping for an ‘exact match’ WITH a solution…
- Rails specific forums
- Rails specific mailing lists
- your Rails ‘network’
- Rails books – normally at least a little out-dated within months of being published…
Common Resources for Rails Development
- git – source code version control; ‘git’ creates a hidden project sub-folder where all of your changes are stored – best if you combine this with some sort of replication to either a local or remote server (i.e. GitHub.Com)
- github.com – online repository for ‘git managed’ code with ‘free’ storage for Open Source projects
- Heroku - almost instant ‘publishing’ for your application; great for testing using a ‘free’ account
- “Blueprint is a CSS framework, which aims to cut down on your development time. It gives you a solid foundation to build your project on top of, with an easy-to-use grid, sensible typography, useful plugins, and even a stylesheet for printing.“
Ok, you create an account with Heroku, upload and successfully run a few applications and then with your next test application you hit a Heroku 500 Response code:
We’re sorry, but something went wrong.
We’ve been notified about this issue and we’ll take a look at it shortly.
This could be your code or it could be the Heroku Server. (I noted that no one contacted me about this issue so the error message is generic and Heroku could save YOU some time by improving it… Sounds like the price of free…) You can query your Heroku Application logs:
>>heroku logs
2011-11-25T00:02:32+00:00 heroku[router]: GET YOUR_Application_URI.heroku.com/ dyno=web.1 queue=0 wait=0ms service=599ms status=500 bytes=728
When I experienced this I deleted the Heroku App with:
- heroku destroy # you will be prompted to confirm; then re-create with
- heroku create # you should get a new application
- git push heroku master # now upload
- heroku rake db:migrate ## Still getting the 500 error – oops maybe a ‘data issue’?
heroku rake db:migrate
rake aborted!
Please install the postgresql adapter: `gem install activerecord-postgresql-adapter` (pg is not part of the bundle. Add it to Gemfile.)
Tasks: TOP => db:migrate => db:load_config
Actually, this is a Heroku ‘confinment’ – Postgres is required – The Fix:
- install Postgres on your system as a native application (non Ruby/Rails system level binary)
- install the ‘pg’ gem
- make these changes to your Gemfile (for the app being deployed via Heroku; note that Heroku strongly encourages the use of Postgres in both development and ‘production’ to avoid these types of issues…) In your project ‘Gemfile’, make sure to ‘comment out’ any existing lines for ‘sqlite3′…
###############################
## from Heroku docs - use 'postgres' for production/sqlite for dev
group :production do
gem 'pg'
end
group :development, :test do
gem 'sqlite3'
end
###############################
- bundle install # make sure that all is up to date
- rake db:migrate # make sure that your DB is updated
- heroku rake db:migrate # send the changes to Heroku
- try your app now (worked for me)
Using ‘git’
Mr. Hartl’s book/screenscasts frequently use ‘git’ to manage the code. If you are new to ‘git’ and if you are using his book I suggest naming ‘git commits’ with extended comments that include book chapter numbers, i.e.:
- rails new new_project # create a new Rails 3 project
- cd new_project # move into the new folder
- git init # initialize the folder for use with ‘git’
- vi Readme.markdown # create a project description file using your editor of choice (using ‘vi’ in this example)
- git status # git should report that there is a new file
- git add . # add your changes to the git repo
- git commit -am “Starting Chapter 1 – created project Readme” # ‘commit’ your changes with an enhanced comment
- git add . # update the git repo as desired as you work through the chapter
- git commit -am “Chapter 1 – section on some_new_topic” # make sense?
- git add . # update the git repo as desired as you work through the chapter
- git commit -am “Completed Chapter 1″ # Completed this chapter
- git commit -am “Starting Chapter N “
- git commit -am “Completed Chapter N” # make sense?
Extended ‘commit comments’ may make it easier when reviewing the project or if you want to ‘rollback’ and re-do a section of the tutorial. Based on my experience a reasonable approach for working through the tutorial code might be to simply ‘checkout chapters’ as you move along OR checkout the entire project and then ‘rollback’ to the point that you want to work. During my exploration I frequently created my own issues (via fat-fingers, whoops! moments, missed ‘step #nnn”, etc.) and found that my version of the app did not work due to my new-bee-ness (well, that’s my excuse..) Soooo, the short story for this is that I will create another post detailing using git with a ‘test project’ in this fashion.
Additional Resources
- Markdown – text based documentation with minimal ‘tags’ for presentation management – used by GitHub
- Pandoc – an exceptional tool for converting between mark-up formats (HTML 2 Markdown)
- Ruby Regular Expression editor/test site – test, experiment, explore, create regular expressions for use in your Ruby Code; also a great way to simply learn about using Regex.
As Ruby on Rails & it’s components Transition you will most likely encounter errors like:
Warnings about deprecations – I am guessing that it is most likely you will see this from ‘generated’ code and it will continue until the ‘code generator’ is updated with the new whatever_was_deprecated OR, until the code simply no longer works and your application will (most likely) ‘break’… It may also occur from ‘gems’ that need to be updated.
sample_app_3_1 (master)]$ rspec spec/
DEPRECATION WARNING: ActiveRecord::Associations::AssociationCollection is deprecated! Use ActiveRecord::Associations::CollectionProxy instead. (called from <top (required)> at /usr/local/Tutorial/sample_app_3_1/config/environment.rb:5)
….
Finished in 0.49615 seconds
4 examples, 0 failures
In this case I quickly found a simple solution – which I try and it appears to ‘solve’ the warning problem. After changing the Gemfile I ran bundle install but no changes seem to occur (which probably means that the needed gem is already installed.)
StyleSheets & Images not working with Rails 3.x?
In the 3.1 release of Rails (So, for a small version change a ‘standard’ item has just bee relocated?) it appears that stylesheets should be placed in:
- app/assets/stylesheets (instead of)
- public/stylesheets
- likewise ‘images’ has been moved to app/assets/images
Check the source for the application web page – it will show you where the stylesheet is being pulled from…
Getting many errors when you try to use Annotate? Try:
- gem ‘annotate’, ’2.4.1.beta1′ ## update Gemfile, run ‘bundle install’
- bundle exec annotate ## may be required for command line use
While working on the tutorial I also worked on some related posts:
Setting Up Local Resources – possible future posts…
- using Apache to run/test applications
- setting up a local Git repository
- setting up a local Phusion (Heroku type ‘service’, AKA mod_rails/mod_rack/mod_passenger)
As always, I expect that your experiences will vary a bit (along with your opinions) – which is as it should be.
