Some information about session and caching in Rails!!

What is Session?
A session is a method of storing object data temporarily between different requests. A session makes it easy to work with logged-in users because you do not have to authenticate them each time they access a protected area of the application. Instead, you can authenticate them once and store their data in a session. A session is merely a container for storing a user’s current state in a web application. Unlike a cookie, session information is stored on the server instead of the client’s computer. Rails offer 4 different ways to store data in session.
1. Memory Store
Rails keeps your session data in server memory
2. ActiveRecord Store
Rails keeps session data in session table in the database
3. Drb Store
This store uses distributed Ruby to store a user’s session data. The performance is great, but it requires a bit more setup than the other stores.
4. PStore
This is the default solution that is used in Rails. Using PStore, your session data is stored in small temporary files on your hard drive. These files are usually located in the tmp/sessions folder for the Rails app. The main downside of using the PStore is that you will have to do some session-pruning periodically because performance decreases as the number of sessions stored increases.

What is Caching?
Caching is the process of saving a copy of the results of a web request on the server or a local machine for subsequent requests
Types:
1. Page:
Whole static page is cached. Not suitable for dynamic pages like greeting messages, etc.
2. Action:
This is useful for authenticated users. It helps to keep the dynamic content on the sidebar.
3. Fragment:
You need to cache the portion of a page like header and footer.

Four places to keep the cache:
1. MemoryStore: This store keeps the fragments in your application's memory, which can potentially take up a lot of memory on your server. It is used by default, but it is hard to manage and scale if your application becomes popular.
2. FileStore: This store keeps the fragments on the hard disk instead of in memory. It works well if you have a lot of file storage and have outgrown the MemoryStore.
3. DRbStore: This store keeps the fragments in the memory on a separate shared Drb server (Drb stands for Distributed Ruby). It keeps only one cache around for all processes. This is a complex solution because it involves setting up a secondary server.
4. MemCacheStore: Similar to DRbStore in that it stores your caches on a separate server, but uses the MemCache library. It also requires you to install the ruby-memcache library.

configuring Capistrano #1

Details

In this article, I have taken quite a bit of space to try and explain what each setting is, and what it does.

As such, don't be put off by the apparent length of the article as, by the end of it, you will understand and have a good grasp of what is happening when you use Capistrano.

deploy.rb

If you are not in the rails application folder, then move there now (remember this is on your local workstation and not on your Slice):

cd ~/dev/project1

The location may vary depending where on your workstation you have placed the rails application.

Let's get straight on and open up the Capistrano deploy file:

nano config/deploy.rb

The default file looks like this:

set :application, "set your application name here"
set :repository,  "set your repository location here"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, "your app-server here"
role :web, "your web-server here"
role :db,  "your db-server here", :primary => true

Fairly simple and, apart from a few additions, is sufficient to get started.

Application, user and repository

Seem logical to start at the top of the file and work our way down so the first thing is the application name.

This can be anything you like. However, it makes a lot of sense to use the domain name as the application name.

This means that the 'application' variable can be used further on in the file and it keeps in line with the protocols we are already using when naming vhost files, etc.

So, set the application name as follows:

set :application, "domain.com"

Next we will add a variable for a username. It's important you set a user here as permission issues often arise from using your local workstation username instead of the Slice username.

Add this line straight after the application variable:

set :user, "demo"

For the repository, enter the same details that you used to check out project1:

set :repository,  "svn+project1ssh://123.45.67.890/home/demo/repository/project1"

SSH port

One essential setting that is not mentioned is how to define the SSH port.

When Capistrano connects to your Slice via SSH it will use port 22 (the default SSH port). However, when we setup the Slice, we defined the SSH port to be 30000.

Capistrano needs to know about this.

Setting the port is as simple as:

set :port, 30000

Deployment path

Now the SSH port has been set, we can set the deployment path.

When we setup the Slice and Nginx vhosts, we used the public_html folder in our home directory.

We've already set the application name (see above) so we can use that variable again.

So the next line to add is this:

set :deploy_to, "/home/demo/public_html/#{application}"

Note the use of the 'application' variable at the end of the entry. If we changed the 'set :application' name, that change would be reflected in this setting.

App, web and db

The final 3 settings (at this stage) are shown as 'app', 'web' and 'db'.

The vast majority of users will have all 3 variables pointing to the same place so it can seem a little confusing to have 3 settings here as if they are different things.

However, do remember that you can have your database (db) on another Slice and so on. These settings are then very useful as it tells Capistrano where the db is, where the app is and so on.

As an aside, we can define a new variable here and call it 'location'. We can then assign a URI to that variable and use it in all 3 settings.

So this section could look something like this:

set :location, "domain2.com"

role :app, location
role :web, location
role :db,  location, :primary => true

That is one way of doing it and I mention it as an option for you to play with.

For this example though, I am simply going to use the 'application' variable as everything is happening on the single Slice.

As such, the 3 settings will look like this:

role :app, application
role :web, application
role :db, application , :primary => true

Completed file

So this is what the completed deploy.rb will look like:

set :application, "domain.com"
set :user, "demo"
set :repository,  "svn+project1ssh://123.45.67.890/home/demo/repository/project1"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

set :port, 30000

set :deploy_to, "/home/demo/public_html/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, application
role :web, application
role :db, application , :primary => true

Still pretty basic as this stage (there is lot more we can do later on) but it is enough to enter our first Capistrano command...

public_html

Before we enter the first command, let's log into our Slice and move into the public_html folder:

ssh -p 30000 demo@123.45.67.890

cd /home/demo/public_html

Unless you already have a working Slice, the directory is going to be empty:

ls

That produces no output as the folder is empty.

Well, let's enter our first Capistrano command and then have another look.

deploy:setup

Back on our local workstation (not the Slice!) we can now enter:

cap deploy:setup

Pretty minimal stuff.

However, exciting things are taking place and this really shows not only the power, but the ease of using something like Capistrano.

So what happened?

Well, let's take another look at the public_html folder on the Slice:

ls
...
domain.com

That's new.

Directory Structure

What Capistrano has done is really quite clever.

It's logged into the Slice and, using the settings from the deploy.rb file, has created a directory structure that will be used for future deployments.

Inside the parent folder are two folders called 'releases' and 'shared'.

Inside the 'shared' folder are permanent folders for the logs, pids and system info.

So from one command, Capistrano is now ready to deploy the application.

Nice.

Summary

We've configured the deploy.rb file that Capistrano uses to setup and deploy our application.

Then, using a single command, we created the directory structure that will be used for future deployments.

A lot has happened, but now that we are more familiar with the deploy.rb file, we can move on to deploying the application.

Apache vhosts, rails and mongrels

There are several ways of serving a Ruby on Rails application, one of which is to use Apache to proxy requests to mongrels.

There are a few ways of completing this and we're going to look at one simple solution. Other ways will be looked at in future articles.

---

Setup

Just a quick note on where we are in the setup. I have my base Ubuntu Feisty installed which I updated and secured. I then installed MySQL and Ruby on Rails as per this article.

Once the basics were done I then proceed to install Apache and PHP. Of course, you can leave out the PHP part.

I then created a public_html folder in my home partition and created the correct permissions as shown here.

Rails Application

You can use a pre-existing Rails application or, like me, create a new one from scratch. To create a new one, move into your public_html folder:

cd /home/demo/public_html

and create a new Ruby on Rails application:

rails railsapp

move into the directory:

cd railsapp

You will notice that the created folders are very similar to the default vhosts layout I describe here

As such, we don't need to create any extra folders as the Apache logs can go into /log and so on.

Mongrels

Let's install the mongrels via ruby gems:

sudo gem install mongrel --include-dependencies

Once done we can move onto the Apache configuration.

Apache modules

Apache will need certain modules to be enabled to allow it to pass the requests to the mongrels.

There are four specific modules that we need. Enable them like so:

sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http
sudo a2enmod rewrite

As suggested by the module commands, reload Apache:

sudo /etc/init.d/apache2 force-reload

Virtual host

Now we need to create a new virtual host for the 'railsapp' we created earlier:

sudo nano /etc/apache2/sites-available/domain.com

Obviously use your domain name instead of my example of domain.com

At this stage we are only doing a basic configuration so you can enter the following in the vhosts file:

 ServerName domain.com
 ServerAlias www.domain.com

 DocumentRoot /home/demo/public_html/railsapp/public

 RewriteEngine On

 
   BalancerMember http://127.0.0.1:8000
   BalancerMember http://127.0.0.1:8001
 

 # Redirect all non-static requests to Mongrel
 RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
 RewriteRule ^/(.*)$ balancer://mongrelcluster%{REQUEST_URI} [P,QSA,L]

 ProxyPass / balancer://mongrelcluster/
 ProxyPassReverse / balancer://mongrelcluster/
 ProxyPreserveHost on

 
   Order deny,allow
   Allow from all
 

 # Custom log file locations
 ErrorLog  /home/demo/public_html/railsapp/log/error.log
 CustomLog /home/demo/public_html/railsapp/log/access.log combined

Take each section at a time and you will see that the basics are exactly the same as for a 'normal' vhost configuration.

We have the ServerName, DocumentRoot and Log locations.

Where it differs is the addition of the Proxy settings.

In this example, we will use 2 mongrels running on ports 8000 and 8001 in a balancer named 'mongrelcluster' (call it something more expressive if you have several rails sites - it is also not technically a mongrel cluster but, hey, it's a good name).

The next sections tell Apache to pass the proxy request to the defined balancer. It then sets the permissions on the Proxy so we don't have a dreaded permissions error.

Do note the trailing slash (/) is very important in the ProxyPass settings. Miss them out and it won't work.

Enable

After all of this, don't forget to enable the new vhost:

sudo a2ensite domain.com

And as requested:

sudo /etc/init.d/apache2 reload

If you have a warning regarding mixed ports, you will need to ensure the default vhost has been changed to reflect specific port access as follows:

NameVirtualHost *:80

...
...

Reload Apache and the warning will have gone.

Start your engines

All that's left is to start the two mongrel processes on the ports defined in the vhost. If you are not already in your railsapp directory, move there now:

cd /home/demo/public_html/railsapp

We will start two separate mongrels:

mongrel_rails start -d -e production -p 8000 -P log/mongrel8000.pid
mongrel_rails start -d -e production -p 8001 -P log/mongrel8001.pid

As Feisty uses ruby -v1.8.5 as the default you will received a warning:

** Ruby version is not up-to-date; loading cgi_multipart_eof_fix

It is just a warning and, until the aptitude version is updated or you install from source, nothing to be concerned about.

Navigate

Once done, navigate to your domain:

http://www.domain.com

Dojo Button and Rails Helpers

When i tried to use dojo buttons on rails partials , i felt happy about dojo widgets.

But if i have to use save_tag button or i want to include button in link_to_remote function,
I dont have option to get dojo style button.

I have used firebug to get the required dojo classes for dojo button and created following helper methods.

def dojo_button(name)
'+name.to_s
end
def dojo_button_class
"dijit dijitLeft dijitInline dijitStretch dijitButtonNode dijitButtonContents dijitButton"
end
Remember u need to use dojo.parser.parse() method of making ajax call using partials.

Ruby: Floating point round off

my method of doing this as

def round(float, decimal_places) # By Jagan Reddy
exponent = decimal_places + 2
@float = float*(10**exponent)
@float = @float.round
@float = @float / (10.0**exponent)
end

In short we can also do this way

class Float
def round_to(i)
  (self * 10**i).round.to_f / 10**i
 end
end
value = 1328.3337
value.round_to(3)
=>1328.334

save_tag to avoid multiple click in IE and Firefox

##############################################################################
# Overrides sumit_tag for disable save after click event --JAGAN REDDY
##############################################################################
def commit_tag(value,options={})
options.stringify_keys!
submit_tag value, options.merge(:onclick => '

if(window.addEventListener)
{
this.disabled = true;
}
else
{ // IE
// this.disabled = true;
setTimeout(m(), 10000);
}
function m()
{
// var tag = window.event.srcElement.tagName
this.disabled = true;
}')
end

use this in apllication_helper.rb