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.

** UNIT TESTS **

You can find information about Unit Tests here:

http://guides.rubyonrails.org/testing.html

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

http://wiki.github.com/dchelimsky/rspec

Screencast tutorial from Ryan
http://railscasts.com/episodes/71-testing-controllers-with-rspec

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

** AUTOSPEC **

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:

http://ph7spot.com/articles/getting_started_with_autotest

http://www.nateclark.com/articles/2008/09/17/autotest-is-now-autospec-how-to-set-up-autospec-for-rspec-and-rails-with-zentest

** SHOULDA **

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

http://wiki.github.com/thoughtbot/shoulda/rails
http://wiki.rubyonrails.org/testing/shoulda
http://thoughtbot.com/projects/shoulda/tutorial?

Enjoy!

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 rubyonrails.org. 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
script.aculo.us reference material.

Don't forget the official Rails Wiki - http://wiki.rubyonrails.org.
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
script.aculo.us 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:

http://www.google.com/trends?q=jQuery%2CPrototype+ajax%2Cscriptaculous%2Cmootools%2Cdojo&ctab=0&geo=all&date=all&sort=0

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 ! )
http://www.amazon.com/Ruby-Rails-Bible-Timothy-Fisher/dp/0470258225
http://www.rubyonrailsbible.com/

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 http://yourdomain.com/users_alloweds
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 http://yourdomain.com/users_allowed 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 http://yourdomain.com/members/users_allowed
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) http://yourdomain.com/members/users_allowed/
(not allowed) http://yourdomain.com/members/users_allowed/*anything

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 =====
http://github.com
http://github.com/guides/home

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
http://code.google.com/p/msysgit/downloads/list
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 "your@email.com" -t rsa
4. Configure your profile by typing:
    git config --global user.name "Your Name"
    git config --global user.email Youremail@domain.com
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 git@github.com:username/YourProjectName.git
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:

http://charlesmaxwood.com/9-resources-for-new-ruby-on-rails-developers/

Cheers, Sazima

Sazima wrote:

9 Resources for New Ruby on Rails Developers:

http://charlesmaxwood.com/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.

Hello--

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.