Interview Questions and Answers

1. Ruby on Rails is an open source full-stack web application framework written in the Ruby Programming Language. Rails is capable of gathering information using pages and applications from the web server and can interact with a database and can retrieve information from the database.

• This is a simple question based on complex concept. Here�s your chance to show off your theoretical knowledge and demonstrate that you can have an in depth conversation on class hierarchies, inheritance, methods, encapsulation, polymorphism, and more.

• Explaining this could take an hour or a few minutes � there�s no single correct answer here, save from being able to demonstrate your familiarity with OOP concepts.

• Class variables are created with the prefix �@@� and are shared by all objects in a class.

• Instance variables are created with the prefix �@� and belong to a single object within a class.

Class variables are created using the @@ prefix to denote the variable as class level. 

It works just like any other variable, however in the case of inheritance it works more like a static variable that is accessed across all variable instances.

Another example can be found here:

class DemoClass 
 @@my_var = nil
  def initialize
    @@my_var = "hello world"
  end
  def my_var
    puts @@my_var
  end
end
class Demo2Class < DemoClass
  def initialize
    @@my_var = "goodbye world"
  end
end
demo1 = DemoClass.new
demo1.my_var
demo2 = Demo2Class.new
demo2.my_var
demo1.my_var
The output would be as shown below:
hello world
goodbye world
goodbye world

Instance variables are defined using single @ symbol.

@foo = "Hello"

Within a class they can be declared as below:

class Animal
 attr_accessor :name, :age
end

Next you can query an object instance to find which instance variables it has.

anim = Animal.new
anim.instance_variables 
=> [ ]
anim.name="John"
anim.age = 3
 => [:@age, :@name] 

In the above case we did not put the @ symbol before the instance variables but it is implied. 

The �&&� and �and� are both logical and statements. They �&&� operator has higher precedence though. Here�s an example of illustrate this in more detail:

foo = 3
bar = nil
a = foo and bar
# => nil
a
# => 3
a = foo && bar
# => nil
a
# => nil

Create a new file as shown below under: config/initializers/my_constants.rb

COLORS = ['white', 'red', 'green']

By default all methods are public, except the initialize(constructor) method.

You can make methods private using this declaration within your class:

class MyClass
    def method_public_here
    end
    PRIVATE# all methods that follow will be made private: not accessible for outside objects
    def method_private_here
    end
  end

The MVC framework is an age-old architecture pattern that works very well for most applications. Rails has adopted the MVC pattern in its inherent design.

Stated Simply:

a) Model � is where the data is � the database

b) Controller � is where the logic is for the application

c) View � is where the data is used to display to the user

• Public, protected, and private.

• Public methods can be called by all objects and subclasses of the class in which they are defined in.

• Protected methods are only accessible to objects within the same class.

• Private methods are only accessible within the same instance.

• Be able to explain why this does (or doesn�t matter), and when you would want to set a method as private.

The ! indicates that the method is about to change the object itself.

Here�s an example:

foo = "A TEST STRING"  # a string called foo

foo.downcase!     # modifies foo permanently
a test string

puts foo          # prints modified foo
a test string

Similarly if you did not want the object to be changed you could have something simple like:

foo2 = "A 2nd Test String"  # a string called foo 

foo2.downcase     # modifies foo temporarily
a 2nd test string 

puts foo2 nbsp;    # prints original foo 
A 2nd Test String

The interpreter essentially invokes a separate piece of code and places it in the location. You might say it is similar to a method calling another method. Let�s understand a little bit of background about where YIELD might be useful first. 

The Rails framework encourages you to write code that is DRY (Don�t Repeat Yourself).

Developers often write common code in a central file and then they write the custom code in the specific files. Let�s say you are building a web application and you want all pages to have a common header, a common footer, the same �Welcome user-name!� message.

You can put all this common code in your application.html.erb file.

<html> .... common page title
.. standard header... 
<body> 
..common page title,
 <%= YIELD %>
..footer code can go here... </body> 
</html>

The rest of the custom code can go in your specific file. Say the page you are creating is the list of articles. Then in your implementation file you would just write the code for pulling in the articles and the final page displayed to the user would be your custom code which will be placed instead of the <%= YIELD %>code in the application.html.erb file.

An instance method can be defined dynamically with

Module#define_method(name, body),

where name is the method�s name given as a Symbol, and body is its body given as a Proc, Method, UnboundMethod, or block literal. This allows methods to be defined at runtime, in contrast to def which requires the method name and body to appear literally in the source code.

class Conjure
  def self.conjure(name, lamb)
    define_method(name, lamb)
  end
end

# Define a new instance method with a lambda as its body

Conjure.conjure(:glark, ->{ (3..5).to_a * 2 })
Conjure.new.glark #=> [3, 4, 5, 3, 4, 5]  

Module#define_method is a private method so must be called from within the class the method is being defined on. Alternatively, it can be invoked inside class_eval like so:

Array.class_eval do
  define_method(:second, ->{ self.[](1) })
end
[3, 4, 5].second #=> 4

Kernel#define_singleton_method is called with the same arguments as Module#define_method to define a singleton method on the receiver.

File.define_singleton_method(:match) do |file, pattern|
  File.read(file).match(pattern)
end
File.match('/etc/passwd',/root/) #=> #<MatchData "root">

Range is a great way to declare continuous variables. You should use it to declare arrays and other types of collections. 

range1 = (1..4).to_a
 => [1, 2, 3, 4] 
puts range1
1
2
3
4

You can also create strings in this format and it fills in the interim values automatically.

range2 = ('bar'..'bat').to_a
puts range2
bar
bas
bat

range2.each do |str|
   puts "In Loop #{str}"
end

In Loop bar
In Loop bas
In Loop bat

This one�s a tricky question. If you have a background in Java then you must know that method overloading is simply multiple methods with same name but different signatures/parameters.

In the case of Ruby method overloading is not supported. 

However, it does support the overall goal of passing variable number of parameters to the same method. You would implement it like this:

class MyClass  
  def initialize(*args)  
    if args.size < 2  || args.size > 3  
      puts 'This method takes either 2 or 3 arguments'  
    else  
      if args.size == 2  
        puts 'Found two arguments'  
      else  
        puts 'Found three arguments'  
      end  
    end  
  end  
end  

The output can be seen here:

MyClass.new([10, 23], 4, 10)  
Found three arguments
MyClass.new([10, 23], [14, 13]) 
Found two arguments

SO: You can get the same effect as method overloading but you just have to manage the number of variables inside your method itself.

Here�s an example:

module Debug
  def whoAmI?
    "I am #{self.to_s}"
  end
end

class Photo
 include Debug
end

ph = Photo.new

"I am : #<Photo:0x007f8ea218b270>"

As you can see above the class Debug and it�s method �whoamI?� were mixed-in (added) with the class Photo.

That�s why you can now create an instance of the Photo class and call the whoAmI? method.

ph.whoAmI?
 => "I am : #<Phonograph:0x007f8ea218b270>" 

Singleton means single instance. 

So, the goal of a singleton pattern is to write a class definition but only allow the creation of the single instance of that object. 

This can be achieved nicely with the singleton gem as shown below:

require 'singleton'
 class Logger
  include Singleton
  def initialize
    @log = File.open("logfile.txt", "a")
  end
  def log(msg)
    @log.puts(msg)
  end
end

Adding the singleton as a mixin to the 

Logger.instance.log('This is just a test message')

The code above will create a single instance of Logger and simply put the message in the logger file.

Singleton patterns are mostly used for DB instance, Logger instance, etc. �- cases where there should be ONE and only ONE instance of the object that is used. 

Sometimes you might like to actually hold on to the logger object and use it everywhere you can do so by the following command:

logObj = Logger.instance

Notice you cannot use the Logger.new to create an object instance because this is a singleton object and therefore calling �new� would fail.

Let�s review first what an observer pattern is all about.  

The observer pattern (sometimes known as publish/subscribe) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.

You might have used them in other programming languages as listener objects. You use them whenever a button is clicked on the screen and a method gets called automatically. 

As in the case of the singleton pattern, the observer pattern is also implemented by mixing in a module. 

In the Ruby implementation, the notifying class mixes in the Observable module, which provides the methods for managing the associated observer objects.

And, the observers must implement the update method to receive notifications.

Here�s an example. Say you want to send an SMS alert to users if a company stock drops then you can do something like this:

require "observer" 
require "observer" 
  class Ticker # Periodically fetch a stock price 
    include Observable 
 	attr_accessor :price 
    def initialize symbol, price 
      @symbol = symbol 
  	@price = price 
	end
    
	def run 
      lastPrice = nil 
      loop do 
        @price = @price+Random.rand(11) 
        print "Current price: #{price}n" 
        if @price != lastPrice 
          changed                 # notify observers 
          lastPrice = @price 
           notify_observers(Time.now, @price) 
         end
       end 
    end 
  end
 
  class Warner
     def initialize ticker  
     ticker.add_observer(self)   # all warners are observers     
  end   
end 
  
class SMSAlert < Warner     
   def update time, price       # callback for observer         
      print "--- #{time.to_s}: SMS Alert for price: #{price}n"     
   end   
end  

class EmailAlert < Warner     
   def update time, price       # callback for observer         
      print "+++ #{time.to_s}: Email Alert Price changed to #{price}n"    
   end
 end

There are two files where variables and configuration settings are stored. 

- config/environment.rb : Environment settings go here

- config/application.rb : Application level global settings go here

config.time_zone = 'Central Time (US & Canada)'
config.i18n.default_locale = :de
config.filter_parameters += [:password] # ensures that passwords are not logged

The same file is also used for configuring various environment settings such as:

config.action_mailer.smtp_settings # various email settings go here 

What is the purpose of config/environments/development.rb file?

You would specify various config settings the development environment in this file.

 config.action_controller.perform_caching = false # to enable caching

This is because you typically do not want to enable caching in the development environment. 

The same config setting in the production environment would be equal to true. 

Fire a method inside a class is very simple.

Say you have a module file trig.rb:

module Trig
  PI = 3.141592654
  def Trig.sin(x)
   # ..
  end
  def Trig.cos(x)
   # ..
  end
end

Now you simply import this module inside your class and invoke the method using the �module.method_name� syntax as shown below

require "trig"

class myclass
y = Trig.sin(Trig::PI/4)

This type of invocation ensures that the right module method gets called.

If you are inside the overridden method in the derived class then a simple call to super will call the right method in the base class

class Parent
   def try_this()
      puts "parent"
   end
end

class Child < Parent
   def try_this()
      super()
      puts "child"
   end
end

ch = Child.new
ch.try_this()

This generates the output

parent
child

Now if you just want to call the base class without calling the derived class then the best way to do that is to simply assign an alias to the parent method like this:

class Parent
  def knox
    puts 'parent'
  end
end
 
class Child < Parent
   alias_method :parent_knox, :knox
   def knox
     puts 'child'
   end
end
 
ch = Child.new
ch.parent_knox
ch.knox

This allows you to call the base class method with the alias parent_knox and the derived class method knox can be called directly.

parent
child

Scopes are nothing more than SQL scope fragments. By using these fragments one can cut down on having to write long queries each time you access content.

Say you typically access content as shown below:

@posts = Post.where("published_at IS NOT NULL AND posts.published_at <= "+ Time.now)

Ruby offers you a nice way to put the where condition inside a scope statement as shown below.

class Post < ActiveRecord::Base
  scope :published, lambda { 
    { :conditions =>
      ["posts.published_at IS NOT NULL AND posts.published_at <= ?", Time.now]
    }
  }  
  scope :recent, :order => "posts.published_at DESC"
end

Now you can simply access the published posts as: Post.published

@posts = Post.published

Also, you can access recent posts as 

@recent_posts = Post.recent

The rake tool does most of the migrations. 

It has this nifty syntax to go back one step:

rake db:rollback

If you want to rollback all the way to the beginning you would use:

rake db:reset

This would drop the database, recreate the Database and load the current schema into it

If you want to rollback multiple steps at the same time you would use:

rake db:rollback STEP=3

To rollback all the way and if you are not worried about losing the data then you can drop the database completely with purge like this:

rake db:purge

Sometimes you want to have control over how often and when the cache expires. 

Sometimes it is a good idea to have the system determine that on a logical basis. Say you have a list of product on your site and you want to reload the cache each time a new product is added/updated/deleted, then you can achieve this by using the sweeper. 

class ProductSweeper < ActionController::Caching::Sweeper
  OBSERVE PRODUCT# This sweeper is going to keep an eye on the Product model 
  # If our sweeper detects that a Product was created call this
  def after_create(product)
    expire_cache_for(product)
  end
  # If our sweeper detects that a Product was updated call this
  def after_update(product)
    expire_cache_for(product)
  end
  # If our sweeper detects that a Product was deleted call this
  def after_destroy(product)
    expire_cache_for(product)
  end
  private
  def expire_cache_for(product)
    # Expire the index page now that we added a new product
    expire_page(:controller => 'products', :action => 'index')
    # Expire a fragment
    expire_fragment('all_available_products')
  end
end

Rails offers multiple ways to cache content.

Fragment caching is my favorite because it gives you the choice to fragment to pull a portion from the cache and the remaining from a real-time DB call. 

Say you wanted to show all the orders placed on your website in real time and didn�t want to cache that part of the page, but did want to cache the part of the page which lists all products available, you could use this piece of code:

<% Order.find_recent.each do |o| %>
  <%= o.buyer.name %> bought <%= o.product.name %>
<% end %>
<% CACHE DO %>  All available products:
  <% Product.all.each do |p| %>
    <%= link_to p.name, product_url(p) %>
  <% end %>
<% end %>

Another technique that works well for static pages is page caching. This technique is often used for home pages and is super fast.

class ProductsController < ActionController
   CACHES_PAGE:index
  def index
    @products = Products.all
  end
end

Filters are methods that are called either before/after a controller action is called. 

Say a user requests a controller action such as userdashboard/index

In such a case a filter can be setup so that the UserDashboard/index page is only accessible to loggedin users by adding the following lines towards the beginning of the page:

class UserDashboardController < ApplicationController

  before_filter :confirm_logged_in,  :except => [:login, :attempt_login, :logout]
  
  def index
      ....
  end

  def login
      ....
  end

  def attempt_login
      ....
  end

  def logout
      ....
  end

end  

In the code above the condition �confirm_logged_in� is checked before all actions, except login, logout & attempt_login. 

After filters (after_filter) are not used too much but they have the effect of executing some code after a particular action has completed. 

Think of them like triggers that get executed automatically � just like a database trigger. 

Once a request comes into the Rails stack, it goes to the routes table to determine which controller and action should be called. 

Once a controller action is determined the request is routed to the controller and it does the needed processing by connecting with the DB if needed and then it sends control to the View to render the output. 

So, really the flow for Rails goes somewhat like this:

Customer-> Routes-> Controller -> Model(DB) -> Controller -> View -> Customer

Routing is fun. If you have ever dealt with IIS you will fall in love with RESTful routing. Here�s how it works. 

Say you want your users to have access to certain pages such as:

/photos/new

/photos/1/edit

/photos/1

And, you want the right controller to get called.

And, you want the right view to get rendered.

All this is made possible with a single entry in the routes.rb file.

In Rails, a resourceful route provides a mapping between HTTP verbs and URLs to controller actions. By convention, each action also maps to particular CRUD operations in a database. The single entry in the routing file creates seven different routes in your application, all mapping to the Photos controller:

GET-/photos

GET-/photos/new

POST - /photos

GET -  /photos/:id

GET -  /photos/:id/edit

PUT - /photos/:id

DELETE - /photos/:id

rake routes -- will display all routes for an application.

Nowadays most email clients support HTML email, however there are still some old Blackberry phones that prefer emails the �ol text way. 

Therefore it is important to send emails both as HTML and text. This technique is called multi-part emails. 

The ActionMailer class (included in Rails 3.0) does a great job of sending both text and HTML emails out to the end user at the same time. 

By default Rails sending an email with plain/text content_type, for example:

# app/models/notifier.rb
def send_email(email)
  subject       email.subject
  from          email.from
  recipients    email.recipients
  sent_on       Time.now
  body          :email => email
end

Next let�s update the view in : app/views/notifier/send_email.html.erb

Welcome to here: 

The sent email is a plain text email

Date: Thu, 5 Aug 2010 16:38:07 +0800
From: RailsBP 
To: flyerhzm@gmail.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8

Welcome: http://rails-bestpractices.com

The link url is just displayed as a plain text because of the email content_type.

TEXT/HTML

If we want the email clients to display link url as html format, we should change the content_type to text/html in the app/models/notifier.rb file

def send_email(email)
  subject          email.subject
  from             email.from
  recipients       email.recipients
  sent_on          Time.now
  content_type     "text/html"
  body             :email => email
end

Now the sent email is a html formatted email

Date: Thu, 5 Aug 2010 17:32:27 +0800
From: RailsBP 
To: flyerhzm@gmail.com
Mime-Version: 1.0
Content-Type: text/html; charset=utf-8

Welcome: http://rails-bestpractices.com

Now the email client can display the link url correctly with html format.

The email header looks somewhat like this:

Content-Type: multipart/alternative;
boundary="----=_NextPart_000_002C_01BFABBF.4A7D6BA0"
Content-Type: multipart/alternative tells the e-mail program to expect different parts to follow, separated by a boundary which specified in quotation marks. Actually the boundary could be anything, though hyphens, equal signs, and underscores insure that the e-mail program won't try to display this boundary to the recipient.
------=_NextPart_000_002C_01BFABBF.4A7D6BA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Layouts are partial ruby/html files that are used to render the content pages. 

There are placed in the folder: app/views/layouts

Items that you would typically put in this folder are things like headers/footers, navigation elements, etc.

Here�s a sample layout file: /app/views/layout/application.html.erb

<html lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Learning System | <%= @page_title || 'Admin Area' %></title>
    <meta name="author" content="Anil Punjabi">
    <%= stylesheet_link_tag('public', 'admin', :media => 'all') %>
    <%= javascript_include_tag('application') %>
  </head>
  <body>
    <div id="header">
      <h1>Learning System</h1>
    </div>
    <div id="main">
      <% if !flash[:notice].blank? %>
      <div class="notice">
        <%= flash[:notice] %>
      </div>
      <% end %>
      <div id="content">
        <%= yield %>
      </div>
    </div>
    <div id="footer">
      <p id="copyright">© / Anil Punjabi</p>
    </div>
  </body>
</html>

Rake is a popular ruby gem that makes the job of running tasks simpler. 

Rake is most often used for DB tasks, but it can be used for m

The common DB commands are:

rake db:migrate
rake db:reset

You can use cron to schedule rake tasks. 

Sometimes you would create a dataloader.rake file and put it in the lib/tasks folder so that it can be used to populate the database on startup.

Eager loading is a great optimization strategy to reduce the number of queries that are made against the DB.

Say you are finding 10 employees and then you are looking for their post codes. Then your query would appear something like this:

clients = Client.limit(10)
clients.each do |client|
  puts client.address.postcode
end

This may seem fine at first look but really this implementation leaves much to be desired. It makes 11 DB calls just to get the results.

Now you can optimize this query by making a slight change in the request like this:

clients = Client.includes(:address).limit(10)
clients.each do |client|
  puts client.address.postcode
end 

This new request makes two SQL calls like this:

SELECT * FROM clients LIMIT 10
SELECT addresses.* FROM addresses
    WHERE (addresses.client_id IN (1,2,3,4,5,6,7,8,9,10))

Validation means checking to see if data  is good before it is stored in the database.

During signups and other such user input cases you want to check and be sure that the data is validated. In the past developers would often put this type of validation logic as triggers in the database.  

In an MVC architecture one can do validations at each level. 

You can do validations in the controllers but it is usually a good idea to keep your controllers skinny.

Views suffer from the javascript limitation because javascript can be disabled on the client side so they are not completely reliable.

The best way to manage validation is to put it in the model code. This model code is really the closest as you can be to the database and works very well for Rails applications.

Here are a few validation examples:

class Person < ActiveRecord::Base
  validates :name, :length => { :minimum => 2 }
  validates :points, :numericality => { :only_integer => true }  # only integer
  validates :age,  :numericality => { :greater_than => 18 } # greater than 18
  validates :email, :uniqueness => true
  validates :email, :confirmation => true  # this is to validate that the two email fields are identical
  validates :email_confirmation, :presence => true # this is to validate that the email confirmation field is not nil

In your view template you may use something like this:

 <%= text_field :person, :email %> <%= text_field :person, :email_confirmation %>

Now custom validations takes it to the next step.

Say you want to confirm that the data meets certain criteria 

Flash  is simply a way to pass some value to the next action. 

Anything you place in the flash will be exposed to the very next action and then cleared out.

Here�s an example:

def destroy

 section = Section.find(params[:id])       
 section.destroy       
 FLASH[:NOTICE] = "SECTION DESTROYED."      
 redirect_to(:action => 'list', :page_id => @page.id)     

end

Then wherever you want to use the flash you can write this code. I often put this snippet in the application.html.erb file, somewhere towards the top:

   <% if !flash[:notice].blank? %>         
         <div class="notice">   
         <%= flash[:notice] %>

bundle install

Ruby ships with i18n which is an internationalization gem. 

You need to create locale files and save them under the config/locales directory as:

en.yml

es.yml

fr.yml

The keys should match for each of these files. 

en:   main_page:     hello: “Hello”     welcome: “Welcome to   My Company” es:   main_page:     hello: “Hola”     welcome: “Bienvenido a Mi Empresa” fr:   main_page:     hello: “Salut”     welcome: “Bienvenue �  Mon Entreprise�

� In your code you would need to specify that the text would be locale specific. So change it to something like this:

.content   %h1     = t("main_page.hello")  
 %p     = t("main_page.welcome")

Then you have to select the actual locale.

Devise works great with Rails. 

It supports OAuth authentication and therefore integrates nicely with Facebook. 

Sunspot supports full-text search capability and uses Solr as the back-end search engine to do so. 

You would include these two plugins in your gem file as shown below:

gem 'sunspot_rails' 
gem 'sunspot_solr' 

A gem is just ruby code. It is installed on a machine and it�s available for all ruby applications running on that machine.

Rails, rake, json, rspec � are all examples of gems. 

Plugin is also ruby code but it is installed in the application folder and only available for that specific application. 

Sitemap-generator, etc.

In general, since Rails works well with gems you will find that you would be mostly integrating with gem files and not plugins in general. Most developers release their libraries as gems. 

If you are using acts_as_solr for your search you will be able to use multi_solr_search to enable search across multiple models. 

Also, you can configure Sunspot/Solr to support search across multiple models.

Sphinx, another powerful search server can be used to search across multiple models and it works great. 

Paperclip is the best solution to manage file uploads to a server.

It can also help you with multiple file uploads and associate it with ActiveRecord.

There are also good examples online that show how you can make rotating sliders with the paperclip images.

Another nice solution is using carrier_wave gem. 

The nice thing about carrier_wave is that it has good documentation on how to integrate with S3, Google & Rackspace for file storage.

You can achieve the same file storage capability with Paperclip as well though. 

The simplest way to do this is to use the gem FriendlyID.

It gives you the ability to specify a friendly URL for pages so that instead of the standard page URLs like:

http://mysite.com/page/1

You can build pages such as:

http://mysite.com/page/my-awesome-page-about-articles-and-content

You can use the Headliner plugin for adding page titles.

You can use the MetaMagic plugin to add meta tags.

Gretel is a great plugin to introduce breadcrumbs in your Rails application.

Another very simple implementation is breadcrumb_on_rails.

Yes Rails gives you complete freedom to use all traditional means of scaling an application. Things like memcached, caching full pages, caching fragments are all supported. 

You can use any standard CDN to serve your media and static content as well. 

Database scaling using sharding is supported. 

Finally heroku makes your life easier by giving you the flexibility to scale up/down based on your need. Mostly websites have a peak time during which you need more servers and then there is a sleep time. Heroku makes that on-demand scaling process simpler. Companies such as HireFireApp.com makes the autoscale process easier.

heroku makes deployment easy.

Things that I sometimes run into are:

> Mismatched gem versions between local and production environment

> Some lessons learned:

�� Use image_tag helper each time

�� Specify root path in ENV variable

�� Configure assets pipeline by setting: config.assets.enabled = true in the config/application.rb file

Configure Capistrano script to precompile assets 

Rails already has the logic built into it to prevent SQL injection attacks if you follow the right syntax. 

Say you are trying to authenticate a user based on their login and password you might be tempted to use a syntax as below:

User.first("login = '#{params[:name]}' AND password = '#{params[:password]}'")

If an attacker enters � OR �1�=�1 as the name, and � OR �2�>�1 as the password, the resulting SQL query will be:

 SELECT * FROM users WHERE login = '' OR '1'='1' AND password = '' OR '2'>'1' LIMIT 1 

This will simply find the first record in the database, and grants access to this user.

To prevent this type of SQL injection simply use the following format.

  User.where("login = ? AND password = ?", entered_user_name, entered_password).first

OR

User.where(:login => entered_user_name, :password => entered_password).first

Rails has a lot of in-built capabilities to deal with common web-security issues. 

> SQL Injection

> Cross-Site 

> Session fixation and Session hijacking

> Captcha