1. This project doesn’t need to let people sign up.
2. There’s no need to send password recovery instructions
3. Much of the data entry will be done with a mobile device connecting to the app’s REST-style XML API.

Something like Authlogic, or even Restful Authentication seems like overkill for something this simple. Many Rails developers are probably used to their solutions because many Rails projects are more complex than this. In the spirit of keeping things simple, I’m going to show you how to do authentication of users without any plugins, the way we used to do it in 2005. (For those of you that have been working with Rails as long as me, this will be a good refresher for you. When was the last time you hand-rolled your authentication solution?)

Back To Basic (Authentication, that is)

Since Rails 2.0, Basic Authentication has been an option, as Ryan Bates explains in Railscast #82. We’ll use that and a basic user model to authenticate our users.

First, generate a user mode with login and a hashed password fields. I’m not going to do any salting here, as it’s not necessary. If you want it, you should be able to add it easily.

ruby script/generate model User login:string hashed_password:string

Now we need to modify the User model to do the password encryption.

First, set up the validations and the attribute accessors for the password and password_confirmation fields.

  validates_presence_of :login
  validates_confirmation_of :password
  attr_accessor :password

Next, be a good developer and write a unit test for hashing the password.

  test "should create a user with a hashed password" do
    u = User.create(:login => "homer",
                 :email =>"homer",
                 :password => "1234",
                 :password_confirmation => "1234")
    u.reload # (make sure it saved!)            
    assert_not_nil u.hashed_password
  end

Prepare your test database

rake db:test:clone

rake test:units

With the test in place, write the code to encrypt the password on save. Add the SHA1 digest library at the top of your class:

require 'digest/sha1'

Then add the before filter and an encryption method:

  before_save :encrypt_password
 
  def encrypt_password
    unless self.password.blank?
      self.hashed_password = Digest::SHA1.hexdigest(self.password.to_s)
      self.password = nil
    end
    return true 
  end

Run your test again and everything should pass.

rake test:units

Authenticating Users

Now we need to write a class method that we can use to grab a user from the database by looking up their username and hashed password. We’ll use a simple pattern for this. First, let’s write a quick test:

  test "given a user named homer with a password of 1234, he should be authenticated with 'homer' and '1234' " do
    User.create(:login => "homer",
                 :email =>"homer",
                 :password => "1234",
                 :password_confirmation => "1234")
    assert User.authenticated?("homer", "1234")
  end

We create a user and then call User.authenticated?. If its return value evaluates to True, we’ve got a good set of credentials. Add this class method to your User model to make your test pass:

  def self.authenticated?(login, password)
    pwd = Digest::SHA1.hexdigest(password.to_s)
    User.find_by_login_and_hashed_password(login, pwd)
  end

Notice that here, I’m actually returning the user object, rather than a boolean. If no user is found, nil is returned which evaluates to false. Remember, in Ruby, everything except nil and false evaluates to True.

Our entire user model looks like this:

require 'digest/sha1'
class User < ActiveRecord::Base
  
  validates_presence_of :login
  validates_confirmation_of :password
  attr_accessor :password
  
  before_save :encrypt_password
  
  def self.authenticated?(login, password)
    pwd = Digest::SHA1.hexdigest(password.to_s)
    User.find_by_login_and_hashed_password(login, pwd)
  end
  
  private
  
  def encrypt_password
    unless self.password.blank?
      self.hashed_password = Digest::SHA1.hexdigest(self.password.to_s)
      self.password = nil
    end
    return true 
  end
end

Creating the Filter

Let’s create a simple Projects scaffold. We’ll use our authentication to protect this scaffolded interface.

ruby script/generate scaffold Project name:string description:text completed:boolean

Now, open app/controllers/application_controller.rb and this code:

  def authenticate_with_basic_auth
    authenticate_or_request_with_http_basic do |username, password|
      @current_user = User.authenticated?(username, password)
    end
  end

This tiny bit of code will pop up a Basic Authentication credentials box and look the user up in our database using the supplied credentials. If we find our user, we put it in the @current_user instance variable. It’s common practice in Rails apps to have a current_user helper method, so we can add that to application_controller.rb as well.

  helper_method :current_user

  def current_user
    @current_user
  end

With that, we simply need to invoke the filter. Open your projects_controller.rb file and add this to the top:

before_filter :authenticate_with_basic_auth

And that’s it! You’ve protected the application. Create a user via the Rails runner, fire up script/server and test it out!

ruby script/runner 'User.create(:login => "homer", :password => "1234", :password_confirmation => "1234")
ruby script/server

You should also be able to use cURL to play with the XML REST-style API provided by the scaffold generator.

Get projects:

curl http://localhost:3000/projects.xml -u homer:1234

Create project via XML

curl http://localhost:3000/projects.xml \
-u homer:1234 \
-X POST \
-d "<project><name>Test</name></project>" \
-H "Content-Type: text/xml"

Simple is Good

This simple solution is easy to write, easy to maintain, and easy to extend. It’s also something that anyone with any practical experience with Rails should be able to write in as much time as it would take to configure Authlogic.

So what’s left to do with this? First, SHA1 isn’t great encryption. BCrypt might be better. A salt might be another good idea too. Some more tests would be great. So, go write them, and have fun! As always, I’d love to hear your comments.

ActiveRecord::StatementInvalid: DBI::DatabaseError: 42000 (15197) [FreeTDS][SQL Server]There is no text for object 'people'.: EXEC sp_helptext people

The “people” table here is actually a view that gets used all over the place in multiple applications. The DBA had moved the databases from an older SQL Server 2000 database previously.

The solution was to ensure that the application’s user account had the “view definition” permission on the view in question as well as the “select” permission. On the view, in the SQL Server Management Studio, right click and choose “Properties”. Then choose Permissions select your user account, and then select the “View definition” permission. Checking the box under the “Grant” column was enough for me to make it work.

Interestingly enough, the production server (which was upgraded months ago from SQL Server 2000 to 2005), does not have the permission set, but still works fine.

Hopefully someone else finds this useful.

Rails projects are quick to launch

With Rails, we can build and launch a prototype application in an extremely short time. On average, we can have something simple in front of the client in less than a couple of days, which is much faster than our previous projects where we used ASP or PHP. And that project isn’t usually a throwaway project; we can tweak it and move forward, from prototype to production.

Rails applications are easily testable

Professionals write tests that prove the code works as it should, and since testing is built right in to the Rails framework. testing is an easy natural part of the process. Testing has always been possible regardless of the language used, but with Rails, it’s so easy to produce well-tested code that you’d be foolish not to test. For my customers, that means much better products, and less support calls.

It’s a standard framework

I occasionally pick up projects from other developers, and while I can’t always ensure that the quality of the code will be good, I at least already know my way around the project because, in a Rails application, conventions dictate where things go. This means the learning curve is lower when we transition an application, and the customer doesn’t get billed extra time for me to figure out what’s going on.

The community is incredible

We rely heavily on open-source projects to get stuff done, and Rails has an amazing community that is always pushing the limits of what Rails applications can do. There is a new solution to a new problem almost every day, and that keeps us all on our toes. Plus, we’re very proud to be sponsoring the Rails Mentors project, which helps other developers get better at Rails development. We’re always giving back to open source, too.

It gets out of the way.

This is the most important point of all; Rails lets me deliver features. Instead of spending hours wiring up database tables to web pages, I can do that in five minutes and spend more time focusing on user experience and new features. And since it isn’t difficult to build things incrementally, I don’t get boxed in. I can make changes without feeling that I’ll lose days of work. It allows me to respond flexibly to new feature requests.

Rails gives us a competitive advantage. We cannot always compete on price alone, but we can provide better-quality solutions than others because we embrace an open, agile framework that lets us deliver stable, scalable, well-tested, and maintainable web applications.

Want to learn how you can take advantage of Ruby on Rails?

Contact us for information on customized training and mentoring services. We offer affordable hourly rates for remote mentoring, as well as custom training classes upon request.

Here are the notes:

Getting Ready

Before you can work with elements on the page, those elements must be loaded.

Prototype uses

document.observe("dom:loaded", function() {
  // your functions
})

jQuery uses this:

$(document).ready(function(){
  // your functions
})

Finding things

In Prototype, you use $() or $$() to locate elements. With $() you use the ID, whereas with $$() you use a CSS selector.

  var header = $("header");  // a single element, <div id="header"
  var popups = $$("a.popup"); // all elements like <a class="popup">

With JQuery, you do almost all of your element location using $(), which works very much like $$() in Prototype.

  var header = $("#header");  // a single element, <div id="header"
  var popups = $("a.popup"); // all elements like <a class="popup">

Binding events

Prototype’s Element class has an Observe method. It’s very easy to use and easy on the eyes.

  $("header").observe("click", function(event){
    alert("Hi there");
  });

In jQuery, it’s nearly identical, except that click is a method on the JQuery object.

  $("#header").click(function(event){
    alert("Hi there");
  });

At first, the differences look marginal, but let’s look at a more complicated example:

In Prototype, to find all links on the page with the class “Popup” and make them open in a new window, you have to do this:

function new_window_links(){
  links = $$("a.popup");
  links.each(function(link){
    link.observe("click", function(event){
      window.open(link.href);
      event.stop();
    });
  });
}

The Prototype version makes us find all of the elements, loop over them, and then apply the observer to each one.

jQuery can hide the iteration from you, which results in somewhat cleaner code.

function new_window_links(){
  links = $("a.popup").click(function(event){
      window.open($(this).attr('href'));
      event.preventDefault();
  });
}

Adding Classes

Prototype:

   $(".foo").addClassName("ninja");

  $(".foo").addClass("ninja");

Traversing the DOM

Prototype:

  parent_of_foo = $("foo").up();

jQuery

  parent_of_foo = $("#foo").parent();

Working with HTML attributes

This one was the most difficult to get used to. In Prototype, many of the HTML attributes are available as methods on the Element class.

  window.open(link.href);

In jQuery, you use the attr method to get and set the attributes.

  window.open(link.attr("http");

This illustrates only a few of the differences between the libraries, but as you can see, the differences don’t realy amount to anything substantial. Both of these libraries greatly simplify cross-browser JavaScript development, so no matter which you choose, you’ll be in good shape.

We held the event at UW-Stout this year, and had a great turnout. I gave two talks, the first on Ruby, and the second on Cucumber. I had wonderful audiences both times, and met some great people that I hope I get to work with in the future. Here are the slides for my talks.

See the end of the slide decks for links to the demo source code.

During the talk, I showed how to use Sinatra to create a very simple wiki. I wrote two versions. During the talk, I used SQLite3 and ActiveRecord, but I wrote a version that uses MongoDB. You can grab the source for those at Github.

Here are the slides from my talk. You can view the notes too by viewing the slides on Slideshare.

Participating at code camps is something I really enjoy. It gives me a chance to talk about what I love, but it also gives me a chance to learn from other speakers. These events are usually free, and an awful lot of fun.

sudo port install boost pcre++ spidermonkey
sudo port install mongodb

When I ran

mongodb

dyld: Library not loaded: /opt/local/lib/libnspr4.dylib
  Referenced from: /opt/local/lib/nspr/libplds4.dylib
  Reason: image not found
Trace/BPT trap

To fix, I simply copied the missing file from its origin to where Mongodb was looking.

 sudo  cp /opt/local/lib/nspr/libnspr4.dylib /opt/local/lib

And all was right.

First, let’s get a basic Rails app running with a Projects table with a single field, the project’s name :

 rails autocomplete
 cd autocomplete
 ruby script/generate model project name:string
 ruby script/generate resource projects
 rake db:migrate

Next, let’s load some test data.

 ruby script/runner "
 ['The Ninja project', 'The Top Secret project', 'World Domination'].each do |p|
    Project.create(:name => p)
 end
 "

Grab the autocomplete plugin from Rails’ Github repository and install it as a plugin:

 ruby script/plugin install git://github.com/rails/auto_complete.git

Our basic app is installed, but we need to implement a controller action to display projects.

Open app/controllers/projects_controller.rb and add this method:

  def index
    @projects = Project.all :limit => 10
    respond_to do |format|
      format.html
    end
  end

When the user requests HTML, we’ll show the last 10 projects created. Good enough for now. Let’s implement the layout and the view.

Open app/views/layouts/application.html.erb and build a very simple layout:

<html>
  <head>
    <title>Autocomplete</title>
    <% =javascript_include_tag :defaults %>
  </head>
  
  <body>
    <%= yield %>
  </body>
</html>

This very basic layout loads the default Javascript fiels for Rails and yields the template.

Now open app/views/projects/index.html and add this code:

<div id="search">
  <% form_tag(projects_path(), {:method => :get, :class => "form"}) do %>    
    <%=text_field_tag "query"%>
    <%=submit_tag "Search"%>
  <% end -%>
</div>
<div id="projects">
  <% if @projects.any? %>
    <ul>
      <%=render @projects %>
    </ul>
  <% else %>
    <p>There are no projects to show.</p>
  <% end %>
</div>

Here we have a list of projects, and when we click the submit button, we’ll filter the results. We’re using render here, and when you pass the render helper a collection, it looks for a partial that it can use render each of the elements in the collection.

Create app/views/projects/_project.erb and add this line:

<li><%=h(project.name)%></li>

Now we have to do the filtering in the controller. Since the search box is simply applying a filter to the list of projects, it makes sense for us to use the index action for the request. This means changing the controller’s index action slightly.

def index
  keyword = params[:query]
  if keyword.present?
    keyword = "%#{keyword}%"
    @projects = Project.all :conditions => ["name like ?", keyword], :order => "name asc", :limit => 10
  else
    @projects = Project.all :limit => 10, :order => "created_at desc"
  end
  
  respond_to do |format|
    format.html
    format.js do
      render :inline => "<%= auto_complete_result(@projects, 'name') %>"
    end
  end
end

If the query parameter comes in, then we want to filter. We build up a LIKE query and get the results. If no query parameter is present, we just get the top ten recent projects.

However, this is really messy. Let’s get that search logic out of the controller.

Open app/models/project.rb. Move the search logic into a new method:

def self.find_all_by_keyword(keyword)
  if keyword.present?
    keyword = "%#{keyword}%"
    @projects = Project.all :conditions => ["name like ?", keyword], :order => "name asc", :limit => 10
  else
    @projects = Project.all :limit => 10, :order => "created_at desc"
  end
end

Now change app/controllers/projects_controller.rb to call the method instead of doing the search:

def index
  @projects = Project.find_by_keyword(params[:query])
  respond_to do |format|
    format.html
    format.js do
      render :inline => "<%= auto_complete_result(@projects, 'name') %>"
    end
  end
end

Much better. At this point you have a non-Javascript search for your projects in a very short time.

Let’s add the autocomplete functionality. First, in the view, change the text field to this:

<%= text_field_with_auto_complete :project, :name, 
    { :name => "query" },
    {:method => :get, :url => projects_path(:format => :js) } %>

This sets up the autocomplete field to send its queries to our index action, but specifies that we should use the “js” format, perfectly appropriate for this, as it’s a Javascript-only request, so we should provide our response with Javascript.

Open the controller and modify the controller’s code so it looks like this:

def index
  @projects = Project.find_all_by_keyword(params[:query])
  respond_to do |format|
    format.html
    format.js do
      render :inline => "<%= auto_complete_result(@projects, 'name') %>"
    end
  end
end

The only real change is adding the format.js block of code. Here, we’re using Rails’ inline renderer which renders ERb code. Within that ERB, we’re calling the auto_complete_response helper provided by the autocomplete plugin to render the specially formatted list that the auto compelte text field expects. We’re using inline rendering here, but you could use a view with the .js extension. Since it’s one line, I’ll save the file I/O.

With the responder in place, the autocomplete should start working. This is a pretty simple example, but it does illustrate how to make the autocomplete plugin work in a current Rails application, without working about

It turns out that ActiveRecord has two private methods.

create_without_callbacks

and

update_without_callbacks

Remember that private in Ruby is less about keeping you from calling the methods and more about letting you know that you shouldn’t depend on them. With Ruby’s send method, using either of these in your application is easy.

Note that in Ruby 1.9, send doesn’t allow calling private methods, but send! does.

  class Project < ActiveRecord::Base
    after_save :create_hash_from_name_and_id

    private
      def create_hash_from_name_and_id
        self.hash = Digest::SHA1.hexdigest("#{self.id}#{Time.now.to_s}#{self.name}")
        self.send :update_without_callbacks
      end
  end

It’s my opinion that these methods should not be private. If I can skip validations with save(false), then I should be able to skip callbacks as well.

There are other patterns you can use to skip callbacks.

  class Project < ActiveRecord::Base
    attr_accessor :skip_callbacks

    with_options :unless => :skip_callbacks do |project|
      project.after_save :create_hash_from_name_and_id
      project.after_save :do_more_stuff
    end

    private
      def create_hash_from_name_and_id
        self.skip_callbacks = true
        self.hash = Digest::SHA1.hexdigest("#{self.id}#{Time.now.to_s}#{self.name}")
        self.save
      end
  end

So there you go. Go forth and skip callbacks at will.

If you have defined a class method you want to run which operates on a collection of records, you can share it with named scopes.

class Project < ActiveRecord::Base
  validates_presence_of :name
  named_scope :completed, :conditions => {:completed => true}

  # returns array of names for projects
  def self.names
    scope = self.scoped({})
    scope.all.collect{|record| record.name}
  end
end

This allows you to do

@project_names = Project.names

Or

@project_names = Project.completed.names

If you return the scope, you can continue chaining. If you don’t return the scope, then you can’t. This comes in handy though for creating a method that returns other objects than the object you’re working with. Here’s a completely contrived example:

Say you want to find the actual hours you’ve spent on all your completed projects:

class Project < ActiveRecord::Base
  named_scope :completed, :conditions => {:completed => true}
  
  def self.tasks
    tasks = []
    self.scoped({}).all.each do |project|
      tasks += (project.tasks)
    end
    tasks
  end
  
  def self.actual_hours
    hours = 0
    tasks.each do |task|
      hours += task.hours
    end
    hours
  end

Grab the value like this:

actual_hours = Project.completed.actual_hours

Now, of course there are other ways to do this, and this particular method will result in a lot of queries. If you were doing this hours counting in a real app, you’d be better off using SQL. This example illustrates the point though. Now go build something more awesome.