New to Rails? Read This

Thanks for this post. I too am coming into this new (except for a heavy Java background) and the onyl thing I would add to your list is this newsgroup. My personal goal here is to keep learning, hopefully, be able to answer other people's questions on this newsgroup. -Janna B.

Testing Rails can be cumbersome but it's also very necessary. You can hand-test all your code and do the greatest job possible but in the end, it won't be enough. So, you should become familiar with a few testing platforms you can use with rails.

By default, whenever you create anything new with rails 2.3.2, test files are automatically created for you. These tests, called Unit Tests are the very barebones basic test platform you can use with Rails.


You can find information about Unit Tests here:

** RSPEC **

But, Unit Tests may not be enough for you and you will find that there are some more popular methods of testing available. One of the more common testing platforms is called Rspec.

Screencast tutorial from Ryan

The tutorial screencast is a little old but it gives you an idea of how to test with rspec..


A lot of people refer to autotest and autotest became Autospec. Autospec is very simple to use (it's also referred to as ZenTest, because of the gem name). You can also use Autospec with Rspec to add a more complete testing platform for rails:


Another new kid on the block is Shoulda. It is actually a very interesting testing platform and it might not be as famous as RSpec but it's really easy to use and I'm starting to lean towards using shoulda over rspec, personally. However, go with what platform you feel is best for "YOU"... Companies like yours create meaningful solutions with thoughtbot?


So yes, it's important to write your topic with something specific and interesting so that the experts want to read and help. But with some luck, you'll still get views with a poorly written topic. There's a better (in my opinion) reason to be specific -- to help the people who have the same issue tomorrow. I try to write a topic such that if it had already existed (started by someone else last year, for example) my google searches would have revealed this based on title alone. In light of that, something along the lines of "How can I make Model.find use a SQL WHERE clause?" is even better than "Need assistance with model/query issue" (possibly you agree and were just trying to keep the example generic).

Sometimes if I'm not familiar with terminology I'm tempted to be vague, but think of it this way: if I'm specific and inaccurate, hopefully someone corrects me. Maybe my problem is well understood, and I just didn't know how to search for it. The next person who is equally confused benefits from my specific topic title.

Example of a bad topic thread:

"I'm having trouble, please help"

-- this doesn't describe anything and your topic might be avoided.

Example of a good topic thread:

"Need assistance with model/query issue"

-- this describes the problem as being related to models/queries.

This is a great thread, by the way! I've been using primarily: Programming Ruby: The Pragmatic Programmer's Guide for a solid understanding of the language, Agile Web Development with Rails, and the guides at I'll try out some of your other suggestions tonight. Found anything good on Rails + Ajax yet? I can't decide whether to order Scott Raymond's book or not since the abstract seems to indicate I can learn the same things reading reference material.

Don't forget the official Rails Wiki - Lots of good info there.

Found anything good on Rails + Ajax yet? I can't decide whether to order Scott Raymond's book or not since the abstract seems to indicate I can learn the same things reading reference material.

Well, I'm really glad you asked this particular question. I'm still going through a ton of resources on ajax/rails.

So, what I find wonderful about rails is that rails + ajax is like having a perfect marriage. They work so well with each other, it's wonderful to implement both in a project. By default, rails uses prototype and scriptaculous but I'm looking into jQuery at the moment.

jQuery seems to be really solid.

Here's a link which will "create" an up-to-date trend chart when you click on it using google trends:

jQuery Prototype Scriptaculous Mootools Dojo

You also have jMaki but that uses jQuery, but jMaki also has great support in certain IDE environments like netbeans. But, IDEs are another subject altogether.

If you notice by the trends chart, jQuery is heavily on the rise.

To add another book to the three initially mentioned ( which are all very good ! )

Ruby on Rails Bible ( released late last year ! )

cheers, Dave Porter

== Tutorial Injection #1 ==

Normally I would just pass some links but at times it's a little refreshing to add some very simple tutorials that many people ask about. This tutorial is about RESTful routing and mapping resources.

=== RESTful Routing and Mapping Resources (advanced) ===

By default, whenever you create a scaffold, 7 methods are automatically created for you. These are index, new, edit, show, update, create, and destroy.

In order to map all paths to these resources a simple map resources line is automatically created for you in your routes.rb file using the pluralized name of the controller.

E.g. scaffold name product produces a controller called products

map.resources :products

This one little line now maps all of your RESTful resources for this controller. However, what if you had something like this?

E.g. scaffold name users_allowed produces a controller called users_alloweds

Now you wouldn't want people to see would you? That would look very strange or peculiar. So, you can do something as simple as this:

map.resources :users_alloweds, :as => 'users_allowed'

Now your url will look like which is a little better.

But, what if you want to group certain resources by a particular category. Say for instance you want to group this particular url in a category called members. Well, you can use a nifty prefix command:

map.resources :users_alloweds, :as => 'users_allowed', :path_prefix => 'members'

Now your url will look like which gives you a nice category grouping and a singular path name.

And, lastly, for this very simple tutorial, what if you wanted to take this further and just allow only the index method/view to be accessed and the rest of the resources not. A simple way:

map.resources :users_alloweds, :as => 'users_allowed', :only => 'index', :path_prefix => 'members'

(acceptable) (not allowed)

And, correcting my own self,..

It might be better to say that Rails is a "framework".. :slight_smile:

.. or more precisely, a web application framework..

Ruby = language Rails = framework

===== GitHub =====

Github is a great place to host your project(s) while you develop.

You can get a free subscription but your projects will be public and open source (viewable to everyone) or you can get a paid subscription (costs very little) and have a large storage area, multiple repositories and you can keep your work private.

Github can be used to commit/add new changes while you work on your project, much like subversion. This allows you to track changes and because it's hosted online, you can add authors and other members to work on projects with you, if desired.

Github, along with Capistrano, can be used to help you with migrations and updates from development to production phases. Develop on your own machine, commit changes to Github and further commit changes to your server. It's seamless and once working, very smooth and efficient.

The only drawback is there is a bit of a learning curve with Github and if you develop on windows, an even bigger learning curve exists. Check out the guides for more information.

----- Building a Repository and Uploading Your Project ----- 1. Signup and register your account in Github 2. Download/install the latest Git release ----- For windows this is 2a. See the guides section if you use linux or mac. 3. Configure your SSH key for git by opening git bash and typing:     ssh-keygen -C "" -t rsa 4. Configure your profile by typing:     git config --global "Your Name"     git config --global 5. Make your rails project directory or go to an existing rails project. 6. Right-click (if windows) and Git Bash Here. 7. Type "git init" to configure git inside your project directory. 8. Type "touch README" and enter. 9. Type "git add README" and enter. 10. Type "git commit -m 'first commit'" and enter 11. Type the following command to set your origin:     git remote add origin 12. Type "git push origin master" to push the readme file to your repository.

----- Updating any new changes -----

This is where at times it can get confusing. Several times you might encounter errors when trying to push to origin. Here's a pretty fail safe way of doing it. If anyone else would like to add to this or change it, please feel free.

1. Modify your rails project, add new code, etc. 2. git bash here at your project directory. 3. Type "git pull origin master" and enter. 4. Type "git add . " and enter.     (yes that is a period) 5. Type "git commit -m 'some message describing your changes' and enter. 6. Type "git push origin master" and enter.

Perhaps worth mentioning what git is: a distributed version control
system. So, independent of github, software version control is an
important practice.

9 Resources for New Ruby on Rails Developers:

Cheers, Sazima

Sazima wrote:

9 Resources for New Ruby on Rails Developers:

Cheers, Sazima

Nice - bookmarked.

Älphä Blüë wrote:

================================================== Ruby Platforms, Rails Versions, and Other Notables

Ruby/Rails platform upgrades:

1. Download and Install your Ruby version upgrade for non-production purposes only. 2. Optionally install any relevant gems or write a Ruby/Bash script to switch between the different implemented platforms. 3. Read the README file and execute any tests of the gem(s) you need for your Rails application against any of the relevant Ruby implementations. 4. Test against the new implementations. 5. You now have a test harnass in place for your rails application.

Or adopt some sort of virtualization technology, like VMware.

I run an Ubuntu virtual machine for my Rails development. When it was time to test out migrating Ruby and Rails to newer versions, I cloned the existing VM, and upgraded the clone, then pulled in the application from the source repository. Parallel environments with few headaches, and allows straight up comparative testing.

I, too, have moved to running Windows VMs inside VMware on Ubuntu. Works like a champ, but if VMware is not in your budget, Before that, I used InstantRails for the same purpose. Same results.


Marnen Laibow-Koser wrote:

Um, WTF? That's where logic is supposed to go. Exception handling supplements that logic; it doesn't replace it. There are times when it might be necessary (methods that

involve rake tasks etc. come to mind) but overall, rescue is something everyone new to rails should learn and implement into their apps.

I didn't use the right wording here. What I meant was there are different types of logic to use with your model. In otherwords, for every method created there are probably 3 people that will do them completely different but achieve the same result.

Remember for loops? Which logic is better to do in the model? A for loop or an each loop? Which is better practice? This is what I was after. You can go to an extreme on one thing and never use the simpler approaches.

Many developers (including me!) perhaps don't use exceptions quite as often as they should, but I am afraid that you are encouraging the opposite extreme -- a style of programming where exceptions are used for everything. I understand that this is not a great idea for a number of reasons: it is said to be inefficient and hard to follow and test.

I'm not sure I follow you completely on this particular response. Are you saying that rescue is a bad thing when you need a routine to continue moving forward? Or, are you saying that there's another way (besides rescue) that should be used to do the same thing? I like rescue. I don't use it for everything but there are some core areas in my app that I do use it.

I bring a fair amount of dated knowledge to this -- the "why not use exception handling for everything" answers from the days of C++ and the like. I learned to steer clear of exception handling in cases where I could fairly predict an outcome.

Ruby may have a slick implementation of exception handling and certainly does not have the baggage of unwinding through destructors that C++ had, but an exception is a non-local jump, not to be confused with scope exit caused by a flow of control structure. That means someplace things like multiple scopes need to be recognized so stale objects can be marked for garbage collection, etc. Additionally, in the presence of a begin/rescue block, when an exception occurs, the interpreter has to look for the closest scoped exception handling block that declares itself as handling the specific type or generic superset of the exception in question. This means maintaining an ordered searchable list of these scoped blocks, thus taking up memory for a case which is supposed to never happen, right?

So here's my way of deciding whether to use exceptions. I ask the questions:

"Is the result of this operation predictable?" If yes, then I test for it, and don't use exceptions.

"If this operation fails, is there anything I can do about it?" If the answer is no, then I let Rails' rescue_action_in_public take care of things for me and get my exception_notification email. Then I fix the bug.

"If this operation fails and there is it important and something I can fix programatically (e.g., would financial data be corrupted or something equally disasterous and will I have information to mitigate the damage)?" If the answer is yes, then I'll use a begin/rescue block.

All of this said, there is a reason exception handling is in the language, but it's not (IMO) the one you cite. Exception handling is made to wrap very important operations that simply can't fail without at least an honest retry strategy. You know, like "user stepped on anti-lock brake pedal and braking computer raised an exception." What exceptions were not specifically designed for was to facilitate non-local jumps out of scope.

I know there will be disagreement on what I've said here, so I must re-emphasize that my habits with respect to use of exception handling are based on avoidance rooted in a pretty dated technology, C++. Additionally, this is something of a religious issue, where you either hate exceptions to the extreme or see no harm in them and use them liberally. I've put my opinion out here in hopes it will be useful.