Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-26T19:08:16Z

Msudhee: /* Understanding Error Messages in Rails */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the [http://en.wikipedia.org/wiki/Backchannel backchannel] application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>

You can also get the application trace manually at any point through the following command:
begin
raise object.inspect
rescue
Rails.logger.warn $!.backtrace.to_yaml
end
This will cause a deliberate error along with an application trace of how you got there.

===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see calls to <code>activerecord</code> in the beginning. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.

Stack trace can be logged using the following lines of code:
begin
raise
rescue => e
logger.error e.message
e.backtrace.each { |line| logger.error line }
end

===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

A session dump can be obtained using the following command:
<%= debug session %>

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostsController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for web development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of problems, the ones particular to versions of ruby and various gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687
# http://stackoverflow.com/questions/8408936/rake-dbmigrate-error

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-26T19:07:21Z

Msudhee: /* References */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>

You can also get the application trace manually at any point through the following command:
begin
raise object.inspect
rescue
Rails.logger.warn $!.backtrace.to_yaml
end
This will cause a deliberate error along with an application trace of how you got there.

===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see calls to <code>activerecord</code> in the beginning. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.

Stack trace can be logged using the following lines of code:
begin
raise
rescue => e
logger.error e.message
e.backtrace.each { |line| logger.error line }
end

===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

A session dump can be obtained using the following command:
<%= debug session %>

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostsController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for web development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of problems, the ones particular to versions of ruby and various gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687
# http://stackoverflow.com/questions/8408936/rake-dbmigrate-error

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-26T19:07:06Z

Msudhee: /* Further Reading */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>

You can also get the application trace manually at any point through the following command:
begin
raise object.inspect
rescue
Rails.logger.warn $!.backtrace.to_yaml
end
This will cause a deliberate error along with an application trace of how you got there.

===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see calls to <code>activerecord</code> in the beginning. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.

Stack trace can be logged using the following lines of code:
begin
raise
rescue => e
logger.error e.message
e.backtrace.each { |line| logger.error line }
end

===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

A session dump can be obtained using the following command:
<%= debug session %>

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostsController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for web development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of problems, the ones particular to versions of ruby and various gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687
# http://stackoverflow.com/questions/8408936/rake-dbmigrate-error

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T23:50:03Z

Msudhee: /* Stack Trace */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>

You can also get the application trace manually at any point through the following command:
begin
raise object.inspect
rescue
Rails.logger.warn $!.backtrace.to_yaml
end
This will cause a deliberate error along with an application trace of how you got there.

===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see calls to <code>activerecord</code> in the beginning. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.

Stack trace can be logged using the following lines of code:
begin
raise
rescue => e
logger.error e.message
e.backtrace.each { |line| logger.error line }
end

===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

A session dump can be obtained using the following command:
<%= debug session %>

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostsController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for web development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of problems, the ones particular to versions of ruby and various gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687
# http://stackoverflow.com/questions/8408936/rake-dbmigrate-error

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T23:48:20Z

Msudhee: /* Conclusion */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>

You can also get the application trace manually at any point through the following command:
begin
raise object.inspect
rescue
Rails.logger.warn $!.backtrace.to_yaml
end
This will cause a deliberate error along with an application trace of how you got there.

===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.

Stack trace can be logged using the following lines of code:
begin
raise
rescue => e
logger.error e.message
e.backtrace.each { |line| logger.error line }
end

===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

A session dump can be obtained using the following command:
<%= debug session %>

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostsController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for web development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of problems, the ones particular to versions of ruby and various gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687
# http://stackoverflow.com/questions/8408936/rake-dbmigrate-error

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:59:18Z

Msudhee: /* What is a debugger? */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostsController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687
# http://stackoverflow.com/questions/8408936/rake-dbmigrate-error

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:57:53Z

Msudhee: /* References */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687
# http://stackoverflow.com/questions/8408936/rake-dbmigrate-error

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:57:03Z

Msudhee: /* References */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
# https://www.youtube.com/watch?v=Ee5vfe0mLb8
# http://railstips.org/blog/archives/2011/08/31/stupid-simple-debugging/
# http://guides.rubyonrails.org/debugging_rails_applications.html
# http://railscasts.com/episodes/54-debugging-with-ruby-debug
# http://bashdb.sourceforge.net/ruby-debug.html
# http://cheat.errtheblog.com/s/rdebug/
# http://railscasts.com/episodes/24-the-stack-trace
# http://www.scribd.com/doc/86869289/3/Rails-Cookery-3
# http://www.ruby-forum.com/topic/67687

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:53:58Z

Msudhee: /* A Very Common Error Message in Ruby */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Most often, it means that an assignment failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:52:59Z

Msudhee: /* Most Common Error Messages in Ruby */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===A Very Common Error Message in Ruby===
<code>undefined method ‘foo’ for nil:NilClass</code> 

Often, it means that an assignment silently failed and we didn't check for errors. 
Example: <code>@m = Movie.find_by_id(id) #could be nil</code> 

When you try to call m.title after an assignment like the one above, it will throw this error.

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:50:34Z

Msudhee: /* Env Dump and Session Dump */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment. If the error is localized to users who use the same version of a host or a protocol, we could find that out using the environment dump.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===Most Common Error Messages in Ruby===

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:48:21Z

Msudhee: /* Env Dump and Session Dump */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Wayne-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===Most Common Error Messages in Ruby===

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:47:59Z

Msudhee: /* Env Dump and Session Dump */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Manoj-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>

===Most Common Error Messages in Ruby===

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:47:30Z

Msudhee: /* Understanding Error Messages in Rails */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, [https://www.youtube.com/watch?v=Ee5vfe0mLb8 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson]. We aim to cover all the material presented in the video with definitions and examples
===Why debugging in Rails can be tricky?===
*We are used to printing the error on the terminal in most applications(Example: [http://www.cplusplus.com/reference/clibrary/cstdio/stderr/ STDERR]). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
Steps to follow when faced with an error can be concisely represented by RASP according to Dr. Fox.
===What is RASP?===
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you? 
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo." 
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS. 
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==
Rails usually provides a very verbose description of error messages. Dr. Fox tells us that error messages are our friends, they try to not only show us what went wrong but a great deal of detail of where it went wrong. Let us look at an example error message. 

Example:
An error message was deliberately caused by entering a route which wouldn't work. The application which we are using is the backchannel application and we are trying to find a post with id=20 (it doesn't exist). This causes rails to throw the following error message.

<code>'''ActiveRecord::RecordNotFound in PostsController#show'''</code>

<code>Couldn't find Post with id=20 
Rails.root: C:/Users/BruceWayne/Downloads/BackChannelApplication 
Application Trace | Framework Trace | Full Trace </code>

'''What is the error message trying to tell us?''' 
It tells us that ActiveRecord raised the error, and the error was raised in the show method of the Posts Controller. Rails tried to find a post with id=20 but it failed.
===Application Trace===
The application trace will give us the file, line number and the method in which the error was thrown. For the above example the application trace will look like this: 
<code>app/controllers/posts_controller.rb:17:in `show'</code>
===Stack Trace===
Full stack trace shows us the entire stack trace of right when the application started until the problem is encountered. Usually stack traces are very lengthy but they can be very useful to solve problems. Here is a partial stack trace from the back channel application error which we saw before: 
<code>activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:312:in `find_with_ids' 
activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:107:in `find' 
C:in `find' 
app/controllers/posts_controller.rb:17:in `show' 
actionpack (3.2.8) lib/action_controller/metal/implicit_render.rb:4:in `send_action' 
actionpack (3.2.8) lib/abstract_controller/base.rb:167:in `process_action' </code>

We can see the stack trace right from where the Rails application started, we can see the calls to activerecord. It is unlikely that there would be a problem in those files. As we continue looking into the stack trace we see the find method, we can click on the link in the trace and it will take us to the line in which the error was found. Most often the first few lines of the stack trace will give us the cause behind the error.
===Env Dump and Session Dump===
Session dump gives all the information of the user's session. This is useful if the error which needs to be fixed is particular to a user or a group of users.
<code>_csrf_token: "LiTiqHSVFOr8uT0+pFJhNCFjUc3YikuJy6F77QG+O1Y=" 
comment_id: 1 
post_id: 1 
session_id: "c562769a55b39620228ce6064aaa1637" 
user: #<User id: 4, name: "seriously", username: "seriously", email: "seriously@seriously.com", encrypted_password: "cb32e64bd4cb11c7424ea4ea75731450e99ed120d4bab155a42...", salt: "DlLGMQzwgU", is_admin: nil, created_at: "2012-11-18 01:08:35", updated_at: "2012-11-18 01:08:35"></code> 

Environment dump gives details of the rails runtime environment.
<code>GATEWAY_INTERFACE: "CGI/1.1" 
HTTP_ACCEPT: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 
HTTP_ACCEPT_CHARSET: "ISO-8859-1,utf-8;q=0.7,*;q=0.3" 
HTTP_ACCEPT_ENCODING: "gzip,deflate,sdch" 
HTTP_ACCEPT_LANGUAGE: "en-US,en;q=0.8" 
REMOTE_ADDR: "127.0.0.1" 
REMOTE_HOST: "Manoj-PC" 
SERVER_NAME: "localhost" 
SERVER_PROTOCOL: "HTTP/1.1" </code>
===Most Common Error Messages in Ruby===

==Rails Debugger==
===What is a debugger?===
Sometimes printing errors to the console or logging is not enough to find out the root cause behind an error message. It is during these times when the debugger is a developer's best friend. The debugger helps us to step forward or backward in the code, execute or skip lines of code, examine the state of a variable or a parameter which has been passed. This will help the developer pinpoint to the actual source of the problem and fix it. 

'''How to install the debugger?''' 
In Rails, ruby-debug is a gem. We can install it like any other gem. To use the gem in a Rails application we need to add the following line: 
<code>require "ruby-debug"</code> 
in the <code>config/environments/development.rb</code> file. 

In Ruby 1.9, you can use this command to install a compatible version of the debugger gem: 
<code>gem install debugger</code> 
'''Running the debugger '''
To use the debugger in the rails application we need to start the server with the <code>--debugger</code> option. 
<code>$ rails server --debugger</code>

If we don't do this we would encounter an error like this: 
<code>***** Debugger requested, but was not available: Start server with --debugger to enable *****</code> 

We can invoke the debugger from any method by using the <code>debugger</code> keyword in the method. 
Example: 

----

<code>class PostController < ApplicationController
def new
debugger
@post = Post.new
end
end</code>

----
Once the debugger method is called a debugger shell is started inside the terminal window where the application server was launched, and the cursor will be placed at ruby-debug’s prompt <code>(rdb:n)</code> where n is the thread number. The prompt will show the next line of code which is waiting to run.

==Conclusion==
Rails is a relatively new platform for development, it is continually evolving which effectively means debugging is harder. However by leveraging the knowledge of people who have encountered similar errors before we can resolve a subset of the problems, the ones particular to versions of ruby and other gems. We have tools like debugger and application trace to help us solve problems which are specific to our application. To know more about using the debugger, please refer to the Further Reading section of the article.

==Further Reading==
# [http://guides.rubyonrails.org/debugging_rails_applications.html Rails Guide - Debugging Rails Applications]
# [http://www.sitepoint.com/debug-rails-app-ruby-debug/ Debug your rails app with ruby-debug]
# [http://rubyforge.org/projects/ruby-debug/ Ruby Forge - Documentation for ruby-debug]

==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:17:23Z

Msudhee: /* What is RASP? */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:15:45Z

Msudhee: /* Understanding Error Messages in Rails */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T19:13:26Z

Msudhee: /* Understanding Error Messages in Rails */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T18:17:10Z

Msudhee: /* Conclusion */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T18:04:30Z

Msudhee: /* What is RASP */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T18:04:14Z

Msudhee: /* RASP */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T18:01:36Z

Msudhee: /* Rails Debugger */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T17:59:45Z

Msudhee: /* Introduction */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T17:59:31Z

Msudhee: /* Introduction */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T17:58:45Z

Msudhee: /* Further Reading */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T17:54:26Z

Msudhee: /* What is a debugger? */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T17:50:51Z

Msudhee: /* Rails Debugger */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T17:48:34Z

Msudhee: /* Interactive Debugger */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T17:47:52Z

Msudhee: /* What is an interactive debugger? */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T01:17:37Z

Msudhee: /* Introduction */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T01:16:22Z

Msudhee: /* Introduction */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T01:15:25Z

Msudhee: /* Application Trace */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson. We aim to cover all the material presented in the video with definitions and examples 
'''Why debugging in Rails can be tricky?''' 
*We are used to printing the error on the terminal in most applications(Example: STDERR). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you?
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo."
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==

===Application Trace===

===Full Trace===

===Framework Trace===

===Env Dump and Session Dump===
===Most Common Error Messages in Ruby===

==Interactive Debugger==
===What is an interactive debugger?===

==Conclusion==
==Further Reading==
==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T01:10:47Z

Msudhee: /* Full Trace */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson. We aim to cover all the material presented in the video with definitions and examples 
'''Why debugging in Rails can be tricky?''' 
*We are used to printing the error on the terminal in most applications(Example: STDERR). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you?
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo."
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==

===Application Trace===
===Full Trace===

===Framework Trace===

===Env Dump and Session Dump===
===Most Common Error Messages in Ruby===

==Interactive Debugger==
===What is an interactive debugger?===

==Conclusion==
==Further Reading==
==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-18T01:10:29Z

Msudhee: /* Back Trace */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson. We aim to cover all the material presented in the video with definitions and examples 
'''Why debugging in Rails can be tricky?''' 
*We are used to printing the error on the terminal in most applications(Example: STDERR). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you?
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo."
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==

===Application Trace===
===Full Trace===

===Full Trace===
===Env Dump and Session Dump===
===Most Common Error Messages in Ruby===

==Interactive Debugger==
===What is an interactive debugger?===

==Conclusion==
==Further Reading==
==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-17T23:59:59Z

Msudhee: /* RASP */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson. We aim to cover all the material presented in the video with definitions and examples 
'''Why debugging in Rails can be tricky?''' 
*We are used to printing the error on the terminal in most applications(Example: STDERR). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you?
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo."
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:Ques.png]] 
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly. 
[[File:Ans.png]] 
The answer is posted within an hour of posting the question. This shows that posting on stack overflow is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==

===Application Trace===
===Back Trace===
===Full Trace===
===Env Dump and Session Dump===
===Most Common Error Messages in Ruby===

==Interactive Debugger==
===What is an interactive debugger?===

==Conclusion==
==Further Reading==
==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

File:Ans.png

2012-11-17T23:58:37Z

Msudhee:

File:Ques.png

2012-11-17T23:58:10Z

Msudhee:

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-17T23:51:02Z

Msudhee: /* RASP */

==Introduction==
This is a wiki article for the material presented in the Coursera SaaS video series, 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson. We aim to cover all the material presented in the video with definitions and examples 
'''Why debugging in Rails can be tricky?''' 
*We are used to printing the error on the terminal in most applications(Example: STDERR). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.

*Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
URI -> Route -> Controller -> Model -> View -> Renderer

Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.

*Errors can be hard to localize/reproduce if it affects only some users or routes.

There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:

'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode. 

'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later. 

'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error. 

Here is a summary of the various approaches and the modes in which they can be used: 
{| class="wikitable"
|-
! Approach !! Development !! Production
|-
| Printing to Terminal || ✓ ||
|-
| Logging || ✓ || ✓
|-
| Interactive Debugging || ✓ ||
|}

==RASP==
RASP is an acronym which briefs the steps which a developer could follow if she were facing an error message. It stands for:
#'''Read''' the error message.
#'''Ask''' your colleague
#'''Search''' using [http://stackoverflow.com/ Stack Overflow] or any other search engine.
#'''Post''' on [http://stackoverflow.com/ Stack Overflow] or class forum

Reading the error message carefully is the first step in debugging. The error messages in Rails are incredibly detailed and it gives us a lot of information, reading it carefully can help us locate the file and line in which you are facing the error. But what if the line looks alright to you?
The next step is to ask a colleague an informed question. In case you are doing pair programming, this is a good step to take. The question has to be of the form "I am trying to do this and I expected to get this but I got this other thing instead of foo."
If the previous steps fail then searching using stack overflow or Google is next, especially if its an error which is particular to a version of gems or OS
In case you don't find a solution to your problem the final step is to get minimal but complete information which reproduces the error message which you are experiencing and post it. 

Here is an example question and solution from stack overflow: 

[[File:question.jpg]]
As we can see the question follows the guidelines explained above. It gives minimal but complete information about the error. It does not give the entire description of the error. It is important to post minimal information so that the person who answers the question can understand your problem quickly.
[[File:answer.jpg]]
The answer is posted within half an hour of posting the question. This shows that this is a fast way of getting expert help with debugging.

==Understanding Error Messages in Rails==

===Application Trace===
===Back Trace===
===Full Trace===
===Env Dump and Session Dump===
===Most Common Error Messages in Ruby===

==Interactive Debugger==
===What is an interactive debugger?===

==Conclusion==
==Further Reading==
==References==
https://www.youtube.com/watch?v=Ee5vfe0mLb8

File:Answer.jpg

2012-11-17T23:37:40Z

Msudhee:

File:Question.jpg

2012-11-17T23:36:42Z

Msudhee:

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-17T23:00:02Z

Msudhee: /* Introduction */

CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

2012-11-16T16:46:00Z

Msudhee: Created page with "==Introduction== ===Why debugging in SaaS/Rails is hard?=== ===Definitions=== ==RASP== ===Steps of RASP=== ==Understanding Error Messages in Rails== ===Application Trace=== =..."

==Introduction==
===Why debugging in SaaS/Rails is hard?===
===Definitions===

==RASP==

===Steps of RASP===

==Understanding Error Messages in Rails==

===Application Trace===
===Back Trace===
===Full Trace===
===Env Dump and Session Dump===
===Most Common Error Messages in Ruby===

==Interactive Debugger==
===What is an interactive debugger?===

==Conclusion==
==Further Reading==
==References==

CSC/ECE 517 Fall 2012

2012-11-16T16:41:15Z

Msudhee:

*[[CSC/ECE_517_Fall_2012/Table_Of_Contents]]
*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w10_rc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w70_sm]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w67_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w40_sn]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w22_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w-1w65_am]]

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T02:27:20Z

Msudhee: /* References */

==Introduction==

===What is Object Oriented Programming?===
Wikipedia defines [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming (OOP)] as a programming paradigm that uses objects and their interactions to design applications and computer programs.
The primary programming concepts in OOP are:
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] - hiding all but the necessary data about an object in order to reduce complexity and increase efficiency.
*[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism ] - characteristic of being able to assign a different meaning to a particular function or "operator" in different contexts.
*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] - hide the implementation details of a class from other objects.
*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance] - form new classes using existing class definitions.
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is pure object-oriented language! i.e to Ruby, everything appears as an object. Every value in Ruby is an object, even the most primitive things: strings, numbers and even true and false. Ruby is so true to being object oriented that even a class is an object that is an instance of the ‘C’lass class.
In object-oriented code, we model concepts from the real world. During this modeling process you’ll different items to be represented. In Ruby, classes are defined to represent each of these items. Objects, which are instances of a class are nothing but different kinds of that item in terms of Ruby.

Now let’s look at some basic object oriented concepts in Ruby.

==Object==
[http://en.wikipedia.org/wiki/Object_(computer_science) Objects] are basic building blocks of a Ruby OOP program. Every basic item, when being represented, can be given its own properties and actions. Object-oriented programming calls properties by the name instance variables , whose names starts with @, and actions are known as methods.
A '''class''' is a template for an '''object''', and an '''object''' is an instance of the class. Objects are created by calling a constructor, a special method associated with a class. The constructor in Ruby is called initialize. Constructors do not return any values. Constructors can be parameterized too, to contain values that initialize the instance method. This is also called the '''initialize method'''. For example, 

Example: 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

account1 = Account.new 10

----

Here the constructor, when invoked will create an object of type ‘Account’ represented by the name account1nitialize the instance variable balance to 10. Each object gets its own set of instance variables.
Different objects communicate together through methods. Each object can receive messages, send messages and process data.

==Class==
A [http://www.ruby-doc.org/core-1.9.3/Class.html class] can be defined as a blueprint for a data type. It defines the state and behaviour of the class, that is, what an object of the class will consist of and what operations can be performed on such an object. A class represents the real world entity.

A class definition starts with the keyword class followed by the class name and is delimited with an end. For example we defined the BankAccount class using the keyword class as follows:

Example: 
----
class BankAccount 
attr_accessor :name, :balance 
def deposit(amt) 
@balance+=amt 
end 
end 

----
The class BankAccount, contains instance variables(defined later) name and balance that defines the state of an object of the class and a method deposit that defines the behavior.
Here, the name (BankAccount) must begin with a capital letter. By convention, names that contain more than one word run together with each word capitalized and no separating characters (CamelCase).

==Inheritance==
One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. The newly formed class is called the derived class or the sub-class, the class that we derive from is called base class or the super-class.
Although, inheritance provides an opportunity to reuse the code functionality and hasten implementation time, Ruby does not support Multiple level of inheritances. However, this functionality can be implemented using another feature called [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html mixins]. A mixin is like a specialized implementation of multiple inheritance in which only the interface portion is inherited.
The syntax for extending a class is by adding a “<” character and the name of the superclass to the class statement.
Example : 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

class SharedAccount < Account 
# adding another instance variable “common_fund” and an instance method “share” 

def share(common=0) # optional argument 
@common_fund = common 
print "Total Balance : #{@balance + @common_fund}" 
end 
end 
a = SharedAccount.new 10 
a.share(20) 
 
Output : Total Balance : 30 


----
The above, will make use of both base class and derived class instance variables.

==Instance Variables and Accessor Methods==

===Instance Variables===
An instance variable begins with the symbol “@” in Ruby. It is different from a local variable because its scope is confined to the object to which self refers. Instance variables are invisible outside of the object. The only way we can access them or observer them is by writing methods to get or set the value of them. Instance variables have the value “nil” until they are initialized.
Instance variables do not need to be declared. In fact we can also access instance variables without declaring or initializing it, this will not raise an exception. However a warning will be issued if we run it using the –w switch.
Every instance variable is dynamically appended to an object in the first assignment. 
Example: 
----
@balance -> instance variable
----
===Accessor Methods===
As stated previously, we cannot access instance variables from anywhere outside an object. Hence we need to define methods to access them. They are generally called as getter and setter methods.
The getter method is used to return the value of the instance variable. It would be defined as: 

Example: 
----
def balance 
@balance 
end 
----

The setter method is used to set the value of the instance variable. Setter methods always end with the “=” sign. It would be defined as: 
Example: 
----
def balance= (bal) 
@balance = bal 
end 
----

Instead of writing getter and setter methods for each class, we can use the attr_accessor function. The attr_accessor is a method call which uses metaprogramming to generate the getter and setter methods dynamically at run time. 

Example: 
----
attr_accessor :balance
----

This is equivalent to
----
 
def balance 
@balance 
end 
def balance= (bal) 
@balance = bal 
end 
----

We can also generate getter and setter methods for more than one instance variable. 
----
 
attr_accessor :balance, :new_balance
----

We can also use attr_reader if we only want to generate the getter function. Similarly we can use the method call attr_writer for generating just the setter function.

==Instance Methods==
Instance methods work with instances of the class. So in order to use instance methods we have to create an instance. 

Example: 
----
def deposit 
@balance += amount 
end 
----

You can include the definition of an instance method within the class like this:
Example: 
----
Class SavingsAccount < Account 
def deposit @balance += amount end 
end 
----

Or you can also define it later. Since Ruby is a dynamic programming language we are allowed to reopen a class and add methods to it. For instance to add the deposit method after closing the class:
----

Class SavingsAccount < Account 
end 
SAcc = SavingsAccount.new 
def SAcc.deposit 
@balance += amount 
end 
----
The save and update methods used in Rails are actually instance methods.

There are two types of methods in Ruby: Safe methods and destructive methods. They are called as safe and destructive depending on whether they modify the input parameters passed to them. The destructive methods end with the “!” symbol, so that they can warn the programmer when he is writing the code. “<<” is another example of a destructive method.

==Class Variables and Class Methods==
===Class Variables===
A class variable begins with the symbol “@@” in Ruby. Once we define a class variable it is set for the class and all of its subclasses. 
Example:
----
@@bank_name = “MyBank.com”
----
We need to add a getter method to access the class variable from outside the class. This would look like:
----
def self.bank_name 
@@bank_name 
end 
puts SavingsAccount.bank_name => “MyBank.com” 
----

===Class Methods===
Class methods are equivalent to static methods in Java. Class methods only exist in the class that defined them. So we cannot call a class method with an instance variable, because the class method does not exist in the instance variable.
There are multiple ways of defining class methods. 
*def SavingsAccount.bank_name 
*def self.bank_name 
*class << self def bank_name 

In Method 1 we use the class name followed by a dot followed by the class method name. In Method 2 we use the keyword [http://stackoverflow.com/questions/6669527/use-of-ruby-self-keyword self]. In Ruby self gives you access to the current object, when defined within a class it refers to the current class. Method 2 is frequently used to define a class method.
In the third method we are actually building an anonymous class for the current object (referred by self) using the << notation. We are doing exactly what we did in Method 2, it is uncommon to see the use of Method 3.

==Further Reading==
[http://www.ruby-doc.org/docs/ProgrammingRuby/ Programming Ruby: The Pragmatic Programmer's Guide]: An excellent textbook for learning and understanding Ruby 
[http://www.ruby-lang.org/en/documentation/quickstart/ Ruby in 20 minutes] : An online tutorial for getting a hang of Ruby. 
[http://tryruby.org/levels/1/challenges/0 Try Ruby]: Try Ruby online without installing it on your machine 
[http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes Wikibooks Programming Ruby]: A wikibook link for Programming Ruby 

==References==
[http://en.wikipedia.org/wiki/Object-oriented_programming1]http://en.wikipedia.org/wiki/Object-oriented_programming 
[http://www.ruby-doc.org/docs/ProgrammingRuby/html/2]http://www.ruby-doc.org/docs/ProgrammingRuby/html/ 
[http://www.rubyfleebie.com/understanding-class-methods-in-ruby/3]http://www.rubyfleebie.com/understanding-class-methods-in-ruby/ 
[http://stackoverflow.com/questions/2084490/ruby-class-variables4]http://stackoverflow.com/questions/2084490/ruby-class-variables 
[http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/5]http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 
[http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods6]http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods/ 
[http://www.rubyist.net/~slagell/ruby/instancevars.html7]http://www.rubyist.net/~slagell/ruby/instancevars.html 
[http://www.rubyist.net/~slagell/ruby/accessors.html8]http://www.rubyist.net/~slagell/ruby/accessors.html 
[http://rubylearning.com/satishtalim/ruby_inheritance.html9]http://rubylearning.com/satishtalim/ruby_inheritance.html 
[http://www.tutorialspoint.com/ruby/ruby_object_oriented.htm10]http://www.tutorialspoint.com/ruby/ruby_object_oriented.htm 
[http://www.ruby-lang.org/en/about/11]http://www.ruby-lang.org/en/about/ 
[http://www.rubyist.net/~slagell/ruby/objinitialization.html12]http://www.rubyist.net/~slagell/ruby/objinitialization.html

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T02:25:27Z

Msudhee: /* Further Reading */

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T01:52:15Z

Msudhee: /* Further Reading */

==Introduction==

===What is Object Oriented Programming?===
Wikipedia defines [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming (OOP)] as a programming paradigm that uses objects and their interactions to design applications and computer programs.
The primary programming concepts in OOP are:
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] - hiding all but the necessary data about an object in order to reduce complexity and increase efficiency.
*[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism ] - characteristic of being able to assign a different meaning to a particular function or "operator" in different contexts.
*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] - hide the implementation details of a class from other objects.
*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance] - form new classes using existing class definitions.
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is pure object-oriented language! i.e to Ruby, everything appears as an object. Every value in Ruby is an object, even the most primitive things: strings, numbers and even true and false. Ruby is so true to being object oriented that even a class is an object that is an instance of the ‘C’lass class.
In object-oriented code, we model concepts from the real world. During this modeling process you’ll different items to be represented. In Ruby, classes are defined to represent each of these items. Objects, which are instances of a class are nothing but different kinds of that item in terms of Ruby.

Now let’s look at some basic object oriented concepts in Ruby.

==Object==
[http://en.wikipedia.org/wiki/Object_(computer_science) Objects] are basic building blocks of a Ruby OOP program. Every basic item, when being represented, can be given its own properties and actions. Object-oriented programming calls properties by the name instance variables , whose names starts with @, and actions are known as methods.
A '''class''' is a template for an '''object''', and an '''object''' is an instance of the class. Objects are created by calling a constructor, a special method associated with a class. The constructor in Ruby is called initialize. Constructors do not return any values. Constructors can be parameterized too, to contain values that initialize the instance method. This is also called the '''initialize method'''. For example, 

Example: 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

account1 = Account.new 10

----

Here the constructor, when invoked will create an object of type ‘Account’ represented by the name account1nitialize the instance variable balance to 10. Each object gets its own set of instance variables.
Different objects communicate together through methods. Each object can receive messages, send messages and process data.

==Class==
A [http://www.ruby-doc.org/core-1.9.3/Class.html class] can be defined as a blueprint for a data type. It defines the state and behaviour of the class, that is, what an object of the class will consist of and what operations can be performed on such an object. A class represents the real world entity.

A class definition starts with the keyword class followed by the class name and is delimited with an end. For example we defined the BankAccount class using the keyword class as follows:

Example: 
----
class BankAccount 
attr_accessor :name, :balance 
def deposit(amt) 
@balance+=amt 
end 
end 

----
The class BankAccount, contains instance variables(defined later) name and balance that defines the state of an object of the class and a method deposit that defines the behavior.
Here, the name (BankAccount) must begin with a capital letter. By convention, names that contain more than one word run together with each word capitalized and no separating characters (CamelCase).

==Inheritance==
One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. The newly formed class is called the derived class or the sub-class, the class that we derive from is called base class or the super-class.
Although, inheritance provides an opportunity to reuse the code functionality and hasten implementation time, Ruby does not support Multiple level of inheritances. However, this functionality can be implemented using another feature called [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html mixins]. A mixin is like a specialized implementation of multiple inheritance in which only the interface portion is inherited.
The syntax for extending a class is by adding a “<” character and the name of the superclass to the class statement.
Example : 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

class SharedAccount < Account 
# adding another instance variable “common_fund” and an instance method “share” 

def share(common=0) # optional argument 
@common_fund = common 
print "Total Balance : #{@balance + @common_fund}" 
end 
end 
a = SharedAccount.new 10 
a.share(20) 
 
Output : Total Balance : 30 


----
The above, will make use of both base class and derived class instance variables.

==Instance Variables and Accessor Methods==

===Instance Variables===
An instance variable begins with the symbol “@” in Ruby. It is different from a local variable because its scope is confined to the object to which self refers. Instance variables are invisible outside of the object. The only way we can access them or observer them is by writing methods to get or set the value of them. Instance variables have the value “nil” until they are initialized.
Instance variables do not need to be declared. In fact we can also access instance variables without declaring or initializing it, this will not raise an exception. However a warning will be issued if we run it using the –w switch.
Every instance variable is dynamically appended to an object in the first assignment. 
Example: 
----
@balance -> instance variable
----
===Accessor Methods===
As stated previously, we cannot access instance variables from anywhere outside an object. Hence we need to define methods to access them. They are generally called as getter and setter methods.
The getter method is used to return the value of the instance variable. It would be defined as: 

Example: 
----
def balance 
@balance 
end 
----

The setter method is used to set the value of the instance variable. Setter methods always end with the “=” sign. It would be defined as: 
Example: 
----
def balance= (bal) 
@balance = bal 
end 
----

Instead of writing getter and setter methods for each class, we can use the attr_accessor function. The attr_accessor is a method call which uses metaprogramming to generate the getter and setter methods dynamically at run time. 

Example: 
----
attr_accessor :balance
----

This is equivalent to
----
 
def balance 
@balance 
end 
def balance= (bal) 
@balance = bal 
end 
----

We can also generate getter and setter methods for more than one instance variable. 
----
 
attr_accessor :balance, :new_balance
----

We can also use attr_reader if we only want to generate the getter function. Similarly we can use the method call attr_writer for generating just the setter function.

==Instance Methods==
Instance methods work with instances of the class. So in order to use instance methods we have to create an instance. 

Example: 
----
def deposit 
@balance += amount 
end 
----

You can include the definition of an instance method within the class like this:
Example: 
----
Class SavingsAccount < Account 
def deposit @balance += amount end 
end 
----

Or you can also define it later. Since Ruby is a dynamic programming language we are allowed to reopen a class and add methods to it. For instance to add the deposit method after closing the class:
----

Class SavingsAccount < Account 
end 
SAcc = SavingsAccount.new 
def SAcc.deposit 
@balance += amount 
end 
----
The save and update methods used in Rails are actually instance methods.

There are two types of methods in Ruby: Safe methods and destructive methods. They are called as safe and destructive depending on whether they modify the input parameters passed to them. The destructive methods end with the “!” symbol, so that they can warn the programmer when he is writing the code. “<<” is another example of a destructive method.

==Class Variables and Class Methods==
===Class Variables===
A class variable begins with the symbol “@@” in Ruby. Once we define a class variable it is set for the class and all of its subclasses. 
Example:
----
@@bank_name = “MyBank.com”
----
We need to add a getter method to access the class variable from outside the class. This would look like:
----
def self.bank_name 
@@bank_name 
end 
puts SavingsAccount.bank_name => “MyBank.com” 
----

===Class Methods===
Class methods are equivalent to static methods in Java. Class methods only exist in the class that defined them. So we cannot call a class method with an instance variable, because the class method does not exist in the instance variable.
There are multiple ways of defining class methods. 
*def SavingsAccount.bank_name 
*def self.bank_name 
*class << self def bank_name 

In Method 1 we use the class name followed by a dot followed by the class method name. In Method 2 we use the keyword [http://stackoverflow.com/questions/6669527/use-of-ruby-self-keyword self]. In Ruby self gives you access to the current object, when defined within a class it refers to the current class. Method 2 is frequently used to define a class method.
In the third method we are actually building an anonymous class for the current object (referred by self) using the << notation. We are doing exactly what we did in Method 2, it is uncommon to see the use of Method 3.

==Further Reading==
[http://www.ruby-doc.org/docs/ProgrammingRuby/ Programming Ruby: The Pragmatic Programmer's Guide]: An excellent textbook for learning and understanding Ruby 
[http://www.ruby-lang.org/en/documentation/quickstart/ Ruby in 20 minutes] : An online tutorial for getting a hang of Ruby. 
[http://tryruby.org/levels/1/challenges/0 Try Ruby]: Try Ruby online without installing it on your machine! 

==References==
[http://en.wikipedia.org/wiki/Object-oriented_programming1]http://en.wikipedia.org/wiki/Object-oriented_programming 
[http://www.ruby-doc.org/docs/ProgrammingRuby/html/2]http://www.ruby-doc.org/docs/ProgrammingRuby/html/ 
[http://www.rubyfleebie.com/understanding-class-methods-in-ruby/3]http://www.rubyfleebie.com/understanding-class-methods-in-ruby/ 
[http://stackoverflow.com/questions/2084490/ruby-class-variables4]http://stackoverflow.com/questions/2084490/ruby-class-variables 
[http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/5]http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 
[http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods6]http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods/ 
[http://www.rubyist.net/~slagell/ruby/instancevars.html7]http://www.rubyist.net/~slagell/ruby/instancevars.html 
[http://www.rubyist.net/~slagell/ruby/accessors.html8]http://www.rubyist.net/~slagell/ruby/accessors.html

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T01:48:42Z

Msudhee: /* References */

==Introduction==

===What is Object Oriented Programming?===
Wikipedia defines [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming (OOP)] as a programming paradigm that uses objects and their interactions to design applications and computer programs.
The primary programming concepts in OOP are:
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] - hiding all but the necessary data about an object in order to reduce complexity and increase efficiency.
*[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism ] - characteristic of being able to assign a different meaning to a particular function or "operator" in different contexts.
*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] - hide the implementation details of a class from other objects.
*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance] - form new classes using existing class definitions.
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is pure object-oriented language! i.e to Ruby, everything appears as an object. Every value in Ruby is an object, even the most primitive things: strings, numbers and even true and false. Ruby is so true to being object oriented that even a class is an object that is an instance of the ‘C’lass class.
In object-oriented code, we model concepts from the real world. During this modeling process you’ll different items to be represented. In Ruby, classes are defined to represent each of these items. Objects, which are instances of a class are nothing but different kinds of that item in terms of Ruby.

Now let’s look at some basic object oriented concepts in Ruby.

==Object==
[http://en.wikipedia.org/wiki/Object_(computer_science) Objects] are basic building blocks of a Ruby OOP program. Every basic item, when being represented, can be given its own properties and actions. Object-oriented programming calls properties by the name instance variables , whose names starts with @, and actions are known as methods.
A '''class''' is a template for an '''object''', and an '''object''' is an instance of the class. Objects are created by calling a constructor, a special method associated with a class. The constructor in Ruby is called initialize. Constructors do not return any values. Constructors can be parameterized too, to contain values that initialize the instance method. This is also called the '''initialize method'''. For example, 

Example: 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

account1 = Account.new 10

----

Here the constructor, when invoked will create an object of type ‘Account’ represented by the name account1nitialize the instance variable balance to 10. Each object gets its own set of instance variables.
Different objects communicate together through methods. Each object can receive messages, send messages and process data.

==Class==
A [http://www.ruby-doc.org/core-1.9.3/Class.html class] can be defined as a blueprint for a data type. It defines the state and behaviour of the class, that is, what an object of the class will consist of and what operations can be performed on such an object. A class represents the real world entity.

A class definition starts with the keyword class followed by the class name and is delimited with an end. For example we defined the BankAccount class using the keyword class as follows:

Example: 
----
class BankAccount 
attr_accessor :name, :balance 
def deposit(amt) 
@balance+=amt 
end 
end 

----
The class BankAccount, contains instance variables(defined later) name and balance that defines the state of an object of the class and a method deposit that defines the behavior.
Here, the name (BankAccount) must begin with a capital letter. By convention, names that contain more than one word run together with each word capitalized and no separating characters (CamelCase).

==Inheritance==
One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. The newly formed class is called the derived class or the sub-class, the class that we derive from is called base class or the super-class.
Although, inheritance provides an opportunity to reuse the code functionality and hasten implementation time, Ruby does not support Multiple level of inheritances. However, this functionality can be implemented using another feature called [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html mixins]. A mixin is like a specialized implementation of multiple inheritance in which only the interface portion is inherited.
The syntax for extending a class is by adding a “<” character and the name of the superclass to the class statement.
Example : 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

class SharedAccount < Account 
# adding another instance variable “common_fund” and an instance method “share” 

def share(common=0) # optional argument 
@common_fund = common 
print "Total Balance : #{@balance + @common_fund}" 
end 
end 
a = SharedAccount.new 10 
a.share(20) 
 
Output : Total Balance : 30 


----
The above, will make use of both base class and derived class instance variables.

==Instance Variables and Accessor Methods==

===Instance Variables===
An instance variable begins with the symbol “@” in Ruby. It is different from a local variable because its scope is confined to the object to which self refers. Instance variables are invisible outside of the object. The only way we can access them or observer them is by writing methods to get or set the value of them. Instance variables have the value “nil” until they are initialized.
Instance variables do not need to be declared. In fact we can also access instance variables without declaring or initializing it, this will not raise an exception. However a warning will be issued if we run it using the –w switch.
Every instance variable is dynamically appended to an object in the first assignment. 
Example: 
----
@balance -> instance variable
----
===Accessor Methods===
As stated previously, we cannot access instance variables from anywhere outside an object. Hence we need to define methods to access them. They are generally called as getter and setter methods.
The getter method is used to return the value of the instance variable. It would be defined as: 

Example: 
----
def balance 
@balance 
end 
----

The setter method is used to set the value of the instance variable. Setter methods always end with the “=” sign. It would be defined as: 
Example: 
----
def balance= (bal) 
@balance = bal 
end 
----

Instead of writing getter and setter methods for each class, we can use the attr_accessor function. The attr_accessor is a method call which uses metaprogramming to generate the getter and setter methods dynamically at run time. 

Example: 
----
attr_accessor :balance
----

This is equivalent to
----
 
def balance 
@balance 
end 
def balance= (bal) 
@balance = bal 
end 
----

We can also generate getter and setter methods for more than one instance variable. 
----
 
attr_accessor :balance, :new_balance
----

We can also use attr_reader if we only want to generate the getter function. Similarly we can use the method call attr_writer for generating just the setter function.

==Instance Methods==
Instance methods work with instances of the class. So in order to use instance methods we have to create an instance. 

Example: 
----
def deposit 
@balance += amount 
end 
----

You can include the definition of an instance method within the class like this:
Example: 
----
Class SavingsAccount < Account 
def deposit @balance += amount end 
end 
----

Or you can also define it later. Since Ruby is a dynamic programming language we are allowed to reopen a class and add methods to it. For instance to add the deposit method after closing the class:
----

Class SavingsAccount < Account 
end 
SAcc = SavingsAccount.new 
def SAcc.deposit 
@balance += amount 
end 
----
The save and update methods used in Rails are actually instance methods.

There are two types of methods in Ruby: Safe methods and destructive methods. They are called as safe and destructive depending on whether they modify the input parameters passed to them. The destructive methods end with the “!” symbol, so that they can warn the programmer when he is writing the code. “<<” is another example of a destructive method.

==Class Variables and Class Methods==
===Class Variables===
A class variable begins with the symbol “@@” in Ruby. Once we define a class variable it is set for the class and all of its subclasses. 
Example:
----
@@bank_name = “MyBank.com”
----
We need to add a getter method to access the class variable from outside the class. This would look like:
----
def self.bank_name 
@@bank_name 
end 
puts SavingsAccount.bank_name => “MyBank.com” 
----

===Class Methods===
Class methods are equivalent to static methods in Java. Class methods only exist in the class that defined them. So we cannot call a class method with an instance variable, because the class method does not exist in the instance variable.
There are multiple ways of defining class methods. 
*def SavingsAccount.bank_name 
*def self.bank_name 
*class << self def bank_name 

In Method 1 we use the class name followed by a dot followed by the class method name. In Method 2 we use the keyword [http://stackoverflow.com/questions/6669527/use-of-ruby-self-keyword self]. In Ruby self gives you access to the current object, when defined within a class it refers to the current class. Method 2 is frequently used to define a class method.
In the third method we are actually building an anonymous class for the current object (referred by self) using the << notation. We are doing exactly what we did in Method 2, it is uncommon to see the use of Method 3.

==Further Reading==

==References==
[http://en.wikipedia.org/wiki/Object-oriented_programming1]http://en.wikipedia.org/wiki/Object-oriented_programming 
[http://www.ruby-doc.org/docs/ProgrammingRuby/html/2]http://www.ruby-doc.org/docs/ProgrammingRuby/html/ 
[http://www.rubyfleebie.com/understanding-class-methods-in-ruby/3]http://www.rubyfleebie.com/understanding-class-methods-in-ruby/ 
[http://stackoverflow.com/questions/2084490/ruby-class-variables4]http://stackoverflow.com/questions/2084490/ruby-class-variables 
[http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/5]http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 
[http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods6]http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods/ 
[http://www.rubyist.net/~slagell/ruby/instancevars.html7]http://www.rubyist.net/~slagell/ruby/instancevars.html 
[http://www.rubyist.net/~slagell/ruby/accessors.html8]http://www.rubyist.net/~slagell/ruby/accessors.html

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T01:47:58Z

Msudhee: /* References */

==Introduction==

===What is Object Oriented Programming?===
Wikipedia defines [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming (OOP)] as a programming paradigm that uses objects and their interactions to design applications and computer programs.
The primary programming concepts in OOP are:
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] - hiding all but the necessary data about an object in order to reduce complexity and increase efficiency.
*[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism ] - characteristic of being able to assign a different meaning to a particular function or "operator" in different contexts.
*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] - hide the implementation details of a class from other objects.
*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance] - form new classes using existing class definitions.
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is pure object-oriented language! i.e to Ruby, everything appears as an object. Every value in Ruby is an object, even the most primitive things: strings, numbers and even true and false. Ruby is so true to being object oriented that even a class is an object that is an instance of the ‘C’lass class.
In object-oriented code, we model concepts from the real world. During this modeling process you’ll different items to be represented. In Ruby, classes are defined to represent each of these items. Objects, which are instances of a class are nothing but different kinds of that item in terms of Ruby.

Now let’s look at some basic object oriented concepts in Ruby.

==Object==
[http://en.wikipedia.org/wiki/Object_(computer_science) Objects] are basic building blocks of a Ruby OOP program. Every basic item, when being represented, can be given its own properties and actions. Object-oriented programming calls properties by the name instance variables , whose names starts with @, and actions are known as methods.
A '''class''' is a template for an '''object''', and an '''object''' is an instance of the class. Objects are created by calling a constructor, a special method associated with a class. The constructor in Ruby is called initialize. Constructors do not return any values. Constructors can be parameterized too, to contain values that initialize the instance method. This is also called the '''initialize method'''. For example, 

Example: 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

account1 = Account.new 10

----

Here the constructor, when invoked will create an object of type ‘Account’ represented by the name account1nitialize the instance variable balance to 10. Each object gets its own set of instance variables.
Different objects communicate together through methods. Each object can receive messages, send messages and process data.

==Class==
A [http://www.ruby-doc.org/core-1.9.3/Class.html class] can be defined as a blueprint for a data type. It defines the state and behaviour of the class, that is, what an object of the class will consist of and what operations can be performed on such an object. A class represents the real world entity.

A class definition starts with the keyword class followed by the class name and is delimited with an end. For example we defined the BankAccount class using the keyword class as follows:

Example: 
----
class BankAccount 
attr_accessor :name, :balance 
def deposit(amt) 
@balance+=amt 
end 
end 

----
The class BankAccount, contains instance variables(defined later) name and balance that defines the state of an object of the class and a method deposit that defines the behavior.
Here, the name (BankAccount) must begin with a capital letter. By convention, names that contain more than one word run together with each word capitalized and no separating characters (CamelCase).

==Inheritance==
One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. The newly formed class is called the derived class or the sub-class, the class that we derive from is called base class or the super-class.
Although, inheritance provides an opportunity to reuse the code functionality and hasten implementation time, Ruby does not support Multiple level of inheritances. However, this functionality can be implemented using another feature called [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html mixins]. A mixin is like a specialized implementation of multiple inheritance in which only the interface portion is inherited.
The syntax for extending a class is by adding a “<” character and the name of the superclass to the class statement.
Example : 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

class SharedAccount < Account 
# adding another instance variable “common_fund” and an instance method “share” 

def share(common=0) # optional argument 
@common_fund = common 
print "Total Balance : #{@balance + @common_fund}" 
end 
end 
a = SharedAccount.new 10 
a.share(20) 
 
Output : Total Balance : 30 


----
The above, will make use of both base class and derived class instance variables.

==Instance Variables and Accessor Methods==

===Instance Variables===
An instance variable begins with the symbol “@” in Ruby. It is different from a local variable because its scope is confined to the object to which self refers. Instance variables are invisible outside of the object. The only way we can access them or observer them is by writing methods to get or set the value of them. Instance variables have the value “nil” until they are initialized.
Instance variables do not need to be declared. In fact we can also access instance variables without declaring or initializing it, this will not raise an exception. However a warning will be issued if we run it using the –w switch.
Every instance variable is dynamically appended to an object in the first assignment. 
Example: 
----
@balance -> instance variable
----
===Accessor Methods===
As stated previously, we cannot access instance variables from anywhere outside an object. Hence we need to define methods to access them. They are generally called as getter and setter methods.
The getter method is used to return the value of the instance variable. It would be defined as: 

Example: 
----
def balance 
@balance 
end 
----

The setter method is used to set the value of the instance variable. Setter methods always end with the “=” sign. It would be defined as: 
Example: 
----
def balance= (bal) 
@balance = bal 
end 
----

Instead of writing getter and setter methods for each class, we can use the attr_accessor function. The attr_accessor is a method call which uses metaprogramming to generate the getter and setter methods dynamically at run time. 

Example: 
----
attr_accessor :balance
----

This is equivalent to
----
 
def balance 
@balance 
end 
def balance= (bal) 
@balance = bal 
end 
----

We can also generate getter and setter methods for more than one instance variable. 
----
 
attr_accessor :balance, :new_balance
----

We can also use attr_reader if we only want to generate the getter function. Similarly we can use the method call attr_writer for generating just the setter function.

==Instance Methods==
Instance methods work with instances of the class. So in order to use instance methods we have to create an instance. 

Example: 
----
def deposit 
@balance += amount 
end 
----

You can include the definition of an instance method within the class like this:
Example: 
----
Class SavingsAccount < Account 
def deposit @balance += amount end 
end 
----

Or you can also define it later. Since Ruby is a dynamic programming language we are allowed to reopen a class and add methods to it. For instance to add the deposit method after closing the class:
----

Class SavingsAccount < Account 
end 
SAcc = SavingsAccount.new 
def SAcc.deposit 
@balance += amount 
end 
----
The save and update methods used in Rails are actually instance methods.

There are two types of methods in Ruby: Safe methods and destructive methods. They are called as safe and destructive depending on whether they modify the input parameters passed to them. The destructive methods end with the “!” symbol, so that they can warn the programmer when he is writing the code. “<<” is another example of a destructive method.

==Class Variables and Class Methods==
===Class Variables===
A class variable begins with the symbol “@@” in Ruby. Once we define a class variable it is set for the class and all of its subclasses. 
Example:
----
@@bank_name = “MyBank.com”
----
We need to add a getter method to access the class variable from outside the class. This would look like:
----
def self.bank_name 
@@bank_name 
end 
puts SavingsAccount.bank_name => “MyBank.com” 
----

===Class Methods===
Class methods are equivalent to static methods in Java. Class methods only exist in the class that defined them. So we cannot call a class method with an instance variable, because the class method does not exist in the instance variable.
There are multiple ways of defining class methods. 
*def SavingsAccount.bank_name 
*def self.bank_name 
*class << self def bank_name 

In Method 1 we use the class name followed by a dot followed by the class method name. In Method 2 we use the keyword [http://stackoverflow.com/questions/6669527/use-of-ruby-self-keyword self]. In Ruby self gives you access to the current object, when defined within a class it refers to the current class. Method 2 is frequently used to define a class method.
In the third method we are actually building an anonymous class for the current object (referred by self) using the << notation. We are doing exactly what we did in Method 2, it is uncommon to see the use of Method 3.

==Further Reading==

==References==
[http://en.wikipedia.org/wiki/Object-oriented_programming1]http://en.wikipedia.org/wiki/Object-oriented_programming 
[http://www.ruby-doc.org/docs/ProgrammingRuby/html/2]http://www.ruby-doc.org/docs/ProgrammingRuby/html/ 
[http://www.rubyfleebie.com/understanding-class-methods-in-ruby/3]http://www.rubyfleebie.com/understanding-class-methods-in-ruby/ 
[http://stackoverflow.com/questions/2084490/ruby-class-variables 4]http://stackoverflow.com/questions/2084490/ruby-class-variables 
[http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 5]http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 
[http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods 6]http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods/ 
[http://www.rubyist.net/~slagell/ruby/instancevars.html 7]http://www.rubyist.net/~slagell/ruby/instancevars.html 
[http://www.rubyist.net/~slagell/ruby/accessors.html 8]http://www.rubyist.net/~slagell/ruby/accessors.html

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T01:46:52Z

Msudhee: /* References */

==Introduction==

===What is Object Oriented Programming?===
Wikipedia defines [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming (OOP)] as a programming paradigm that uses objects and their interactions to design applications and computer programs.
The primary programming concepts in OOP are:
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] - hiding all but the necessary data about an object in order to reduce complexity and increase efficiency.
*[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism ] - characteristic of being able to assign a different meaning to a particular function or "operator" in different contexts.
*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] - hide the implementation details of a class from other objects.
*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance] - form new classes using existing class definitions.
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is pure object-oriented language! i.e to Ruby, everything appears as an object. Every value in Ruby is an object, even the most primitive things: strings, numbers and even true and false. Ruby is so true to being object oriented that even a class is an object that is an instance of the ‘C’lass class.
In object-oriented code, we model concepts from the real world. During this modeling process you’ll different items to be represented. In Ruby, classes are defined to represent each of these items. Objects, which are instances of a class are nothing but different kinds of that item in terms of Ruby.

Now let’s look at some basic object oriented concepts in Ruby.

==Object==
[http://en.wikipedia.org/wiki/Object_(computer_science) Objects] are basic building blocks of a Ruby OOP program. Every basic item, when being represented, can be given its own properties and actions. Object-oriented programming calls properties by the name instance variables , whose names starts with @, and actions are known as methods.
A '''class''' is a template for an '''object''', and an '''object''' is an instance of the class. Objects are created by calling a constructor, a special method associated with a class. The constructor in Ruby is called initialize. Constructors do not return any values. Constructors can be parameterized too, to contain values that initialize the instance method. This is also called the '''initialize method'''. For example, 

Example: 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

account1 = Account.new 10

----

Here the constructor, when invoked will create an object of type ‘Account’ represented by the name account1nitialize the instance variable balance to 10. Each object gets its own set of instance variables.
Different objects communicate together through methods. Each object can receive messages, send messages and process data.

==Class==
A [http://www.ruby-doc.org/core-1.9.3/Class.html class] can be defined as a blueprint for a data type. It defines the state and behaviour of the class, that is, what an object of the class will consist of and what operations can be performed on such an object. A class represents the real world entity.

A class definition starts with the keyword class followed by the class name and is delimited with an end. For example we defined the BankAccount class using the keyword class as follows:

Example: 
----
class BankAccount 
attr_accessor :name, :balance 
def deposit(amt) 
@balance+=amt 
end 
end 

----
The class BankAccount, contains instance variables(defined later) name and balance that defines the state of an object of the class and a method deposit that defines the behavior.
Here, the name (BankAccount) must begin with a capital letter. By convention, names that contain more than one word run together with each word capitalized and no separating characters (CamelCase).

==Inheritance==
One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. The newly formed class is called the derived class or the sub-class, the class that we derive from is called base class or the super-class.
Although, inheritance provides an opportunity to reuse the code functionality and hasten implementation time, Ruby does not support Multiple level of inheritances. However, this functionality can be implemented using another feature called [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html mixins]. A mixin is like a specialized implementation of multiple inheritance in which only the interface portion is inherited.
The syntax for extending a class is by adding a “<” character and the name of the superclass to the class statement.
Example : 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

class SharedAccount < Account 
# adding another instance variable “common_fund” and an instance method “share” 

def share(common=0) # optional argument 
@common_fund = common 
print "Total Balance : #{@balance + @common_fund}" 
end 
end 
a = SharedAccount.new 10 
a.share(20) 
 
Output : Total Balance : 30 


----
The above, will make use of both base class and derived class instance variables.

==Instance Variables and Accessor Methods==

===Instance Variables===
An instance variable begins with the symbol “@” in Ruby. It is different from a local variable because its scope is confined to the object to which self refers. Instance variables are invisible outside of the object. The only way we can access them or observer them is by writing methods to get or set the value of them. Instance variables have the value “nil” until they are initialized.
Instance variables do not need to be declared. In fact we can also access instance variables without declaring or initializing it, this will not raise an exception. However a warning will be issued if we run it using the –w switch.
Every instance variable is dynamically appended to an object in the first assignment. 
Example: 
----
@balance -> instance variable
----
===Accessor Methods===
As stated previously, we cannot access instance variables from anywhere outside an object. Hence we need to define methods to access them. They are generally called as getter and setter methods.
The getter method is used to return the value of the instance variable. It would be defined as: 

Example: 
----
def balance 
@balance 
end 
----

The setter method is used to set the value of the instance variable. Setter methods always end with the “=” sign. It would be defined as: 
Example: 
----
def balance= (bal) 
@balance = bal 
end 
----

Instead of writing getter and setter methods for each class, we can use the attr_accessor function. The attr_accessor is a method call which uses metaprogramming to generate the getter and setter methods dynamically at run time. 

Example: 
----
attr_accessor :balance
----

This is equivalent to
----
 
def balance 
@balance 
end 
def balance= (bal) 
@balance = bal 
end 
----

We can also generate getter and setter methods for more than one instance variable. 
----
 
attr_accessor :balance, :new_balance
----

We can also use attr_reader if we only want to generate the getter function. Similarly we can use the method call attr_writer for generating just the setter function.

==Instance Methods==
Instance methods work with instances of the class. So in order to use instance methods we have to create an instance. 

Example: 
----
def deposit 
@balance += amount 
end 
----

You can include the definition of an instance method within the class like this:
Example: 
----
Class SavingsAccount < Account 
def deposit @balance += amount end 
end 
----

Or you can also define it later. Since Ruby is a dynamic programming language we are allowed to reopen a class and add methods to it. For instance to add the deposit method after closing the class:
----

Class SavingsAccount < Account 
end 
SAcc = SavingsAccount.new 
def SAcc.deposit 
@balance += amount 
end 
----
The save and update methods used in Rails are actually instance methods.

There are two types of methods in Ruby: Safe methods and destructive methods. They are called as safe and destructive depending on whether they modify the input parameters passed to them. The destructive methods end with the “!” symbol, so that they can warn the programmer when he is writing the code. “<<” is another example of a destructive method.

==Class Variables and Class Methods==
===Class Variables===
A class variable begins with the symbol “@@” in Ruby. Once we define a class variable it is set for the class and all of its subclasses. 
Example:
----
@@bank_name = “MyBank.com”
----
We need to add a getter method to access the class variable from outside the class. This would look like:
----
def self.bank_name 
@@bank_name 
end 
puts SavingsAccount.bank_name => “MyBank.com” 
----

===Class Methods===
Class methods are equivalent to static methods in Java. Class methods only exist in the class that defined them. So we cannot call a class method with an instance variable, because the class method does not exist in the instance variable.
There are multiple ways of defining class methods. 
*def SavingsAccount.bank_name 
*def self.bank_name 
*class << self def bank_name 

In Method 1 we use the class name followed by a dot followed by the class method name. In Method 2 we use the keyword [http://stackoverflow.com/questions/6669527/use-of-ruby-self-keyword self]. In Ruby self gives you access to the current object, when defined within a class it refers to the current class. Method 2 is frequently used to define a class method.
In the third method we are actually building an anonymous class for the current object (referred by self) using the << notation. We are doing exactly what we did in Method 2, it is uncommon to see the use of Method 3.

==Further Reading==

==References==
[http://en.wikipedia.org/wiki/Object-oriented_programming1]http://en.wikipedia.org/wiki/Object-oriented_programming 
[http://www.ruby-doc.org/docs/ProgrammingRuby/html/2]http://www.ruby-doc.org/docs/ProgrammingRuby/html/ 
[http://www.rubyfleebie.com/understanding-class-methods-in-ruby/3]http://www.rubyfleebie.com/understanding-class-methods-in-ruby/ 
[4 http://stackoverflow.com/questions/2084490/ruby-class-variables]http://stackoverflow.com/questions/2084490/ruby-class-variables 
[5 http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/]http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 
[6 http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods]http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods/ 
[7 http://www.rubyist.net/~slagell/ruby/instancevars.html]http://www.rubyist.net/~slagell/ruby/instancevars.html 
[8 http://www.rubyist.net/~slagell/ruby/accessors.html]http://www.rubyist.net/~slagell/ruby/accessors.html

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T01:44:05Z

Msudhee: /* References */

==Introduction==

===What is Object Oriented Programming?===
Wikipedia defines [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming (OOP)] as a programming paradigm that uses objects and their interactions to design applications and computer programs.
The primary programming concepts in OOP are:
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] - hiding all but the necessary data about an object in order to reduce complexity and increase efficiency.
*[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism ] - characteristic of being able to assign a different meaning to a particular function or "operator" in different contexts.
*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] - hide the implementation details of a class from other objects.
*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance] - form new classes using existing class definitions.
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is pure object-oriented language! i.e to Ruby, everything appears as an object. Every value in Ruby is an object, even the most primitive things: strings, numbers and even true and false. Ruby is so true to being object oriented that even a class is an object that is an instance of the ‘C’lass class.
In object-oriented code, we model concepts from the real world. During this modeling process you’ll different items to be represented. In Ruby, classes are defined to represent each of these items. Objects, which are instances of a class are nothing but different kinds of that item in terms of Ruby.

Now let’s look at some basic object oriented concepts in Ruby.

==Object==
[http://en.wikipedia.org/wiki/Object_(computer_science) Objects] are basic building blocks of a Ruby OOP program. Every basic item, when being represented, can be given its own properties and actions. Object-oriented programming calls properties by the name instance variables , whose names starts with @, and actions are known as methods.
A '''class''' is a template for an '''object''', and an '''object''' is an instance of the class. Objects are created by calling a constructor, a special method associated with a class. The constructor in Ruby is called initialize. Constructors do not return any values. Constructors can be parameterized too, to contain values that initialize the instance method. This is also called the '''initialize method'''. For example, 

Example: 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

account1 = Account.new 10

----

Here the constructor, when invoked will create an object of type ‘Account’ represented by the name account1nitialize the instance variable balance to 10. Each object gets its own set of instance variables.
Different objects communicate together through methods. Each object can receive messages, send messages and process data.

==Class==
A [http://www.ruby-doc.org/core-1.9.3/Class.html class] can be defined as a blueprint for a data type. It defines the state and behaviour of the class, that is, what an object of the class will consist of and what operations can be performed on such an object. A class represents the real world entity.

A class definition starts with the keyword class followed by the class name and is delimited with an end. For example we defined the BankAccount class using the keyword class as follows:

Example: 
----
class BankAccount 
attr_accessor :name, :balance 
def deposit(amt) 
@balance+=amt 
end 
end 

----
The class BankAccount, contains instance variables(defined later) name and balance that defines the state of an object of the class and a method deposit that defines the behavior.
Here, the name (BankAccount) must begin with a capital letter. By convention, names that contain more than one word run together with each word capitalized and no separating characters (CamelCase).

==Inheritance==
One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. The newly formed class is called the derived class or the sub-class, the class that we derive from is called base class or the super-class.
Although, inheritance provides an opportunity to reuse the code functionality and hasten implementation time, Ruby does not support Multiple level of inheritances. However, this functionality can be implemented using another feature called [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html mixins]. A mixin is like a specialized implementation of multiple inheritance in which only the interface portion is inherited.
The syntax for extending a class is by adding a “<” character and the name of the superclass to the class statement.
Example : 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

class SharedAccount < Account 
# adding another instance variable “common_fund” and an instance method “share” 

def share(common=0) # optional argument 
@common_fund = common 
print "Total Balance : #{@balance + @common_fund}" 
end 
end 
a = SharedAccount.new 10 
a.share(20) 
 
Output : Total Balance : 30 


----
The above, will make use of both base class and derived class instance variables.

==Instance Variables and Accessor Methods==

===Instance Variables===
An instance variable begins with the symbol “@” in Ruby. It is different from a local variable because its scope is confined to the object to which self refers. Instance variables are invisible outside of the object. The only way we can access them or observer them is by writing methods to get or set the value of them. Instance variables have the value “nil” until they are initialized.
Instance variables do not need to be declared. In fact we can also access instance variables without declaring or initializing it, this will not raise an exception. However a warning will be issued if we run it using the –w switch.
Every instance variable is dynamically appended to an object in the first assignment. 
Example: 
----
@balance -> instance variable
----
===Accessor Methods===
As stated previously, we cannot access instance variables from anywhere outside an object. Hence we need to define methods to access them. They are generally called as getter and setter methods.
The getter method is used to return the value of the instance variable. It would be defined as: 

Example: 
----
def balance 
@balance 
end 
----

The setter method is used to set the value of the instance variable. Setter methods always end with the “=” sign. It would be defined as: 
Example: 
----
def balance= (bal) 
@balance = bal 
end 
----

Instead of writing getter and setter methods for each class, we can use the attr_accessor function. The attr_accessor is a method call which uses metaprogramming to generate the getter and setter methods dynamically at run time. 

Example: 
----
attr_accessor :balance
----

This is equivalent to
----
 
def balance 
@balance 
end 
def balance= (bal) 
@balance = bal 
end 
----

We can also generate getter and setter methods for more than one instance variable. 
----
 
attr_accessor :balance, :new_balance
----

We can also use attr_reader if we only want to generate the getter function. Similarly we can use the method call attr_writer for generating just the setter function.

==Instance Methods==
Instance methods work with instances of the class. So in order to use instance methods we have to create an instance. 

Example: 
----
def deposit 
@balance += amount 
end 
----

You can include the definition of an instance method within the class like this:
Example: 
----
Class SavingsAccount < Account 
def deposit @balance += amount end 
end 
----

Or you can also define it later. Since Ruby is a dynamic programming language we are allowed to reopen a class and add methods to it. For instance to add the deposit method after closing the class:
----

Class SavingsAccount < Account 
end 
SAcc = SavingsAccount.new 
def SAcc.deposit 
@balance += amount 
end 
----
The save and update methods used in Rails are actually instance methods.

There are two types of methods in Ruby: Safe methods and destructive methods. They are called as safe and destructive depending on whether they modify the input parameters passed to them. The destructive methods end with the “!” symbol, so that they can warn the programmer when he is writing the code. “<<” is another example of a destructive method.

==Class Variables and Class Methods==
===Class Variables===
A class variable begins with the symbol “@@” in Ruby. Once we define a class variable it is set for the class and all of its subclasses. 
Example:
----
@@bank_name = “MyBank.com”
----
We need to add a getter method to access the class variable from outside the class. This would look like:
----
def self.bank_name 
@@bank_name 
end 
puts SavingsAccount.bank_name => “MyBank.com” 
----

===Class Methods===
Class methods are equivalent to static methods in Java. Class methods only exist in the class that defined them. So we cannot call a class method with an instance variable, because the class method does not exist in the instance variable.
There are multiple ways of defining class methods. 
*def SavingsAccount.bank_name 
*def self.bank_name 
*class << self def bank_name 

In Method 1 we use the class name followed by a dot followed by the class method name. In Method 2 we use the keyword [http://stackoverflow.com/questions/6669527/use-of-ruby-self-keyword self]. In Ruby self gives you access to the current object, when defined within a class it refers to the current class. Method 2 is frequently used to define a class method.
In the third method we are actually building an anonymous class for the current object (referred by self) using the << notation. We are doing exactly what we did in Method 2, it is uncommon to see the use of Method 3.

==Further Reading==

==References==
[http://en.wikipedia.org/wiki/Object-oriented_programming1]http://en.wikipedia.org/wiki/Object-oriented_programming 
[http://www.ruby-doc.org/docs/ProgrammingRuby/html/2]http://www.ruby-doc.org/docs/ProgrammingRuby/html/ 
[http://www.rubyfleebie.com/understanding-class-methods-in-ruby/3]http://www.rubyfleebie.com/understanding-class-methods-in-ruby/ 
[4http://stackoverflow.com/questions/2084490/ruby-class-variables]http://stackoverflow.com/questions/2084490/ruby-class-variables 
[5http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/]http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 
[6http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods]http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods/ 
[7http://www.rubyist.net/~slagell/ruby/instancevars.html]http://www.rubyist.net/~slagell/ruby/instancevars.html 
[8http://www.rubyist.net/~slagell/ruby/accessors.html]http://www.rubyist.net/~slagell/ruby/accessors.html

CSC/ECE 517 Fall 2012/ch1b 1w56 ms

2012-10-11T01:39:18Z

Msudhee: /* Class Methods */

==Introduction==

===What is Object Oriented Programming?===
Wikipedia defines [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming (OOP)] as a programming paradigm that uses objects and their interactions to design applications and computer programs.
The primary programming concepts in OOP are:
*[http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] - hiding all but the necessary data about an object in order to reduce complexity and increase efficiency.
*[http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism ] - characteristic of being able to assign a different meaning to a particular function or "operator" in different contexts.
*[http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] - hide the implementation details of a class from other objects.
*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance] - form new classes using existing class definitions.
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is pure object-oriented language! i.e to Ruby, everything appears as an object. Every value in Ruby is an object, even the most primitive things: strings, numbers and even true and false. Ruby is so true to being object oriented that even a class is an object that is an instance of the ‘C’lass class.
In object-oriented code, we model concepts from the real world. During this modeling process you’ll different items to be represented. In Ruby, classes are defined to represent each of these items. Objects, which are instances of a class are nothing but different kinds of that item in terms of Ruby.

Now let’s look at some basic object oriented concepts in Ruby.

==Object==
[http://en.wikipedia.org/wiki/Object_(computer_science) Objects] are basic building blocks of a Ruby OOP program. Every basic item, when being represented, can be given its own properties and actions. Object-oriented programming calls properties by the name instance variables , whose names starts with @, and actions are known as methods.
A '''class''' is a template for an '''object''', and an '''object''' is an instance of the class. Objects are created by calling a constructor, a special method associated with a class. The constructor in Ruby is called initialize. Constructors do not return any values. Constructors can be parameterized too, to contain values that initialize the instance method. This is also called the '''initialize method'''. For example, 

Example: 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

account1 = Account.new 10

----

Here the constructor, when invoked will create an object of type ‘Account’ represented by the name account1nitialize the instance variable balance to 10. Each object gets its own set of instance variables.
Different objects communicate together through methods. Each object can receive messages, send messages and process data.

==Class==
A [http://www.ruby-doc.org/core-1.9.3/Class.html class] can be defined as a blueprint for a data type. It defines the state and behaviour of the class, that is, what an object of the class will consist of and what operations can be performed on such an object. A class represents the real world entity.

A class definition starts with the keyword class followed by the class name and is delimited with an end. For example we defined the BankAccount class using the keyword class as follows:

Example: 
----
class BankAccount 
attr_accessor :name, :balance 
def deposit(amt) 
@balance+=amt 
end 
end 

----
The class BankAccount, contains instance variables(defined later) name and balance that defines the state of an object of the class and a method deposit that defines the behavior.
Here, the name (BankAccount) must begin with a capital letter. By convention, names that contain more than one word run together with each word capitalized and no separating characters (CamelCase).

==Inheritance==
One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. The newly formed class is called the derived class or the sub-class, the class that we derive from is called base class or the super-class.
Although, inheritance provides an opportunity to reuse the code functionality and hasten implementation time, Ruby does not support Multiple level of inheritances. However, this functionality can be implemented using another feature called [http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html mixins]. A mixin is like a specialized implementation of multiple inheritance in which only the interface portion is inherited.
The syntax for extending a class is by adding a “<” character and the name of the superclass to the class statement.
Example : 
----
class Account 
# constructor used when Account.new(...) called 
def initialize(starting_balance=0) # optional argument 
@balance = starting_balance 
end 
end 

class SharedAccount < Account 
# adding another instance variable “common_fund” and an instance method “share” 

def share(common=0) # optional argument 
@common_fund = common 
print "Total Balance : #{@balance + @common_fund}" 
end 
end 
a = SharedAccount.new 10 
a.share(20) 
 
Output : Total Balance : 30 


----
The above, will make use of both base class and derived class instance variables.

==Instance Variables and Accessor Methods==

===Instance Variables===
An instance variable begins with the symbol “@” in Ruby. It is different from a local variable because its scope is confined to the object to which self refers. Instance variables are invisible outside of the object. The only way we can access them or observer them is by writing methods to get or set the value of them. Instance variables have the value “nil” until they are initialized.
Instance variables do not need to be declared. In fact we can also access instance variables without declaring or initializing it, this will not raise an exception. However a warning will be issued if we run it using the –w switch.
Every instance variable is dynamically appended to an object in the first assignment. 
Example: 
----
@balance -> instance variable
----
===Accessor Methods===
As stated previously, we cannot access instance variables from anywhere outside an object. Hence we need to define methods to access them. They are generally called as getter and setter methods.
The getter method is used to return the value of the instance variable. It would be defined as: 

Example: 
----
def balance 
@balance 
end 
----

The setter method is used to set the value of the instance variable. Setter methods always end with the “=” sign. It would be defined as: 
Example: 
----
def balance= (bal) 
@balance = bal 
end 
----

Instead of writing getter and setter methods for each class, we can use the attr_accessor function. The attr_accessor is a method call which uses metaprogramming to generate the getter and setter methods dynamically at run time. 

Example: 
----
attr_accessor :balance
----

This is equivalent to
----
 
def balance 
@balance 
end 
def balance= (bal) 
@balance = bal 
end 
----

We can also generate getter and setter methods for more than one instance variable. 
----
 
attr_accessor :balance, :new_balance
----

We can also use attr_reader if we only want to generate the getter function. Similarly we can use the method call attr_writer for generating just the setter function.

==Instance Methods==
Instance methods work with instances of the class. So in order to use instance methods we have to create an instance. 

Example: 
----
def deposit 
@balance += amount 
end 
----

You can include the definition of an instance method within the class like this:
Example: 
----
Class SavingsAccount < Account 
def deposit @balance += amount end 
end 
----

Or you can also define it later. Since Ruby is a dynamic programming language we are allowed to reopen a class and add methods to it. For instance to add the deposit method after closing the class:
----

Class SavingsAccount < Account 
end 
SAcc = SavingsAccount.new 
def SAcc.deposit 
@balance += amount 
end 
----
The save and update methods used in Rails are actually instance methods.

There are two types of methods in Ruby: Safe methods and destructive methods. They are called as safe and destructive depending on whether they modify the input parameters passed to them. The destructive methods end with the “!” symbol, so that they can warn the programmer when he is writing the code. “<<” is another example of a destructive method.

==Class Variables and Class Methods==
===Class Variables===
A class variable begins with the symbol “@@” in Ruby. Once we define a class variable it is set for the class and all of its subclasses. 
Example:
----
@@bank_name = “MyBank.com”
----
We need to add a getter method to access the class variable from outside the class. This would look like:
----
def self.bank_name 
@@bank_name 
end 
puts SavingsAccount.bank_name => “MyBank.com” 
----

===Class Methods===
Class methods are equivalent to static methods in Java. Class methods only exist in the class that defined them. So we cannot call a class method with an instance variable, because the class method does not exist in the instance variable.
There are multiple ways of defining class methods. 
*def SavingsAccount.bank_name 
*def self.bank_name 
*class << self def bank_name 

In Method 1 we use the class name followed by a dot followed by the class method name. In Method 2 we use the keyword [http://stackoverflow.com/questions/6669527/use-of-ruby-self-keyword self]. In Ruby self gives you access to the current object, when defined within a class it refers to the current class. Method 2 is frequently used to define a class method.
In the third method we are actually building an anonymous class for the current object (referred by self) using the << notation. We are doing exactly what we did in Method 2, it is uncommon to see the use of Method 3.

==References==
[1]http://en.wikipedia.org/wiki/Object-oriented_programming 
[2]http://www.ruby-doc.org/docs/ProgrammingRuby/html/ 
[3]http://www.rubyfleebie.com/understanding-class-methods-in-ruby/ 
[4]http://stackoverflow.com/questions/2084490/ruby-class-variables 
[5]http://railstips.org/blog/archives/2009/05/11/class-and-instance-methods-in-ruby/ 
[6]http://railsguru.org/2010/04/quick-ruby-tutorials-3-class-and-instance-methods/ 
[7]http://www.rubyist.net/~slagell/ruby/instancevars.html 
[8]http://www.rubyist.net/~slagell/ruby/accessors.html