Url shortener gem came out of my need to tweet rss feeds to twitter every 5 minutes and shortening the url is the first thing required to do that. I looked at different url shortening services and decided to use bit.ly’s api as it appeared to be mature, comprehensive and more stable compared to other url shortening services.

The url_shortener gem allows to shorten/expand urls, retrieve stats and other information about them.

How to use

Since it is an API wrapper hence an account with bit.ly i.e. login and api key is required to use the url_shortener gem. bit.ly gives an API key to every user so if you have an account with bit.ly then you already have the key otherwise you can get it easily by signing up with bit.ly

Then the usual drill to install the gem

gem sources -a http://gemcutter.org
sudo gem install url_shortener


For a quick test, start an irb session and


require 'rubygems'
require 'url_shortener'


Before sending any request to bit.ly you need to initialize the Authorize and Client classes with bit.ly credentials:

authorize = UrlShortener::Authorize.new 'your_bitly_login', 'your_bitly_api_key'

If you don’t have a bit.ly account then you can use the bitlyapidemo key to try this

authorize = UrlShortener::Authorize.new 'bitlyapidemo', 'R_0da49e0a9118ff35f52f629d2d71bf07'
client = UrlShortener::Client.new(authorize)

bit.ly provides following four main end points or resources:

• shorten
• expand
• stats
• info

I suggest to check the xml outputs by clicking on the above end points to familiarize with the results returned.

Shorten Urls
Once you have the client object then call the shorten method on it with the url as the parameter.

shorten = client.shorten('http://www.yahoo.com') # => UrlShortener::Response::Shorten object

This will return a UrlShortener::Response::Shorten object which has several useful methods to parse results and access xml elements

shorten.result # => returns a hash of all data returned from bitly
shorten.urls # => returns the short url

The shorten method accepts a single or multiple url as parameters to shorten the urls

shorten = client.shorten('http://www.yahoo.com', 'http://www.google.com', 'http://github.com')

apart from the #urls and #result method you can also pass
#urls_with_long_url_keys, #hashes_with_long_url_keys, #hash and any xml element name within results->nodeKeyVal element

shorten.urls_with_long_url_keys
#etc


Expand Urls
To expand urls, either the hash or short url hash can be passed to the expand method which returns UrlShortener::Response::Expand object

expand = client.expand(:shortUrl => 'http://bit.ly/1RmnUT') # => UrlShortener::Response::Expand object
#OR
expand = client.expand(:hash => '1RmnUT') # => UrlShortener::Response::Expand object

Similar to the shorten method, you can call #result method to get a hash of xml or #url/#long_url to get the expanded long url

expand.result # => returns a hash of all data returned from bitly
expand.url # => returns a long url string


Stats

stats = client.stats(:shortUrl => 'http://bit.ly/1RmnUT') # => UrlShortener::Response::Stat object
#OR
stats = client.stats(:hash => '1RmnUT') # => UrlShortener::Response::Stat object
stats.result # => returns a hash of all data returned from bitly

There is a #referrers and #user_referrers method in the UrlShortener::Response::Stat class that does the xml parsing to return all referrers and as usual any xml element name can be passed as the method name to the stats response object like

stats.hash # => returns url hash
stats.referrers # => returns an array of referrers
stats.user_referrers # => returns an arrays of referrers
stats.clicks # => returns number of clicks


Info

info = client.info(:shortUrl => 'http://bit.ly/1RmnUT') # => UrlShortener::Response::Info object
#OR
info = client.info(:hash => '1RmnUT') # => UrlShortener::Response::Info object
info.result # => returns a hash of all data returned from bitly

All elements within doc element are available as methods to the info response object.
If you are a ruby purist and don’t want to use camelized method calls then you can use the underscore, for e.g.

info.htmlMetaDescription
#OR
info.html_meta_description

will work seamlessly and give the same results. Checkout the results return by bitly’s info resource to see what other methods are available to info response object.

url_shortener gem is available on github.

In this task we’ll take a peek at how to genereate XML feed from our application. We’ll start by generating a link that will tell us who bought a certain product, so it would be something link http://mystore.com/info/who_bought/product_id
Notice that’s the opposite direction of our application structure, you can’t access a line item from a product, but you can acess a product from a line item, so how do we tell Rails to do it both ways? By adding one line of code to the product model:

class Product < ActiveRecord::Base
  has_many:orders, :through=>:line_items
  has_many:line_items
#rest of the code

Now it knows that a product has orders, but it has to go through the line items database table first to get to those orders. We’re all set to generate the info controller with the who_bought action now (look back at the link mentioned). To the command propmt we go:

ruby script/generate controller info who_bought

With all files created, time to edit that who_bought action (and override the authorize method):

class InfoController < ApplicationController

  def who_bought
    @product=Product.find(params[:id])
    @orders=@product.orders
    respond_to do |format|
      format.xml{ render :layout => false }
    end
  end

  protected

  def authorize
  end
end

Who_bought is basically returning the orders from a given product ID. Notice it will format XML requests with no layout, so it will just be pure XML. Now we’ll need to implement a template that will return XML data to XML requests, and we can do that by creating an XML builder. Create a who_bought.xml.builder file in the info view directory and code this in:

xml.order_list(:for_product => @product.title) do
  for o in @orders
    xml.order do
	    xml.name(o.name)
	    xml.email(o.email)
    end
  end
end

This builder will render whenever a XML request is made to the who_bought action, so, as a view file, it can use all the instance variables from the info controller. As you can see, that’s just pure Ruby code that’s telling the XML object to do a few things:
- Create an orderlist tag with a for_product attribute filled in with the product title data.
- Create an order tag (with no data in) with 2 other tags embedded in it: name (with the order name data in it) and email (with the order email data in it).

To add an attribute all you do is add a hash collection to the tag you want, to add data you just pass it as a parameter and to nest other tags within a tag you just put them in a block inside the outer tag. To check this format out, just access the method and pass an ID with a .xml extension in the end, such as: http://localhost:3000/info/who_bought/1.xml

It’d be nice to render HTML case somebody accesses the page normally, with a GET request, so let’s create a simple view file that will supply mailing links to all the people who ordered a specific product (e-mail marketing is one of the reasons you should add XML feed to your applications, and that’s why we’re mentioning mail_to here). Edit your who_bought.html.erb file with this:

<h3>People Who Bought <%= @product.title %></h3>
<ul>
  <% for order in @orders -%>
  <li>
    <%= mail_to order.email, order.name %>
  </li>
  <% end -%>
</ul>

Since now we have some HTML to render, we need to tell the controller that he should render HTML case that’s what the HTTP request wants:

def who_bought
    @product=Product.find(params[:id])
    @orders=@product.orders
    respond_to do |format|
      format.html
      format.xml{ render :layout => false }
    end
  end

We have 2 ways of generating XML, one is through the builder which we already did, and another one is through the to_xml method that every model object has, which is easier to implement but not easy to maintain, edit the who_bought method again so that it will generate XML automatically:

def who_bought
    @product=Product.find(params[:id])
    @orders=@product.orders
    respond_to do |format|
      format.html
      format.xml{ render  ml=> @product.to_xml(:include =>  rders) }
    end
  end

Now all the product information will be dumped and rendered when a XML request comes. As said, this is hard to maintain because you can’t really set the XML the way you want, for that we use the builder template, but it’s always nice to know an easier way to do it cause you don’t mind just dumping everything.

Before finishing off our application, let’s generate its documentation. Rails turns the hassle of documenting everything into one single line of code in the command propmt, but before you do that, edit the README_FOR_APP file in the ‘doc’ directory with some description about this application, because it will show on the first page of the generated documentation. Now, to the code:

rake doc:app

And we’re done coding the application. But don’t think it’s over, on the next task and last task we’ll be doing one of the most important things in application development: testing. See you then.

In this task we’ll learn how to create a simple administration system that will allow restricted access to product maintenance (what we created in task A), orders (task E) and a new user management system.

Let’s start with the user management system that will allow us to create, edit, view and delete users in our online shop. These users will have only a login and a password, which will be hashed by the SH1 digest and then saved into the database. We’ll use a generator and specify the fields we need, and by doing that the migration will be already filled with the columns we specified. At your application directory, open your command prompt and type this in:

ruby script/generate scaffold user name:string hashed_password:string salt:string

And to make the database base changes happen:

rake db:migrate

Open your database and checkout the new users table with all the fields we specified. As we move on to the user model, notice that this will get a little more complicated due to the fact that we need to work with a plain text password in the application, but with a hashed version in the database, and knowing that complication, it’s better to work out the model step by step, so first, let’s put in some validation:

require 'digest/sha1'

class User < ActiveRecord::Base

  validates_presence_of :name
  validates_uniqueness_of :name

  attr_accessor :password_confirmation
  validates_confirmation_of :password

  validate :password_non_blank

  private

  def password_non_blank
    errors.add_to_base("Missing password") if hashed_password.blank?
  end
end

You should be familiar with the presence and uniqueness validation, we’ve used before, but there’s a new one named validates_confirmation_of that will basically check if 2 fields are matching, in this case, the password field with a ‘Confirm Password’ field (this is pretty common). Lastly we validate the existence of a password, but notice we check for its hashed version, not itself, this is because the hashed version is the one being stored in the database, thus, what matters to validation. The require method includes the SHA1 digest library, allowing us to use all its methods, so let’s get to that by adding a new private class method to the user model that will encrypt the plain text password into a hashed result:

def self.encrypted_password(password,salt)
  string_to_hash = password + "secretkey" + salt
  Digest::SHA1.hexdigest(string_to_hash)
end

The method above is taking a plain text password (which the user inputs) and a random value named salt, which is used to concatenate to the password and stored in the database making the hashed value even more unpredictable. Notice the “secretkey”, which makes the hashed value even richer, and is only available to people who have access to the Rails code. A digest is then applied to that whole string, turning it into a 160-bit hash such as “588aa91d21e71d0e2e3f6febfe8e90e1819ae97f”.
The salt was mentioned but a way to create it wasn’t, so we’ll be doing that by adding another private class method:

def create_new_salt
  self.salt = self.object_id.to_s + rand.to_s
end

Notice that by writing self.salt, we’re avoiding that Ruby treats salt as a local variable, which would be of no effect to us since it would just get discarded and collected by the garbage collector, by doing this we’re telling it to use the salt= accessor method instead, which updates its value, in this case, we’re updating with the object’s id (by using an accessor method that returns the object’s current id) concatenated with a random string.

Now that we have the hashing process all set up, we need to make it so a plain text password sent by an user input will be treated and sent into the database, to do that, we’ll use a so called ‘virtual attribute’, which is something we can manipulate but doesn’t go into the database. Of course we can’t use Rails’ built-in accessor methods for that virtual attribute, because that would make it go into the database, instead, we’ll hard code our own accessors into the user model:

def password
  @password
end

def password=(pwd)
  @password = pwd
  return if pwd.blank?
  create_new_salt
  self.hashed_password = User.encrypted_password(self.password,self.salt)
end

Last thing we need to is create a User class method that checks if the right login/password combination has been supplied and returns that object if it has.

def self.authenticate(name,password)
  user = self.find_by_name(name)
  if user
    expected_password = encrypted_password(password,user.salt)
    if user.hashed_password != expected_password
      user = nil
    end
  end
  user
end

Notice the find_by_name method, whenever an undefined method that starts with find_by_ is called, Rails looks for the last part of the string, in this case, name, and begins a search on the class database table using that part as a string, in this case, it searches all users by their name using the name passed as a parameter.

Let’s put everything we did to the user model so far in a single chunk of code:

require 'digest/sha1'

class User < ActiveRecord::Base

  validates_presence_of :name
  validates_uniqueness_of :name

  attr_accessor :password_confirmation
  validates_confirmation_of :password

  validate :password_non_blank

  # 'password' is a virtual attribute

  def password
    @password
  end

  def password=(pwd)
    @password = pwd
    return if pwd.blank?
    create_new_salt
    self.hashed_password = User.encrypted_password(self.password,self.salt)
  end

  def self.authenticate(name,password)
    user = self.find_by_name(name)
    if user
      expected_password = encrypted_password(password,user.salt)
      if user.hashed_password != expected_password
        user = nil
      end
    end
    user
  end

  private

  def password_non_blank
    errors.add_to_base("Missing password") if hashed_password.blank?
  end

  def self.encrypted_password(password,salt)
    string_to_hash = password + "wibble" + salt
    Digest::SHA1.hexdigest(string_to_hash)
  end

  def create_new_salt
    self.salt = self.object_id.to_s + rand.to_s
  end

end

Moving on to the administration itself, let’s edit the user controller file that was generated by scaffold, first, the index method:

def index
    @users = User.find(:all,  rder => :name)

    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render  ml => @users }
    end
  end

All we did was alter the first second line of code to return all users to the @users instance variable. Moving on to the create method:

def create
    @user = User.new(params[:user])

    respond_to do |format|
      if @user.save
        flash[:notice] = "User #{@user.name} was successfully created."
        format.html { redirect_to(:action => :index) }
        format.xml  { render  ml => @user, :status => :created, :location => @user }
      else
        format.html { render :action => "new" }
        format.xml  { render  ml => @user.errors, :status => :unprocessable_entity }
      end
    end
  end

This time we added a flash notice and an index redirection, because it really doesn’t make sense to redirect to the edit page. Finally, the update method:

def update
    @user = User.find(params[:id])

    respond_to do |format|
      if @user.update_attributes(params[:user])
        flash[:notice] = "User #{@user.name} was successfully updated."
        format.html { redirect_to(:action => :index) }
        format.xml  { head  k }
      else
        format.html { render :action => "edit" }
        format.xml  { render  ml => @user.errors, :status => :unprocessable_entity }
      end
    end
  end

Same flash notice and redirection as the create method.

We have our model and our controller ready, now we did to edit some view files, let’s start by the index.html.erb (inside the user folder, of course)

<h1>Listing users</h1>

<table>
  <tr>
    <th>Name</th>
  </tr>

<% @users.each do |user| %>
  <tr>
    <td><%=h user.name %></td>
    <td><%= link_to 'Show', user %></td>
    <td><%= link_to 'Edit', edit_user_path(user) %></td>
    <td><%= link_to 'Destroy', user, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to 'New user', new_user_path %>

The scaffold generates viewing of all the table’s attributes, which in this case is a bad thing because the password and salt information do not need to show, so we removed all the data related to that in the code above, and with that same line of though, we’ll now edit the new.html.erb file:

<div class="depot-form">
  <%= error_messages_for :user%>
  <% form_for(@user) do |f| %>
  <fieldset>
    <legend>Enter User Details</legend>
    <p>
      <label for="user_name">Name:</label>
      <%=  f.text_field:name, :size=>40 %>
    </p>
    <p>
      <label for="user_password">Password:</label>
      <%=  f.password_field :password, :size=>40%>
    </p>
    <p>
      <label for="user_password_confirmation">Confirm:</label>
      <%=  f.password_field :password_confirmation, :size=>40 %>
    </p>
    <p>
      <%=f.submit "Add User", :class => "submit" %>
    </p>
  </fieldset>
  <% end %>
</div>

<%= link_to 'Back', users_path %>

Notice we removed the salt and hashed password information again and replaced it with a common password field and a confirmation field. As seen on Task A, we need to add our custom stylesheet to the stylesheet helper on the user layout file (it comes with the default scaffold stylesheet):

<!DOCTYPE htmlPUBLIC "-//W3C//DTDXHTML1.0Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8"/>
<title>Users:<%= controller.action_name %></title>
<%= stylesheet_link_tag'scaffold','depot' %>
</head>

All done, now we have a user management system with some design on it, you should add a user now, we will need it for the next step which will be the creation of a login system, which will be the primal basis for our administration system, so let’s get to it. First thing we need to do is generate a controller with some specific actions (at the command propmt in your application directory):

rubyscript/generate controller admin login logout index

With all files created, let’s edit the login method in the recently created admin controller:

def login
    session[:user_id] = nil
    if request.post?
      user = User.authenticate(params[:name], params[:password])
      if user
        session[:user_id] = user.id;
        redirect_to(:action => "index")
      else
        flash.now[:notice] = "Invalid user/password combination"
      end
    end
  end

Notice the request.post? condition, this is a way to know whether the page is being executed through a GET request (by some URL) or through a POST request (through a form), this way the action knows that it should only execute the login logic case the user has already submitted the form, if he hasn’t, the login view file will be parsed. The login logic is pretty simple, the authenticate method is called using the name and password passed into the request by the login form and returns a user case there is one (or nil case there isn’t), then a session variable is set using the user id and a redirection is made.
Having the controller all set, it’s time to edit the login view file (that will get parsed case the login action is accessed by some URL or redirection):

<div class="depot-form">
  <% form_tag do %>
  <fieldset>
    <legend>Please Log In</legend>
    <p>
      <label for="name">Name:</label>
      <%= text_field_tag :name, params[:name] %>
    </p>
    <p>
      <label for="password">Password:</label>
      <%= password_field_tag :password, params[:password]%>
    </p>
    <p>
      <%= submit_tag "Login" %>
    </p>
  </fieldset>
  <% end %>
</div>

Since there is no ‘admin’ model, we have to hard code the form using different helpers. This time, instead of form_for, we’re using form_tag, which creates a simple form tag that envelops the Ruby block. Then we use field_tags, which need a name and a value, which, in this case, are being filled in directly with parameters passed by the params hash. Okay, so the user logs in, then what? Then an index page shows, one which we will edit right now: (index.html.erb in the admin controller)

<h1>Welcome</h1>
It's <%= Time.now %>
We have<%= pluralize(@total_orders, "order") %>.

Pluralize helper just checks if it should say ‘order’ or ‘orders’, and its using a instance variable which we didn’t define yet. Going back to the controller, let’s add the until-now undefined @total_orders variable to the index method:

def index
  @total_orders = Order.count
end

Order.count returns the number of rows in the orders table. Now that we have our first administration page working with our login system, it’s time to actually make logging in necessary to anyone who tries to access administrating pages (which is the whole point). This sounds much, but it’s just one line of code (and a method). But what would be the perfect place to put that in, no use putting in the admin controller because the product maintenance would be accessible, and what about everything else related to administration that isn’t in the admin controller? As you can see, this requires global attention, and when it comes to globalizing actions, the best way to do it is by editing the application controller, which is the ‘mother’ of all controllers (all controllers heir all methods from the application controller). Knowing the right place to mess with (application_controller.rb), code this in:

class ApplicationController < ActionController::Base

  before_filter :authorize, :except => :login

  helper :all
  protect_from_forgery

  protected

  def authorize
    unless User.find_by_id(session[:user_id])
      flash[:notice] = "Please log in"
      redirect_to :controller => :admin, :action => :login
    end
  end

end

We’re telling Rails that we want to execute the authorize method before rendering any page, with the exception of the login action, obviously (you don’t have to be authorized to access the login page), redirecting the user to the login page and flashing a message pointing that he needs to log in first. But we don’t want the log in page to be forced on the user in the store page, for example, so what do we do? We could just add a bunch of exceptions, but that wouldn’t look nice and would need maintenance every time something new was added to the application, so it’s better to just override the authorize method on every controller that doesn’t need authorization, an example of this can be shown by adding few lines of code to the store controller:

protected

def authorize
end

Now we have our logic all set for the administration system, so we need to make the layout a little bit more consistant, and we’ll do that by adding the same sidebar as the one in the store layout to all pages, with a few options added for logged in administrators. This way, we will have a single layout for the whole application, needo, huh? Although a big change, this requires only a single line of coded added to the mother of controllers, the application controller:

class ApplicationController < ActionController::Base

  layout "store"

  before_filter :authorize, :except => :login

  helper :all
  protect_from_forgery

  protected

  def authorize
    unless User.find_by_id(session[:user_id])
      flash[:notice] = "Please log in"
      redirect_to :controller => :admin, :action => :login
    end
  end

end

With one line of code we made the whole application include the store layout, which is prettier than anything we’ve done so far. Make sure you delete the ‘users’ and the ‘products’ layout, by simple file deletion or by the command prompt: (rm command for Linux users, erase command for Windows users)

rm app/views/layouts/products.html.erb
rm app/views/layouts/users.html.erb

Now that the store layout is global, we need to make a few changes to it. First, a condition is needed to check if there is a @cart instance variable before executing the code relative to the shopping cart, we didn’t need this before because all the store actions instantiated the @cart object, but other controllers won’t. Next we will add a condition to check if there is someone logged in (an administrator, of course) and show some administrative options on the sidebar. All this can be done with this code (in the store layout file):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<html>
<head>
<title>Pragprog Books Online Store</title>
<%= stylesheet_link_tag "depot" , :media => "all" %>
<%= javascript_include_tag :defaults %>
</head>
<body id="store">
<div id="banner">
<%= image_tag("logo.png" ) %>
<%= @page_title || "Pragmatic Bookshelf" %>
</div>
<div id="columns"> </div>
<div id="side">
  <div id="cart">
    <% if @cart %>
      <% hidden_div_if(@cart.items.empty?, :id => "cart" ) do %>
      <%= render(:partial => "cart",  bject => @cart) %>
      <% end %>
    <% end %>
  </div>
  <a href="http://www....">Home</a><br />
  <a href="http://www..../faq">Questions</a><br />
  <a href="http://www..../news">News</a><br />
  <a href="http://www..../contact">Contact</a><br />
  <%if session[:user_id]%>
    <br/>
    <%= link_to 'Orders',  :controller => 'orders' %><br/>
    <%= link_to 'Products',:controller => 'products' %><br/>
    <%= link_to 'Users',   :controller => 'users' %><br/>
    <br/>
    <%=link_to 'Logout',   :controller => :admin, :action => 'logout'%>
  <% end %>
</div>
<div id="main">
  <% if flash[:notice] -%>
  <div id="notice"> <%=flash[:notice]%> </div>
  <%  end -%>
<%= yield :layout %>
</div>
</body>
</html>

Next we’ll be adding a few security measures so that the last administrator cannot be deleted making the administration panel unaccessible. Rails has methods called ‘hook’ methods, we already used the ‘validate’ hook that validates an object state, and now it’s time to use a hook that will raise an exception on a database line deletion, making it rollback case the hook returns true. To do this we only need to add a method to the user model:

def after_destroy
  if User.count.zero?
    raise "Can't delete last user"
  end
end

Now we need to rescue that exception and show it to the user, and since it is risen when we order the deletion of a user, we’ll need to rescue in on the destroy action of the user controller:

def destroy
  @user = User.find(params[:id])
  begin
    flash[:notice] = "User #{@user.name} deleted"
    @user.destroy
  rescue Exception => e
    flash[:notice] = e.message
  end

  respond_to do |format|
    format.html { redirect_to(users_url) }
    format.xml  { head  k }
  end
end

There we go, now an error message will pop case the last user is issued to deletion. Wait, we almost forgot about one thing: the log out action, we created a link to it on the sidebar but didn’t set the action itself, so let’s get to that (on the admin controller):

def logout
  session[:user_id] = nil
  flash[:notice] = "Logged out"
  redirect_to(:action=> "login")
end

Session clearing, flash notice and a redirection, nothing we haven’t mastered already.

Now we’re all set on the administration system, the user can log in and out, add users, and know that it is all being restricted. But, before we finish this task, let’s apply the filter concept we learned in the store controller. Remember all those @cart = find_cart assignments? They’re almost in every store action, which is ugly because it’s duplicated code, and thanks to filters, we can avoid that by making use of one. First we need to change the find_cart method to assign an instance variable (instead of returning something that would get assigned to an instance variable):

def find_cart
  @cart=(session[:cart]||=Cart.new)
end

And lastly, add the filter to the beggining of the controller (with an exception of the empty_cart method which clears out the instance variable):

before_filter:find_cart,:except=>:empty_cart

Now the find_cart method is executed everywhere in the store controller and you can remove all the @cart = find_cart assignments from it.

Our application is coming together, we’re almost done! See you next task.

saya rada jenuh menggunakan nama user_session sebagai nama model untuk authlogic, yah saya iseng aja ganti namanya menggunakan nama session.

dan voilla error pun terjadi.

permasalahannya authlogic menggunakan teknik pembacaan parameter untuk session secara default seperti ini => {nama_model_yang_divalidasi}_session, contoh user_session. makanya dia muncul dengan error interning string.

nah solusinya kalau mau tetap mempertahankan nama model tetap session cukup tambahkan

authenticate_with User

dalam isi class session tersebut.

semoga bermanfaat.

I haven’t spent this much time talking to journalism professors and students since I graduated from Texas Christian University (let’s just say some time ago).

I visited TCU last week to present seminars on the Complete Community Connection and journalism ethics in the digital age. And since I was sticking around for some memory-lane time, the curriculum committee at TCU’s Schieffer School of Journalism asked me to meet with them and tell them what I think journalism schools should be teaching about our swiftly changing field.

I shared my views with them and will share them with you here shortly. The TCU meetings continued a heavy fall schedule of consultations with journalism faculty and students on a variety of related topics:

• In late August, I was a panelist for the Accreditation Council on Education in Journalism and Mass Communication, sharing my views on how journalism schools should be teaching today and what sort of standards the council should require. Afterward, I shared some resources for journalism educators on this blog.
• In mid-September, I met with University of Missouri faculty to advise on plans for digital-only coverage of the Associated Press Managing Editors convention in St. Louis.
• Later in September, I presented an ethics seminar at the University of Kentucky. The visit included an informal discussion over pizza with students about what editors are seeking in interns and journalism graduates. I developed a post of career advice for journalism students and called their attention to an earlier post on the importance of your digital profile.
• The next week, I met with faculty advisers and editors of the Iowa State Daily, who came to Cedar Rapids to brainstorm issues such as digital coverage, C3 and organizational changes we’ve made at Gazette Communications.
• In November, I led another ethics seminar at the University of Nebraska-Lincoln and critiqued the senior portfolios of three UNL seniors (part of the UNL accreditation process, as well as providing advice to the seniors).
• Before visiting TCU, I returned to the University of Missouri for an American Society of News Editors/Reynolds Journalism Institute Ethics and Values Forum. Participants included journalism faculty from four other universities, in addition to Missouri. After dinner one night, we had an interesting discussion with several Missouri students, many of whom are already looking for jobs.
• I have had frequent discussions with David Perlmutter, new director of the School of Journalism and Mass Communication at the University of Iowa, including plans to team-teach a course with Jim Cremer on creating an iPhone application.

In various ways in formal events and private conversations, similar concerns about how to teach journalism today came up again and again. If I could summarize the concerns (admitting that I am drawing conclusions that weren’t always stated explicitly), I would say this: Lots of journalism educators worry how they can and should teach to prepare students for a world that has changed vastly since professors practiced and/or earned graduate degrees and is changing so swiftly that even if professors were current in all respects, their lessons may be outdated by the time their students graduate. While journalism school enrollment is stronger than the businesses that support journalism, educators are keenly aware that they need to update their curriculum and knowledge or they could face the same sort of crash that news media companies are experiencing.

My response focuses heavily on what journalism schools should be doing to address new needs and challenges. I have not looked at closely at what they should not be doing. But I would suggest that in the current environment, every requirement and every course needs to be re-examined and face demanding questions:

• Does the course need to be updated?
• Should the course be dropped?
• Should the course be taught less frequently?
• Should the course be combined with another?
• Should a required course become an elective?

Journalism schools also need to examine their tracks, sequences and structures. If your school offers a “print sequence,” you might as well call it an “outdated sequence.” While newspapers still command large audiences and generate large revenues, newspaper companies are diversifying and journalism schools need to be educating multi-platform journalists, not print journalists.

As I go through topics that journalism schools might not be covering adequately, I would argue that many of these issues don’t need to be addressed in a standalone class, required or elective. Rather, they should be integrated throughout the curriculum. For instance, if you offer an elective course in Twitter but don’t teach students in your basic reporting course how reporters should use Twitter, you aren’t teaching what you need to teach. I would advise requiring students in their first media writing course to spend at least a couple weeks taking their class notes in Twitter, so they get an early practical exposure and see it as a tool for journalism from the start. And each course should decide the appropriate way to use Twitter in that course.

In other cases, a required or elective course – or perhaps a course combining a few of these topics – might be exactly what a journalism curriculum needs. I will make specific recommendations about how digital skills should be infused throughout the curriculum and about specific courses a journalism school should consider. But as curriculum committees and J-school leaders consider these issues, they will need to consider other factors. As j-schools weigh such factors as course loads, total hours students can take and so on, I would usually err on the side of incorporating digital skills throughout the curriculum, rather than addressing them in specific courses.

These are the topics I think journalism schools need to address:

Social media. Journalism schools today need to educate students about how social media are changing professional media and society. Twitter is the social platform that needs the most attention right now, but professors need to stay abreast of how society and journalists are using social tools and update their courses appropriately. If Twitter goes the way of MySpace, you need to adjust swiftly to address the next hot social tool. Students are already active in using Facebook, so Facebook is less urgent. Professors also should consider how to use Facebook in courses, such as using a fan page for assignments and exchanges about a course. My primary recommendation here is that social media need to be incorporated throughout the curriculum: Twitter in media writing, reporting, ethics, specialized reporting courses, appropriate strategic communication courses, etc.; visual journalism courses should cover such social tools as YouTube, Flickr, Twitpic and Qik. Ethics courses certainly need to incorporate social media, including Facebook. I also would recommend an advanced course on social media strategy. This would focus on how media organizations need to use social tools to engage the community and serve business customers. This course also would cover potential uses of emerging social tools. This should be an advanced or graduate-level course, serving journalism and strategic communication sequences.

Interactive databases and computer-assisted reporting. I have been critical before of the use of the term computer-assisted reporting. You might as well refer to notebook-assisted reporting or telephone-assisted reporting. This is 2009 and computers have been an essential tool for reporters for a couple decades now. Journalism schools should take the lead in breaking down the data ghettos that have emerged in our profession. Basic reporting courses should cover use of basic spreadsheet, database and mapping programs. These are essential journalism tools and skills and their use should start in basic courses and be required throughout the curriculum. An advanced course should cover development of interactive databases using such tools as Caspio, Django and Ruby on Rails. Again, these skills are as valuable to strategic communication students as to journalism majors.

Programming. As I mentioned to the TCU curriculum committee, I encourage working with a computer science department to develop cross-disciplinary courses such as my iPhone app course at Iowa. I also encourage working with the computer science department to develop double-major or major-minor combos to help “hacker journalists” get the appropriate education in journalism and programming. (I’m delighted that two students in the iPhone class will be double majors in journalism and informatics.

Mobile journalism. Basic reporting courses should introduce students to the multitasking skills and demands of mobile journalism. The University of Missouri is requiring journalism students to buy iPhones. I don’t know how important it is to specify a brand (I do use an iPhone), but I think requiring students to use smart phones as journalism tools is an excellent idea. If I were teaching a reporting or multimedia course now, I would require that some specific assignments be carried out entirely with a mobile device. This would require writing on the phone, shooting still photos and video and providing geocoding metadata. An advanced course(s) could focus specifically on mobile journalism, such as developing mobile applications or a mobile-first strategy.

The business of journalism. Journalism students need a more thorough introduction to the business of journalism than I received as a student (almost none) or than students receive today. They need to learn about traditional business models for print and broadcast. They should understand the disruption that is causing the collapse of the business models. They should understand why and how some organizations are seeking to try paid-content digital models (and they should understand how paid content has been tried before and that it hasn’t worked). They should examine and understand efforts to develop new business models (such as my own Complete Community Connection model). They should learn about product development and entrepreneurial journalism. They should understand how the advertising model is collapsing on all platforms and study efforts to develop new revenue streams. Tim McGuire’s Business and Future of Journalism course at Arizona State University provides a good model. While some coverage of business models would be good in lower-level courses, an upper-level course is a good idea and I would encourage requiring it for all students or for some particular majors. The lack of business literacy is a huge problem among journalists and tunnel vision on business issues is a huge problem for people in advertising and executive offices.

Community engagement. Interaction is a significant part of the future of journalism, from crowdsourcing of stories (investigative, events, features, reviews) to engaging comments on blogs to aggregating the work of community bloggers and citizen journalists. This could certainly be a full course.

Digital content in specialized courses. A question raised in an email about TCU’s curriculum asked how much digital content should be integrated into advanced courses on journalism specialties, such as public affairs reporting and sports reporting. My answer is that the courses should have as much digital emphasis as the specialties have now, and that’s a lot. For instance, even TCU sportswriting legend Dan Jenkins, became a Twitter icon this year at age 79. Blogging, liveblogging and video are essential parts of sportswriting now, and the traditional game story is declining in importance to the point that sports writers are debating whether it’s dying. Any course on a specialty should reflect the current state and projected direction of that specialty.

Visual journalism. Photojournalism and graphic arts, as narrowly defined for much of my career, are outdated journalism specialties. While those skills remain important, visual journalists need to master (and be taught) a range of digital skills: video, audio, animation, multimedia graphics using programs such as Flash. And, of course, visual journalists need to learn ethical standards for using all these new tools and skills. Journalism students learning graphic arts should certainly learn how to make print graphics, but they also should learn to develop interactive multimedia, including simulations and games.

Live coverage. Increasingly, journalists need to provide live, unedited coverage of events. Whether in a reporting course, a visual journalism course, a live-coverage course or all three, students should learn how to liveblog, stream live video and aggregate real-time public content from social media.

Managing digital content. Digital journalism and strategic communication both will require a range of digital skills that are rapidly developing. The specific content of such a course and the balance of topics covered would change by semester, but someone should stay abreast of issues such as search-engine optimization, analytics, tagging, curation, aggregation, archiving, content-management systems and semantic technology. Some of these topics need to be introduced in lower-level courses, but they easily could be an upper-level course.

Design. Print design is fading in importance as newspapers cut newsholes and resources and require more regional design and use of templates. But web design and mobile design are areas of growing importance. Design courses should be adjusted accordingly.

Blogging. I don’t see a need for a course specifically in blogging (though I wouldn’t object either). Blogging should be part of nearly every writing course. In many courses, students should be required to keep a course blog. I evaluated portfolio blogs for seniors at the University of Nebraska, and I would encourage any journalism school to require students to maintain portfolio blogs.

Link journalism. Students need to learn how to use links, which are the footnotes of the digital world. This certainly should be part of reporting and editing courses.

Law and Ethics. As I address in my Upholding and Updating Ethical Standards seminars, ethics education needs to address a wide range of digital issues. Of course, digital journalism presents many legal issues as well. In fact, many (I suspect most) editors and journalism professors continue to follow outdated advice on court interpretations of Section 230 of the Communications Decency Act.

First Amendment. The American Press Institute, where I worked for three years, collaborates with the First Amendment Center and the Freedom Forum to take our seminars to programs on the First Amendment. These programs gave me both a deep appreciation of our First Amendment freedoms and a keen realization that professional journalists don’t know enough about the history and current status of the First Amendment and the freedoms it guarantees. A First Amendment course could be a cross-disciplinary course with credit in journalism, religion and political science. With TCU’s international communication major, this course should include units on restrictions on our key freedoms in other nations.

TCU’s curriculum committee asked me whether I thought professionals would be interested in a certificate program in digital journalism for professionals needing to update their skills. While ability to pay might be impaired by staff reductions and fears about job security, I think interest in such programs would be high. I encourage journalism schools to offer such programs in person and/or online, and to either develop financial aid support for such courses or to cut down the university overhead in determining tuition, since professionals would not draw as heavily as younger students on university resources. Such a certificate program should allow considerable flexibility for professionals to fill the gaps in their own skills.

Many journalism schools will be hard-pressed to update their curricula as I’ve described (though some certainly are already doing some of these things). They will need to hire more faculty with digital skills, use adjunct faculty with digital skills and require faculty to update their own skills and knowledge.

I’m glad journalism schools are considering these issues and I hope they move decisively and swiftly to update.

If you install Rails using RubyGems
(which we recommend), simply start the gem documentation server (using the
command gem server), and you can access all the Rails APIs by pointing your
browser at http://localhost:8808.

I’ve been hard at work on a new rails app recently.  Anyone who has built a Rails app knows the it’s less about coding than understanding how the framework works for you and following the path of least resistance.  If you’re writing a lot of Ruby code in your rails app to do what seems to be typical activities…well you may be approaching it wrong.

In Rails 2.3 some new features were added to simplify dealing with “nested forms”.  That is, a single form that manages a model and it relationship data (has_one, has_many, etc)  In the dark ages (last spring) it was necessary to add a faux accessor to accommodate this.  No longer.

If you surf the web you will find many examples, not all of the are current.  I just put an example on github that demonstrates a simple master-detail type of form.  In this case it’s an order that has_many line_items.  The app is purposefully bare-bones so that the essential aren’t buried.  Any real app would have more elegant page layout, data validations and a lot of other niceties.

This first example shows adding and removing detail records using AJAX.  There are two simple helper methods to facilitate this.

Check it out on github: http://github.com/canonical/OrderItemsExample

Nestiker adalah suatu animasi sederhana yang biasanya digunakan oleh banya programer untuk memberikan animasi berupa text yang berganti satu demi satu secara vertikal, biasanya digunakan di News Later Barita, adapun cara pembuatannya sangat mudah :

1. Mempersiapkan code Javascriptnya :

<script type=”text/javascript”>
$(function() {
$(“.newsticker-jcarousellite”).jCarouselLite({
vertical: true,
hoverPause:true,
visible: 1,
auto:500,
speed:2500
});
});
</script>

Download Code Javascript berikutnya jquery-latest.pack dan jcarousellite_1.0.1c4 , masukkan semua javascript yang ada di antara head

2. Pada View kita masukkan code berikut :

<div id=”newsticker-demo”>
<div class=”newsticker-jcarousellite”>
<ul>
<% @articles.each do |article| %>
<li>
<div class=”info”>
<span class=”title”><a href=”/newsbriefs/1″><%=h article.title %></a></span>&nbsp;&nbsp;
<span class=”cat”><a href=”/newsbriefs/1″><%=h article.updated_at %></a></span><br />
<%= snippet(article.content, 30) %>
</div>
</li>
<% end %>
</ul>
<div class=”clear”></div>
</div>
</div>

Selesai Selamat Mencoba !!!! Moga aja berhasil

In my current Ruby n Rails project, the focus of work is to periodically update database entries from XML feeds.

Naturally I’ve implemented a threading system using the rufus-scheduler gem for updating database entries every so many minutes. However I soon noticed that after running on the development enviroment with 1 minute intervals on updates, that the updating of the last updated time column in the db suddenly stopped after about 5 iterations. No error, warnings or other signals (smoke or otherwise).

After a bit of head scratching I finally managed to mentally link the 5 iterations to the pool number setting in the database.yml file. Executing my database updates within the thread job was stopping Rails from cleaning up the unrequired connections (for whatever reason. I suspect this is because the thread is sent back to sleep before this can occur).

So the solution is to simply call the cleanup manually via…

ActiveRecord::Base.connection_pool.clear_stale_cached_connections!

… at the end of every job execution run. Problem sorted!

Olá pessoal!!

Recentemente tive vários problemas ao tentar conectar o ruby com o banco postgres via dbi com a porta diferente da padrão 5432. Era erro atrás de erro, só conseguia conectar com a porta padrão 5432, mas queria utilizar outra, por exemplo, 5433. Até que consegui assim:

require 'dbi'
con=["DBI:Pg:dbname=nome_do_banco;host=localhost;port=porta", "nome_do_usuario", "senha"]
DBI.connect(*con)

É isso ai!
Abraços!

Monday morning is the time when our teams interact the most about projects and the coming week.  I’ve decided to capture events typical of Monday to provide insight into our work developing products for clients.  I’ll do my best to include everything warts and all even if that means sharing something I would not normally share.  In support of full disclosure, I took sparse notes over a period of time and came back later to clean up the text and add commentary.  Here goes nothing!

Our high-tech revolution has plunged us into a state of continuous partial attention.

iBrain by Gary Small, M.D. and Gigi Vorgan

- A typical Monday starts by pulling my canoe out into the various communication streams.  Logging on to Skype is the watershed event.

- Skype is running.  Firefox is open with tabs for email, calendar, several Google docs, WordPress for this post and YouTube for a side project I am working on.

- I check in with my lead on Skype.  I have the same guy across a few of my projects.  This certainly streamlines the communication.  He’s in Costa Rica.  When I worked at Adobe, we used IM all the time as people worked on different floors and at different locations.

- I am acting as the product owner for one project and I clarify something about a feature we are implementing.

- On another project, our client provides detailed specifications and we review the documents to make sure we are in sync.  We are, which is good.

The new promise of collaboration is that with peer production we will harness human skill, ingenuity, and intelligence more efficiently and effectively than anything we have witnessed previously.

WIKINOMICS by Don Tapscott and Anthony D. Williams

- Our newest client jumps on Skype to validate the release, our testing and the schedule.  There is a lot to discuss so we move to a Skype call. He does a good job managing his business to create an active and valuable community.

- Another issue comes in about how a feature should work that requires some thought.  I ignore chats and emails for the next 30 minutes and open specifications in Google docs and mock-ups in Preview.  We clarify the issue.

- By late morning, the major communications have been completed.  Projects are moving forward and our teams seem to understand what needs to happen this week.  I am responsible for a couple of releases that are in full swing.

No matter how clever the idea or great the implementation, an invention typically lives or dies depending on how well it can be integrated into a larger social or technological context.

Juice by Evan I. Schwartz

- The marketing text for our Web site update is long overdue.  Some tasks on the docket this week are for corporate business.  But I decide to focus on that side project and YouTube.

- I started a project called ReachGivers.org to help charities and non-profits get their message out over the Internet.  ReachGivers.org uses Ruby on Rails and has Twitter integration.  I added a poor man’s blog a while back as well.  This week I want to add video support.  Side projects help me stay connected with technology.

Economics is above all a science of measurement.  It comprises an extraordinarily powerful and flexible set of tools that can reliably assess a thicket of information to determine the effect of any one factor, or even the whole effect.

Freakonomics by Steven D. Levitt and Stephen J. Dubner

- Off to Starbucks for a Mocha and a blueberry scone.  This happens so often that people know me by name there.  The Ethos water billboard reminds me I wanted to blog about that on ReachGivers.org after finishing the video work.

- My brain stumbles on some concepts for the marketing text and I jot down some ideas.

- I was working on a product a while back and was not that impressed with the end user documentation.  I sent a book proposal out to a technology book publisher, which turned into a series of titles, and I have been writing every since.  I love it, I really do.  I even enjoy working on marketing text and ads.

Execution is not a one-time event.  Nor is it a process where you check off goals as if your sixth-grade teacher were looking over your shoulder.

The Art of the Start by Guy Kawasaki.

- Shorty before noon we get a curve ball. Mid-cycle, our client needs to shift direction on a project to change the prioritization and the release date.  I’ll spend the next few days updating user stories and validating the new plan. Sometimes I feel like we’re actually better at hitting a curve ball.

- The Agile software process, which is intended for flexible development, actually advocates against this type of mid-cycle change.  Release cycles are purposely shorter so that a direction shift simply influences the next cycle.  For start-ups, next month can be years away.  We have to be more flexible.

- A site we monitor generates an alert right before I can escape for lunch.  I used to get a little rush on these mini-emergencies like working as an EMT. Now I am the ambulance driver who knows that most pick-ups are not at all like the show ER.  Still, up-time is important and so we resolve the issue as quickly as possible.

- It occurs to me that this post demonstrates why people Tweet.  Expressing myself effectively with 140 character didn’t work well for me.  I decide to try it again because I am enjoying creating this running dialog.

- We’re trying to send large Photoshop files with mock-ups.  Some days technology just seems to work against us.  We’re hitting proxy issues and time out issues.  Eventually we solve the problem and remind ourselves yet again we should standardize on an approach.  Problem is, email and Skype are so convenient and work well enough most of the time.  I guess this would be one of those warts.

Agile software development methods should be able to survive in an atmosphere of constant change and still emerge with success.

Agile Management for Software Engineering by David J. Anderson

- After 40 plus years of eating sandwiches, I still love a good sandwich.  The best sandwich in town is from the deli in Vallergus and the people at the cash register all know me by sight.

- I never get back to the post after lunch.  Clients and partners all eat at different times and issues were waiting for me when I got back.  That is definitely a typical Monday.

- I didn’t finish the marketing text either.  The text I came up with was not remarkable.  I made some small updates to our corporate site instead and also finished my changes on ReachGivers.org.  Perhaps I will think of something while winding down for the night.

- My iPhone sits by my bed.  With several releases in play, there is always a chance a developer is still working and will fire off a question.  Of course, I can’t just let the device sit there, now can I?  I pull my canoe back out into the stream and see what else I might have missed during dinner.

This is a very simple Ruby on Rails plugin that allows easy encryption of strings. For the sake of simplicity there no customization. The only cipher used is ‘des-ede3-cbc’ (Triple DES using Cipher Block Chaining) . See my post on encrypting/decrypting a string with Ruby for more information. First install the plugin:

 script/plugin install git://github.com/handerson/string_encryption.git

Next we need to add an encryption key as the constant ENV['STRING_ENCRYPTION_KEY']. To do this just run

 script/generate encryption_key

or you could set

ENV['STRING_ENCRYPTION_KEY'] = "somekey"

where “somekey” is your key in environment.rb.

Now encryption/decryption is easy.

Encryption:

"Test".encrypt  #=> "NDFkZTc5NDEyNTg1MzdiZPzBrxZz5aoN%0A"

Decryption:

"NDFkZTc5NDEyNTg1MzdiZPzBrxZz5aoN%0A".decrypt  #=> "Test"

Code at Github:
http://github.com/handerson/string_encryption

I have followed the below steps to install RMagick on Ubuntu 9.04 - the Jaunty Jackalope

As Root via terminal

1) apt-get install imagemagick

2) gem install rmagick

It was a failure I was stucked with the below error.

gem install rmagick

Building native extensions.  This could take a while…

ERROR:  Error installing rmagick:

ERROR: Failed to build gem native extension.

/usr/bin/ruby1.8 extconf.rb install rmagick

checking for Ruby version >= 1.8.5… yes

checking for cc… yes

checking for Magick-config… no

Can’t install RMagick 2.12.2. Can’t find Magick-config in /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

*** extconf.rb failed ***

Could not create Makefile due to some reason, probably lack of

necessary libraries and/or headers.  Check the mkmf.log file for more

details.  You may need configuration options.

Provided configuration options:

–with-opt-dir

–without-opt-dir

–with-opt-include

–without-opt-include=${opt-dir}/include

–with-opt-lib

–without-opt-lib=${opt-dir}/lib

–with-make-prog

–without-make-prog

–srcdir=.

–curdir

–ruby=/usr/bin/ruby1.8

Gem files will remain installed in /var/lib/gems/1.8/gems/rmagick-2.12.2 for inspection.

Results logged to /var/lib/gems/1.8/gems/rmagick-2.12.2/ext/RMagick/gem_make.out

The Highlighted error was because of missing libraries and when i have googled the error I got a prompt solution to solve it by installing libmagick9-dev

but when i tried installing it also failed

“apt-get install libmagick9-dev

Reading package lists… Done

Building dependency tree

Reading state information… Done

Package libmagick9-dev is a virtual package provided by:

libmagickwand-dev 7:6.4.5.4.dfsg1-1ubuntu3.1

You should explicitly select one to install.

E: Package libmagick9-dev has no installation candidate”

It was solved by Installing “libmagickwand-dev”

4) gem install rmagick

its always a nightmare to debug
its more hard when the process is more depending upon the user input
test cases cant help many times but only manual testing

## in controller
def show
@debug_mode = false
if params[:debug] and (params[:debug].downcase == ‘true’ || params[:debug] == ‘1′)
@debug_mode = true
end
post = Post.find params[:id]
end
## in application_helper

def debug_an_object(obj)
“”"
This will print the content of the object passed
Usage :
// in controller
location = Location.find :first
// in view
<%= debug_an_object(location) %>

This will returns a table which contains the attribues of the object passed

“”"

str_table_start = “<table border=’1′ cellpadding=’2′ cellspacing=’2′ style=’font-size:11px;’>”
str_table_end = “</table>”

str_tr_start = “<tr>”
str_tr_end = “</tr>”

str_td_start = “<td style=’background-color:skyblue;’>”
str_td_end = “</td>”

str_html = str_table_start + “<tr><td style=’background-color:lightgreen;’>Name</td><td style=’background-color:lightgreen;’>Value</td></tr>”
for key,val in obj.instance_values['attributes']
str_td_key = str_td_start + key.to_s + str_td_end
str_td_val = str_td_start + (val.nil? ? “nil”:val.to_s) + str_td_end
str_tr = str_tr_start + str_td_key + str_td_val + str_tr_end
str_html = str_html + str_tr
end
str_html = str_html + str_table_end
return str_html
end

## in view

<%= debug_an_object(post)  %>

this will display the object in a table

Tenho recebido alguns comentários referentes ao andamento das rotinas de bancos e boletos que estávamos desenvolvendo a algum tempo atrás, então resolvi fazer um post rápido para informar a todos que o projeto está atualmente parado. O cliente com o qual estávamos trabalhando congelou o projeto e ainda não tem previsão de continuar com o desenvolvimento. Sendo assim, todo o código que desenvolvemos para a geração de boletos e guias também está congelado. Como é um código experimental, ou seja, ainda não foi efetivamente testado e homologado diretamente com nenhum banco, decidimos não divulgar nenhum código ainda.

Para quem está precisando gerar boletos em sua aplicação Rails, aconselho muito a utilização do projeto brcobranca, um plugin/gem criado pelo Kivanio Barbosa com a ajuda de alguns colaboradores (Shairon Toledo e Claudio Pozzebon), e que atualmente funciona com vários bancos diferentes (Banco do Brasil, Itaú, HSBC, Banco Real, Bradesco e Unibanco até então), além de geração direta para os formatos png, tif, jpg ou mesmo pdf.

Você pode encontrar mais informações sobre o projeto no github e também na página de exemplo, onde é possível gerar boletos de testes para todos os bancos e formatos disponíveis.

As a rails programmer all of you have come accross url like following

http://localhost:3000/albums/7

With the above url in browsers users can guest the next/other album details. For example users can guess that there might be ablums with id 8 or 9, which might not belongs to that particular user. Ofcourse we can always check the if the data is relevant to particular user by checking there session details.

Now there is another way of avoid such a  situation. We can use

UUIDHelper which generates a unique id which can use it as a secondary primary key for viewing data. I am sure that this kind of key wont be able to guess by users.

Step 1

To install UUIDTools gem

gem install uuidtools

Step 2

You need to have string field for above id ,  I am using a string field called s_id

Step 3

Create a file like lib/uuid_helper.rb and add the following content.

require 'rubygems'
require 'uuidtools'

module UUIDHelper
  def before_create()
    self.s_id  = UUID.timestamp_create().to_s
  end
end

Step 4

In your models you can use by including the helper methods

include UUIDHelper

Step 5

and you can override

def to_param
s_id
end

in this case the unique id generated is stored as s_id in database.

after that you can edit

Step 6

all the find methods to find_by_s_id(params[:id])

because after overriding to_param you are passing the s_id as id.

sample url after using UUID helper

http://localhost:3000/albums/

Ever wanted to connected to more than one database in a rails application ?

Here is how to do it.

in database.yml add your second database connection

example

# database.yml

development:

adapter: mysql

encoding: utf8

username: root

password:

database: store_development

#new connection

other_development:

adapter: mysql

encoding: utf8

username: limited_user

password: welcome

database: legacy_database

Now go to the model you want to use the new connection and add following

# app/models/guest.rb

class Guest < ActiveRecord::Base
     #specify other connection you want to use instead of default connection
     establish_connection :other_development
end



   

After learning how to build a cart that can keep track of orders, it’s time to make those orders happen. When we were dealing with our cart, we didn’t worry about creating database tables for the core thing the cart holds: cart items, so the time has come to finally create a model for that and for the orders taken (so they too will be stored at the database), and we’ll do it by using script generators at the command prompt:

ruby script/generate model order

ruby script/generate model line_item

A bunch of files should have been generated, including the migrations for these tables (remember migrations from Task A? Well, you should), so let’s edit each of ‘em for our specific needs. Starting with the create_orders migration file:

class CreateOrders < ActiveRecord::Migration
  def self.up
    create_table  rders do |t|
      t.string :name
      t.text :address
      t.string :email
      t.string :pay_type, :limit => 10

      t.timestamps
    end
  end

  def self.down
    drop_table  rders
  end
end

We’re just telling it to create specific filds with the name and type of data we want. Timestamps are the created_at and updated_at fields that every Rails table has. Anyway, moving on to the create_line_items migration:

class CreateLineItems < ActiveRecord::Migration
  def self.up
    create_table :line_items do |t|
      t.integer :product_id, :null=>false
      t.integer  rder_id, :null=>false
      t.integer :quantity, :null=>false
      t.decimal :total_price, :null=>false, :precision=>8, :scale=>2

      t.timestamps
    end
  end

  def self.down
    drop_table :line_items
  end
end

To make the migrations actually go into the database:

rake db:migrate

There’s a certain relation between products, orders and line items, an order includes line items, a product also includes line items, and line items are included by both. Of course we know this, but Rails doesn’t, and there’s a nice and easy to tell it. First, edit the order model file:

class Order<ActiveRecord::Base
  has_many:line_items
end

Now the product model file:

class Product<ActiveRecord::Base
  has_many:line_items
  #all the stuff we added in other tasks
end

And finally, the line item model file:

class LineItem<ActiveRecord::Base
  belongs_to:order
  belongs_to:product
end

Now that our tables are all set, let’s create a link on the cart partial to a checkout action:

<div class="cart-title">Your Cart</div>
<table>
  <%= render(:partial => "cart_item" , :collection => cart.items) %>
  <tr class="total-line">
  <td colspan="2">Total</td>
  <td class="total-cell"><%= number_to_currency(cart.total_price) %></td>
  </tr>
</table>
<%= button_to "Checkout",    :action=>:checkout     %>
<%= button_to "Empty cart" , :action => :empty_cart %>

The cart is now linking to a checkout action, which we will now create (on the store controller):

def checkout
  @cart = find_cart
  if @cart.items.empty?
    redirect_to_index("Your cart is empty")
  else
    @order = Order.new
  end
end

After finding a cart (on the session), the action will check if the cart is empty (maybe some smart guy is trying to make an order with an empty cart) and redirect case it is, case not, a new order is created. The logic for the checkout action is now all set, time to make its view file (checkout.html.erb):

<div class="depot-form">
  <%= error_messages_for 'order' %>
  <% form_for  rder, :url=>{:action => :save_order} do |form| %>
  <fieldset>
    <legend>Please enter your details</legend>
    <p>
      <%= label  rder, :name, "Name:" %>
      <%= form.text_field :name, :size=>40 %>
    </p>
    <p>
      <%= label  rder, :address, "Address:" %>
      <%= form.text_area :address, :rows=>3, :cols=>40 %>
    </p>
    <p>
      <%= label  rder, :email, "E-mail:" %>
      <%= form.text_field :email, :size=>40 %>
    </p>
    <p>
      <%= label  rder, :pay_type, "Pay with:" %>
      <%= form.select :pay_type, Order::PAYMENT_TYPES,
                      :prompt=>"Select a payment method" %>
    </p>
    <%= submit_tag "Place Order", :class=>"submit" %>
  </fieldset>
  <% end %>
</div>

The error_messages_for displays any validation error regarding the ‘order’ form, which we created in the line right below. The form_for helper takes a name (‘order’), a url to where the HTTP POST request will be sent to (in our case, a save_order action) and a block which will contain everything relating to the form, such as HTML tags and input fields. Notice the select method is using a constant which is in the Order class that we didn’t define yet, and that’s what we will be doing now along with adding some validation helpers:

class Order < ActiveRecord::Base

  PAYMENT_TYPES = [
    #Displayed        stored in DB
    ["Check",         "check"],
    ["Credit card",   "cc"],
    ["Purchase order","po"]
  ]

  validates_presence_of :name, :address, :email, :pay_type
  validates_inclusion_of :pay_type, :in => PAYMENT_TYPES.map {|disp,value| value}

  has_many :line_items
end

Try adding stuff to the cart and clicking the ‘Checkout’ button, a nice page should show asking for your information. All good, but the data still isn’t going into the database because we did’nt set the save_order method (which the form is pointing to), which we will be doing now by going through a few steps.
First we’ll be creating the save_order method on our store controller, which should capture an order, fill in an order model object with that order (which contains line items), validate the information case it’s wrong and finally redirect the user to the catalog page with a cheerful message. Getting down to the code:

def save_order
  @cart = find_cart
  @order = Order.new(params[:order])
  @order.add_line_items_from_cart(@cart)
  if @order.save
    session[:cart] = nil
    redirect_to_index("Thank you for your order")
  else
    render :action => :checkout
  end
end

We’re telling the code to find a cart, instace a new order based on the object sent by the form, add all items from the cart to that order and save it to the database, clearing the session and redirecting the user case that goes smoothly, or render back the checkout page case validation fails and the database isn’t able to save the data. To make this work, let’s define the add_line_items_from_cart method on the order model file:

def add_line_items_from_cart(cart)
  cart.items.each do |item|
    li=LineItem.from_cart_item(item)
    self.line_items<<li
  end
end

As you can see, it’s basically an iteration over the cart items that invokes a LineItem method and adds that result to the line_items array, which belongs to the order object itself. Now all we need to do is define that from_cart_item class method on the line item model file:

class LineItem < ActiveRecord::Base

  belongs_to  rder
  belongs_to :product

  def self.from_cart_item(cart_item)
    li = self.new
    li.product = cart_item.product
    li.quantity = cart_item.quantity
    li.total_price = cart_item.price
    li
  end
end

All this is doing is associating a cart_item (which came from the cart object iteration in the add_line_items_from_cart method) with a new instance of LineItem that will later on be saved into the database when the method @order.save is called. And how is it possible to save an order and save all the line items that correspond to that order without calling the save method on each LineItem? Simple, remember the association we did at the beggining where an Order has_many :line_items and a LineItem belongs_to rder? We did that to tell Rails that a relation exists between them, so it would automatically associate everything into the database and save all the LineItems that corresponded to that specific Order. Try adding some items to the cart, checking out, filling in correct information and placing the order, you’ll see that everything is placed perfectly in the database and a nice message appears at the catalog page.

Lastly we’ll be adding a small AJAX feature that will make the “Thank you for your order” message disappear when a user is starting a new order after placing and order before that. This can be done with a simple line of code to our add_to_cart RJS template:

page.replace_html("cart",:partial => "cart",  bject => @cart)

page[:cart].visual_effect :blind_down if @cart.total_items == 1

page[:current_item].visual_effect :highlight,
                                  :startcolor => "#88ff88",
                                  :endcolor => "#114411"
page.select("div#notice").each {|div|div.hide}

The page will now browse through all the divs with the ‘notice’ ID and hide them on any request made, so that the thanking message will disappear after any user interaction.

Before we finish things off, I’m gonna add some things that weren’t specified in the book. If you, like me, noticed that there isn’t an orders controller (I thought it was going to be added later, but it didn’t), you should also, like me, feel the urge to add it. With no controller, we cannot view the orders that were made, which is bad because how would our depot admin know where to ship the products to? Anyway, let’s get started on that, first thing we’ll do is generate our controller with an index, show and destroy methods:

ruby script/generate controller orders index show

As you’ll see, this is a pretty basic controller that could be easily generated by scaffold, and there’s nothing different to explain about it, so here’s the whole code:

class OrdersController < ApplicationController

  def index
    @orders = Order.all
    respond_to do |format|
      format.html
      format.xml {render  ml => @orders}
    end
  end

  def show
    @order = Order.find(params[:id])
    respond_to do |format|
      format.html
      format.xml {render  ml => @order}
    end
  end

  def destroy
    @order = Order.find(params[:id])
    @order.destroy

    respond_to do |format|
      format.html { redirect_to(orders_url) }
      format.xml  { head  k }
    end
  end

end

We added the method destroy by hand so the generator wouldn’t create a view file for it. Moving on to the view files, let’s start with the index page:

<h1>Listing orders</h1>
<table>
  <tr><th>Buyer Name</th></tr>
  <% for order in @orders %>
  <tr>
    <td><%=  link_to order.name, order %></td>
  </tr>
  <% end %>
</table>
<br />

Basic iteration through all orders with a link to each of them. On with the show page:

<p>
  <b>Buyer Name:</b>
  <%= h @order.name %>
</p>

<p>
  <b>Address:</b>
  <%= h @order.address %>
</p>

<p>
  <b>E-mail:</b>
  <%= h @order.email %>
</p>

<p>
  <b>Payment type:</b>
  <%= h @order.pay_type %>
</p>

<p>
  <b>Line Items:</b><br/>
  <% for item in @order.line_items  %>
  <%= item.quantity %> &times; <%= link_to(item.product.title, product_url(item.product))  %> = <%= number_to_currency item.total_price %><br/>
  <% end %>
</p>

<p>
  <b>Total price:</b>
  <%= number_to_currency @order.total %>
</p>

<%= link_to 'Back', orders_path %>
<%= link_to 'Destroy', @order ,:confirm => 'Are you sure?',:method => :delete %>

As learned in this task, an order has many line items, so to show an order, we need to iterate through every line item it has, which we did here by adding the line item quantity, the a link to its product and the price of that line item. Lastly there’s a call to a total method which isn’t defined in our order model, so let’s add that:

def total
  self.line_items.sum(:total_price)
end

The sum method iterates through all the line items and sums their total_price, returning a total order price.

That’s pretty much it, we now have an application with a cool shopping cart that is now able to place orders.

It was fun — pure unadulterated fun!!

Now, I started looking at heroku since our current deployment on a linode was getting a little bulky. Our client has been complaining of ’suddenly things slowing down’ and ’site not working’. The site is used at a hit rate of 36 Requests per minute and we need to keep our hosting costs down — so what is the solution???

Currently, its hosted on a linode (740MB) memory and and nginx + 3 thin cluster. There is monit which ensures that ANY thin server going above 140MB is restarted. BackgrounDrb is taking a lot of memory too ( an unavoidable 160MB) and we have ferret to make things more complicated !!

Enter Heroku – first thing that got me hooked was a ‘git push heroku’ DEPLOYS your application! Fantastic. I have been a capistrano freak till now and loved it – but its all gone now! (wonder if thats good or bad though).  LoL

So, to get started, you sign-up on heroku and follow instructions on your My Apps page:

$ heroku create
$ git init && git add . && git commit -m"initial checkins"
$ git push heroku

I used the Blossom account (5 MB space) and was pleasantly surprised to see it work ‘out of the box’. It created some wierd named sub-domain for me which I changed using

$ heroku rename <new-name>

Digging deeper, I wanted to deploy the application ‘as is’ but that was not to be:

Setup Woes

Heroku uses PostGres and we had used MySQL – you need to ensure that there are no special data types being used. As goes Murphy’s law – we had used blob and had to change that the bytea (bytearray in PG). The interesting thing I found was that there is NO way to drop the database and re-create it. The answer lies in:

$ heroku rake db:schema:load

Production environment is assumed. I was not sure which environment I am in till I issued the command (after reading up) that I was in production mode:

$ heroku config
RACK_ENV => production

I was also curious to see how I get the logs and check the console and it really ROCKS:

$ heroku logs
$ heroku console

Alas I could not find a way to access the dbconsole (like what I do sometimes with script/dbconsole -p). Well, that is the way it is!

Ferret Woes

Heroku does not use ferret – it uses solr and sunspot. I had to install these additional gems using the gem manifest i.e. the .gems file located at RAILS_ROOT.

rupport
acts_as_ferret
prawn
$ git commit
$ git push heroku

Since acts_as_ferret is installed, it loads the Rails models and ‘expects’ the database to be in place. So, I had to comment out ALL the references to acts_as_ferret to be able to run a

$ heroku rake db:migrate

So far so good. Now, since ferret requires to index files and heroku mounts the deployment on a read-only filesystem, we need to tweak the configurations to ensure that the index is created in tmp/ (the are where we can write stuff). Add the following lines to the config/environments/production.rb

require 'acts_as_ferret'
ActsAsFerret.index_dir = "#{RAILS_ROOT}/tmp/index"

Now, default ferret production environment is to start a Drb server on 9010 port — and Heroku will not allow this! So, we have to comment out all the configuration in config/ferret_server.yml to ensure that this loads like it does in development. I hate this but no alternative for now. I do plan to migrate to the WebSolr that Heroku is offering but its at 20$ per month! Lets see how that works out.

This should at least get you started on ferret – phew!

BackgrounDrb woes

BackgrounDrb comes with its own baggage I must say. Heroku proposes the use of DelayedJob (yippee) and I have just this plan, so rather than even try to figure out a way to get backgrounDrb to work on Heroku, I simply commented out the config/backgroundrb.yml settings (to ensure it does not get initialized).

I also had to comment out all the MiddleMan references in the controller. The backgrounDrb workers are easily  modified so that they can work as DelayedJob objects . I have mentioned this in my earlier posts Moving from BackgrounDrb to DelayedJob

Once this was done, I did not face any problems and after some quick code fixes, git commits and git push’es, I was able to get my heroku application up and running.

All in a days work! Thats really amazing. Now, the next step is to get WebSolr  and DelayedJob integrated and see if I can move onto a bigger storage setup — a couple of months will let me know if this move was right.

It was great to see so many solutions for the problem statement I had set. After an initial ’shock’ from all electrical engineers, the problem was clearly understood as a variant of the ’shortest path algorithm’. I hope I was able to derive a laugh from the cryptic clue ’short-circuit’.

Speaking of ‘derive’, I did see most solutions going into a class implementation of  ’class Graph’ or ‘class Vector’. Though its pretty cool to see a complete packaged solution, I believe this was a slight overkill. This was NOT the basis of judging but I do feel that ruby has its essence in getting the job done in far lesser code. i.e. less LOC. So, I personally did not foresee 3-4 classes with inheritance in them.. I do totally agree its an excellent way to show-case one’s skills  ;)

Djikstra’s algorithm seems to be the popular hit for solving this problem – however, I do feel a recursive solution than an iterative one is more appropriate for this. Again this is just an opinion but to get a sense of the power of ruby programing, a recursive program probably paints a better picture. Its also very concise and readable.

A lot of effort was spent in ‘initializing’ the data-structure. This was really nice to see — unlike me, who took a short-cut. The aim was to see the algorithm but I was really proud to see ‘complete’ solutions. Test cases were written in most solutions and it was a pleasure to see them run.

It was interesting to see various forms of Infinity:

Infinity = 1 << 64
Infinity = 1 << 32
Infinity = 1.0 / 0 # simple and ideal
Infinity = 1000000 # incorrect

It was interesting to note that very few catered for multiple shortest paths, though the question was raised in the comments earlier. Not trying to be a hypocrite here, I should say that I too did not implement multiple shortest paths – LoL.

My solution to the problem is provided at http://github.com/gautamrege/short_circuit and its merely a representation of my style of programing. Creating a gem was for kicks but lib/short_circuit.rb has the core code. It was great fun AND learning while doing this and I realized that I will always be a student.

Cheers!

El plugin Authlogic (de BinaryLogic) es un excelente recurso a la hora de facilitar la autenticación de usuarios en nuestros sitios web. Se caracteriza por ser muy fácil de configurar, utilizar y extender (existen otros plugins que le agregan funcionalidad, como Lockdown). Por supuesto, tiene un muy buen nivel de seguridad y muchas funcionalidades extremadamente útiles que, de hacerlas a mano, nos tomaría mucho tiempo implementar.

Este tutorial está basado en el sitio de ejemplo oficial de Authlogic, en GitHub.

1- Instalación

Authlogic se puede instalar como gem o como plugin.

A) Para instalar como plugin (recomendado por ellos mismos):

$ ./script/plugin install git://github.com/binarylogic/authlogic.git

B) Para instalar como gem, basta agregar lo siguiente a environment.rb

# config/environment.rb
config.gem "authlogic"

Luego, ejecutar en la consola (si usás linux quizás necesites correrlo con sudo):

rake gems:install

2- Crear el modelo UserSession

El modelo UserSession es aquel que se va a encargar de administrar todo lo que tiene que ver con una sesión en nuestro sitio: su creación (login), su actualización, y su destrucción (logout). Como ellos mismos comentan en su sitio de ejemplo, de la misma forma que ActiveRecord se sitúa entre nosotros y la base de datos, el modelo UserSession se situá entre nosotros y las cookies del usuario.

Asumiendo que lo que queremos autenticar es un modelo nombrado User, vamos a crear nuestro modelo UserSession. En la consola:

script/generate session user_session

Esto va a crear un archivo similar al siguiente:

#app/models/user_session.rb
class UserSession < Authlogic::Session::Base
  # aquí va la configuración
end

Es importante destacar que este modelo hereda de Authlogic::Session::Base, lo cual nos permitirá configurarlo muy fácilmente. Por ejemplo, es aquí donde podemos proteger a nuestros usuarios de ataques de fuerza bruta. Para más información, ver la documentación de los submódulos de Authlogic::Session.

3- Crear el modelo User

El modelo User es el modelo que guarda la información de registro de los usuarios. Se pueden incluir todos los campos que sean necesarios para nuestra aplicación, pero existen algunos campos que Authlogic administra de forma automática, facilitando muchísimo nuestro trabajo. Pero primero, creemos el modelo: en la consola,

script/generate model user login:string crypted_password:string

Authlogic utilizará este modelo para autenticar. El tutorial oficial (en inglés) incluye una lista que muestra cuáles son los campos administrados por Authlogic. Todos los campos son opcionales excepto el que se utiliza para que la sesión persista: persistence_token. Para este tutorial utilizaremos una combinación de nombre de usuario y contraseña para autenticar. Como fueron especificados como parámetros, ambos campos (login y crypted_password, respectivamente) fueron añadidos automáticamente por Rails a nuestro archivo de migración cuando corrimos el generador anterior. Por lo tanto, podemos directamente ejecutar rake db:migrate para crear la tabla users junto con dichos campos en nuestra base de datos.

4- Configurar el modelo

Configurar el modelo es extremadamente simple:

class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.opcion = valor # ver documentación
  end # el bloque es opcional
end

A partir de ahora el modelo intentará validar automáticamente los campos nombre de usuario, email, contraseña, etc. La configuración en bloque nos permite personalizar cómo queremos que se validen esos campos, definir nombres distintos para los campos o incluso cambiar el algoritmo de encriptación para la contraseña.

5- Crear el Controlador para UserSessions

Es a través de este controlador que el usuario iniciará y cerrará su sesión. Es importante aclarar que este controlador no debería ser usado para registrar usuarios u otras acciones similares que tienen que ver con la administración de usuarios; lo utilizaremos simplemente para iniciar o cerrar sesión. En la consola:

script/generate controller user_sessions

Aquí hay un ejemplo del contenido básico de un controlador de UserSessions. También existen ejemplos paras las vistas correspondientes. Sin cambiar lo básico, podemos agregar toda la funcionalidad que queramos, tanto a las vistas como al controlador.

En cuanto a las rutas, hace falta conectar el modelo UserSession con el controlador. Para lograrlo:

#config/routes.rb
map.resource :user_session

6- Persistiendo Sesiones

Para persistir sesiones utilizaremos el ApplicationController. Agregaremos algunos métodos al controlador y a dos de ellos los convertiremos en métodos helper, para poder accederlos desde las vistas. Estos métodos fueron extraídos del sitio ejemplo, son simplemente ilustrativos y pueden ser personalizados según la necesidad.

# app/controllers/application.rb
class ApplicationController < ActionController::Base
  helper :all
  filter_parameter_logging :password, :password_confirmation
  helper_method :current_user_session, :current_user

  private
  def current_user_session
    return @current_user_session if defined?(@current_user_session)
    @current_user_session = UserSession.find
  end

  def current_user
  return @current_user if defined?(@current_user)
    @current_user = current_user_session && current_user_session.user
  end

  def require_user
     unless current_user
       store_location
       flash[:notice] = "You must be logged in to access this page"
       redirect_to new_user_session_url
       return false
     end
   end

   def require_no_user
     if current_user
       store_location
       flash[:notice] = "You must be logged out to access this page"
       redirect_to account_url
       return false
     end
   end

   def store_location
     session[:return_to] = request.request_uri
   end

   def redirect_back_or_default(default)
     redirect_to(session[:return_to] || default)
     session[:return_to] = nil
   end
end

Ahora tendremos acceso al usuario y su sesión en toda nuestra aplicación, con sólo llamar a current_user y current_user_session, respectivamente.

7- Restringiendo Acceso

Authlogic se encarga simplemente de la autenticación, pero nos permite restringir acceso en nuestros controladores de forma muy fácil. Lo podemos hacer a mano o utilizando algún otro plugin que agregue esta funcionalidad. Lockdown es un plugin muy bueno que permite restringir acceso según los roles que tenga un usuario, y se integra de forma excelente con Authlogic.

Sin embargo, aquí incluiremos un ejemplo muy simple de cómo restringir acceso manualmente dentro de uno de nuestros controladores. En nuestro ApplicationControler:

# app/controllers/application.rb
class ApplicationController < ActionController::Base

  #... (código anterior)

  def require_user
     unless current_user
       store_location
       flash[:notice] = "You must be logged in to access this page"
       redirect_to new_user_session_url
       return false
     end
   end

   def require_no_user
     if current_user
       store_location
       flash[:notice] = "You must be logged out to access this page"
       redirect_to account_url
       return false
     end
   end

   def store_location
     session[:return_to] = request.request_uri
   end

   def redirect_back_or_default(default)
     redirect_to(session[:return_to] || default)
     session[:return_to] = nil
   end
end

Y luego utilizamos estos nuevo métodos en nuestros controladores. Por ejemplo, si queremos que una lista de productos pueda ser vista por cualquier persona, pero que sólo usuarios logueados puedan administrarla (crear productos, actualizarlos, borrarlos, etc.), hacemos lo siguiente en nuestro ProductsController (asumiendo que existe):

# app/controllers/products_controller.rb
class ProductsController < ActionController::Base
  before_filter :require_user, :except => [:index, :show]

  #GET /products/new
  def new
    #...
  end

  # ... (resto del código)
end

De esta forma, si una visita intenta añadir un producto accediendo a “sitio.com/products/new”, será redirigida automáticamente al formulario de login para que se identifique con su usuario antes de poder continuar. Esta lógica se encuentra en el ApplicationController, dentro del método require_user.

8- Registrando Usuarios

Registrar usuarios es muy simple con Authlogic. De hecho, funciona exactamente igual que si no lo usáramos, siempre y cuando utilicemos las acciones CRUD estándar. Esto es debido a que Authlogic se inyecta automáticamente en el modelo, y por lo tanto no nos tenemos que preocupar en absoluto de nada que tenga que ver con lógica que hay detrás de registrar un usuario. Es más, tampoco es necesario preocuparnos de encriptar la contraseña antes de almacenarla en la base de datos. Authlogic se encarga de todo. Y si lo que buscamos es un poco más avanzado, Authlogic es muy fácil de configurar y extender (ver la documentación).

9- Próximos Pasos

La gente de BinaryLogic incluye una lista de próximos pasos que pueden o no ser implementados. Todos remiten a una sección en particular dentro de la documentación de Authlogic. Aquí la incluyo traducida:

1. Querés usar otro algoritmo de encriptación, como BCrypt? Ver Authlogic::ActsAsAuthentic::Password::Config
2. Migrando de autenticación REST? Ver Authlogic::ActsAsAuthentic::RestfulAuthentication::Config
3. Querés que las sesiones expiren automáticamente después de un período de inactividad? Ver Authlogic::Session::Timeout
4. Necesitás restringir tus sesiones a una cuenta o modelo en particular? Ver Authlogic::AuthenticatesMany
5. Necesitás muchos tipos diferentes de sesiones? Ver Authlogic::Session::Id
6. Querés permitir que los usuarios reestablezcan sus contraseñas o confirmen su subscripción? Utilize una clave de expiración automática. Ver Authlogic::ActsAsAuthentic::PerishableToken
7. Querés dar acceso privado a una API o canal RSS? Utilice autenticación básica por HTTP o por parámetros. Ver Authlogic::Session::HttpAuth o Authlogic::Session::Params
8. Necesitás ayuda con tus pruebas? Consulta Authlogic::TestCase

Créditos

Este tutorial está estructuralmente basado en el tutorial oficial de Authlogic (en inglés). Mucho del código lo extraje de allí directamente, aunque me tomé libertades en cuanto a su presentación y en algunos casos le cambié en formas que me parecieron más convenientes.

Si este tutorial fue de provecho, no dudes en comentar! Lo mismo si encontraste errores o quisieras dar alguna sugerencia.

También podés subscribirte al feed para mantenerte al tanto de los artículos más frescos.