New to Rails? Read This
Älphä Blüë
about 6 weeks. I've read 3 rails books, performed thousands of google
searches, saved everything important to my current work scope, and want
to make it easier for those that come after me.
If you are reading this then you probably already realize that it's
sometimes difficult to find information on certain topics. To make it
easier to find things you need, please look below:
**========= Direct Tutorials/Walkthroughs ==========**
http://www.buildingwebapps.com/learningrails
Summary: This is one of the best learning rails sites I've come across.
Everything works with Rails 2.3.2 and both persons that teach on this
site are very experienced with rails. I can personally attest to
Christopher Haupt who has on numerous occassions, personally answered my
emails to assist me with questions. The entire site is free and will
walk you through creating a custom content management system from start
to finish.
In addition, it goes through a lot of core foundations and these guys
are really good at explaning things.
**========== SCREENCASTS ==========**
http://railscasts.com/episodes/archive
Summary: This is the home of Ryan Bates, a very masterful rails
programmer that has created an extremely large archive of screencasts
(all free) that take you through many core rails fundamentals (basic and
advanced).
Ryan is a great all around guy and will teach you things you never
thought possible.
**========== GUIDES ==========**
http://guides.rubyonrails.org/
Summary: The often unnoticed guides are the ones perhaps the easiest to
find, but people tend to miss them. The guides listed at
rubyonrails.org are very informative and will teach you many nuances of
rails.
Summary: Another really good guides site is fortytwo. They house many
informative articles and tips for rails that will help you when you feel
a bit lost.
**========== DATABASE ==========**
http://databases.about.com/lr/database_normalization/24903/1/
Summary: Many people, including myself, forget to normalize their rails
databases. Because rails works with a lot of associations, it is very
important to first make sure your databases are normalized. Most people
will agree that if you want to use relationships like HABTM, you need to
normalize to a minimum of 3NF (3rd Normal Form).
This site will showcase exactly how to normalize your database and is
fairly easy to follow.
**========== BOOKS ==========**
Agile Web Development with Rails 3nd Edition Beta
Foundation Rails 2
Enterprise Rails
Summary: A lot of books are either out of date, or no longer workable
with Rails 2.3.2. These books still are effective learning tools.
Foundation Rails 2 teaches you things in order of importance. Agile Web
is a very good read. Enterprise Rails is important because it gives you
the database/model associations and how to use them effectively in your
projects.
======================================
If anyone wants to add important links, tips, or other comments that
might help someone new to Rails, please do so here.
Thanks.
--
Posted via http://www.ruby-forum.com/.
JannaB
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.
Älphä Blüë
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
** 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!
Marnen Laibow-Koser
[...]
> ** 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).
Almost. AFAIK, autotest used to work with both Rails' built-in tests
and RSpec, but at some point the script was split. So now you use
autospec for RSpec and autotest otherwise.
Autospec and autotest are part of the ZenTest package, but ZenTest is
more than just those scripts: it contains the logic necessary for
autotest to do incremental testing. So it's a bit of an
oversimplification to say that autospec is referred to as 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.
I've noticed a lot of people going this way. Why? What are Shoulda's
advantages over RSpec?
I like what you're doing with this thread, BTW!
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
Älphä Blüë
> and RSpec, but at some point the script was split. So now you use
> autospec for RSpec and autotest otherwise.
>
> Autospec and autotest are part of the ZenTest package, but ZenTest is
> more than just those scripts: it contains the logic necessary for
> autotest to do incremental testing. So it's a bit of an
> oversimplification to say that autospec is referred to as ZenTest.
>
Thanks for the reply Marnen - great to see the differences between those
two. I personally did not realize this.
>> ** 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.
>
> I've noticed a lot of people going this way. Why? What are Shoulda's
> advantages over RSpec?
I'll set aside some links that would do a better job at explaning the
pros/cons or the opinionated versus arguments between the two. Please
note that I like Rspec and I also like Shoulda. I haven't gained enough
knowledge of both to reply with my own opinions unfortunately. My
attempt was to bring more of an awareness to the different testing
platforms out there and allow others to make their own educated guess as
to which one works well for them.
Rspec vs. Shoulda
http://kylebanker.com/blog/2008/08/from-rspec-to-shoulda/
http://www.vimeo.com/3296561
Älphä Blüë
are Subject Matter Experts and every language or platform discussion
groups have them. These are generally people that have a great deal of
experience and house a wealth of knowledge that they share with others
in the community.
There are numerous SMEs that assist with answering questions by the
minute and it would do well to thank them and be appreciative of their
help.
However, how do you communicate your topic and readily obtain answers
from different SMEs?
======================
**-------**: Rule One:
======================
Make certain that your topic is descriptive enough to highlight your
issue. Having trouble with queries or models - simply say so.
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.
======================
**-------**: Rule Two:
======================
Make certain that your topic contains all of the pertinent information
surrounding your issue. More information is always better than less
information.
If you were having a model/query issue you would want to post a general
idea of what both your controller method initiating the query looks
like, and the model method being called looks like. You would also want
to make sure you tested that query in a console so you could see what
the output is. Supplying these three things would make it much easier
for someone to assist with a model/query issue for instance.
========================
**-------**: Rule Three:
========================
Always make sure you try the simple things first before posting on an
issue. A lot of issues stem from a simple restart of a server because
some changes never took effect.
Make sure your syntax looks appropriate in the editor you are using.
Make sure you at the very minimum try to test or debug the code in the
console. Doing this will make it easier when adding information to your
topic.
=========================
Lastly,
Thank the people that helped you resolve your issue. Patience,
understanding, reflection on the way a person helps you and your end
response goes a long way. These SMEs are giving their own volunteer
time and knowledge to help you. Make sure you show them the respect
they deserve.
==================================================
Channels and Communication Forums / MIRC:
==================================================
http://www.ruby-forum.com
http://railsforum.com
Start here to choose the forum that best describes your needs. Ruby on
Rails is my choice each and every day.
Mirc Channels:
Ruby Language: #ruby-lang on the irc.freenode.net server
Ruby on Rails: #rubyonrails on the irc.freenode.net server
There are a lot of people on the ruby on rails channel. There are a
great many SMEs there that assist by the second. Please be patient when
asking for help on IRC.
If you need help with IRC chat and you need some code looked at, make
sure you go to Pastie.org before asking for help:
You can put all of your code that needs help with on here and it will
give you a nice neat link. You can link that into IRC chat and anyone
can see the code and assist you. It's also properly formatted
automatically for you!
Marnen Laibow-Koser
thread as useful as possible...
Älphä Blüë wrote:
[...]
>
> There are numerous SMEs that assist with answering questions by the
> minute and it would do well to thank them and be appreciative of their
> help.
Indeed. (I think Frederick Cheung may very well be superhuman...)
>
> However, how do you communicate your topic and readily obtain answers
> from different SMEs?
>
> ======================
> **-------**: Rule One:
> ======================
>
> Make certain that your topic is descriptive enough to highlight your
> issue. Having trouble with queries or models - simply say so.
>
> 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"
Thank you, thank you, thank you! I recently saw a subject line that was
something like "Rails problem" -- which, when you think about it,
probably describes 2/3 of the posts on this list, so it's not terribly
helpful. :)
I *do* think that your "good" subject could be made even a bit more
specific, but it's a great place to start.
[...]
> ==================================================
> Channels and Communication Forums / MIRC:
The chat medium is called IRC. mIRC is the name of one client program.
[...]
> If you need help with IRC chat and you need some code looked at, make
> sure you go to Pastie.org before asking for help:
>
> http://pastie.org/
Great idea -- although Gist ( http://gist.github.com ) might be even
better than Pastie.
Again, thanks for taking the time to write all this!
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
Brian
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.
On Jul 13, 10:17 am, "Älphä Blüë" <rails-mailing-l...@andreas-s.net>
wrote:
>
> "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.
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.
John Yerhot
Älphä Blüë
> 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:
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.
Dave Porter
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
On Jul 14, 4:44 am, "Älphä Blüë" <rails-mailing-l...@andreas-s.net>
wrote:
> > 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:
>
Älphä Blüë
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
====================================
If you need to understand more about routing, please visit:
http://guides.rubyonrails.org/routing.html
Älphä Blüë
Perhaps I neglected to open with a proper introduction to Ruby and Ruby
on Rails. Therefore, I feel it's appropriate to separate and explain
the two in a very minimalist format.
==What is Ruby?==
Ruby is a programming "language". It is the very backbone upon which
rails was built. Understanding Ruby is, IMHO, more important than
understanding Rails. Without a proper understanding of the core
programming language that Rails itself is built upon, many trivial
things can become complicated things.
This is why it's important to remember to read up on your Ruby
programming language resources. There is a wealth of knowledge all
around the web for Ruby.
http://www.ruby-lang.org/en/
http://www.ruby-forum.com/forum/4
==What is Rails?==
Rails is a "platform". It is easy to confuse and mistake apples for
oranges but Rails is "not" a programming language. It is a development
"platform". It is also still a very young platform, roughly 5 years
old. It was released as open source in July 2004.
==Making proper comparisons==
When performing research, please make sure you compare apples to apples
and not apples to oranges. For instance:
PHP vs. Ruby on Rails (incorrect)
-- PHP is a language and Ruby on Rails is a platform
You can compare various "platforms" that PHP might use to Rails, but you
can't compare a language to a platform. Many people make this mistake.
Älphä Blüë
It might be better to say that Rails is a "framework".. :)
.. or more precisely, a web application framework..
Ruby = language
Rails = framework
Älphä Blüë
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 "yo...@email.com" -t rsa
4. Configure your profile by typing:
git config --global user.name "Your Name"
git config --global user.email Your...@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 g...@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.
=========
Now if you go to your git repository online you will see all the changes
and notes. There is a lot more that you can do with Git and I'm just
touching on the basics and hoping to help anyone who has trouble getting
an initial repository going.
Take care.
s.ross
system. So, independent of github, software version control is an
important practice.
Sazima
http://charlesmaxwood.com/9-resources-for-new-ruby-on-rails-developers/
Cheers, Sazima
Älphä Blüë
> 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üë
Ruby Platforms, Rails Versions, and Other Notables
==================================================
With any language, there are always multiple versions (platforms) that
you can use. Ruby is no different when it comes to this. In addition,
there are specific OS (Operaing System) distributions for those
platforms. Installation of each platform type, based on the OS type can
be entirely different and at times confusing.
Rails also houses many different versions and each one has specific
nuances versus the other. So, trying to find a good combination of the
two for your development/testing/production projects can be a bit
difficult, considering how much information we become inundated with
over the course of documentation and help searches.
Here is a solid rule of thumb:
Don't upgrade Ruby platforms OR Rails versions for (production). Don't
ever do it unless you enjoy some amount of pain, hardship, and reaching
for Tylenol and Motrin.
Conrad Taylor offered me some great advice when I thought about doing
the former. I'm going to add these thoughts because they do help:
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.
Ar Chron
> ==================================================
> Ruby Platforms, Rails Versions, and Other Notables
> ==================================================
>
>
> 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.
bill walton
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.
Alpha Blue
Rescue and Redirects
==============================
There are a lot of times that you'll find when you perform a query on
your database that no records are found. Some people that are new to
rails might do something like:
if model.find(:all).empty?
.. do something else
else
.. continue with our program ..
end
But, this doesn't really help you when you have a very extensive
routine. It also doesn't really handle ActiveRecord returns or even
logging the errors to your logs.
This is where rescue is a great feature that rails has implemented into
it. How do you use it? Here's an example:
def get_products(product_id)
begin
@products = Product.find(product_id)
rescue ActiveRecord::RecordNotFound
logger.error("#{product_id} in products wasn't found from
get_products."
redirect_to :action => :index
else
.. continue with your routine
end
end
So, what did we do here?
Pretty simple when you look deeply at it. We have a routine that tries
to find a product by a product_id. Rescue occurs if no record is found
from ActiveRecord and a logger error is placed in your log telling you
what occurred, so you can later review and fix (if it needs fixing) the
error. It then redirects your user back to the index (or you can
specify some other redirect (redirect_to root_url OR redirect_to
controllername_path, etc.). If the rescue doesn't occur, the method
continues on and processes your routine.
By using rescue you don't have to interfere greatly with your model's
core methods. Adding too much logic to your model methods might not be
a good thing. 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 hope this helps.
Thanks.
Marnen Laibow-Koser
[...]
> This is where rescue is a great feature that rails has implemented into
> it.
Actually, it's a basic Ruby feature.
> How do you use it? Here's an example:
>
> def get_products(product_id)
> begin
> @products = Product.find(product_id)
> rescue ActiveRecord::RecordNotFound
> logger.error("#{product_id} in products wasn't found from
> get_products."
> redirect_to :action => :index
> else
> .. continue with your routine
> end
> end
In most cases, this would not be worth logging. Even if it is,
exception handling may not be the best way to do it. (Also, the method
is badly named, since it will only ever get one product.)
[...]
> By using rescue you don't have to interfere greatly with your model's
> core methods. Adding too much logic to your model methods might not be
> a good thing.
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 hope this helps.
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.
>
> Thanks.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
Alpha Blue
> 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.
s.ross
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.