The purpose of SSL is to provide a reasonable level of protection against eavesdropping and man-in-the-middle attacks. Although SSL provides a greater level of security, it introduces a lot of overheads and hence should be used sparingly. Two of the most common places to use SSL is for payment transactions and user registration/login.
This post intentionally focuses only on the Rails application as there are numerous post on the net for SSL setup on the server. Enabling SSL in a Rails application is really trivial and there are just a few points that need your attention..

1. Enabling SSL
a. Install the ssl_requirment plugin:

./script/plugin install git://github.com/rails/ssl_requirement.git

b. Include it in your application_controller.rb:

include SslRequirement

c. Specify actions that require SSL in their respective controllers. For eg. my session controller has the following line:

ssl_required  :new, :create if Rails.env.production?

d. Add the following line in development.rb to bypass SSL in development mode:

SslRequirement.disable_ssl_check = true

2. Gotcha’s
a. Include all submit actions in requirement
Any action that processes form data from a SSL page should also be added to the requirement. In the above example, the form on the login page(new action) is processed by the create action and hence it is also included in the requirement.
b. Ajax actions
Ajax actions on a SSL page should also use SSL and must be included in the requirement. At times you do not have a body for the Ajax action and it is rendered using it’s respective RJS template. In such cases create an empty action and include it in the ssl_requirement.
c. Mixed content
A lot of browsers show you a “Mixed Content Warning” if your SSL page references non-SSL assets. IE displays a scary looking confirmation dialog while Firefox and Chrome show a exclamation in the url bar. Any relative paths(eg. using _path helpers) on the page will automatically use the https protocol but any absolute paths(eg. using _url helper or by manually specifying as a string in link_to) will need to be changed to use https.
d. Asset host issue
If you are using Rails asset hosts and do not have a SSL certificate that supports wildcard(for subdomains), then you need to disable them for the SSL pages. Just add the following code to your production.rb:

ActionController::Base.asset_host = Proc.new { |source, request|
  if request.ssl?
    "#{request.protocol}#{request.host_with_port}"
  else
    "#{request.protocol}assets%d.yourdomain.com" % (source.hash % 4)
  end
}

Replace “yourdomain” with your apps domain and “4″ with the number of asset hosts required.

The above should ensure that you have a proper SSL setup without displaying warnings to the user.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This is my very first blog post and so I though it should be about a tool that is indispensable for me – Git. I started using git about 10 months ago and looking back I can’t imagine how I managed to get work done without it. The purpose of this post however is not to sing git’s praises, there are lots of good articles on the web that do so much better than I ever could. Instead, I wish to share the work-flow I use on my projects. I developed this work-flow by trial and error over the months and is currently the most efficient and productive approach I can think of. If any experienced git users happen to stumble upon this post, please do provide suggestions/alternatives to help me improve my process.

The project I am currently working on requires me to maintain two parallel deployment branches. One is a “production branch” which is deployed on the live server and the other is a “development branch” which is deployed on a staging server. All enhancements and feature additions are done in the “development branch” and the only changes made in the “production branch” are production bug fixes that need urgent attention. Once the “development branch” is deemed stable it is merged into “production branch” and deployed.

I’ve divided my work-flow into two parts. The first part is a generic approach which I follow in all projects, the second part is specific to the case mentioned above and discusses how I manage the two branches using git. Although I mention “Rails” in the title of this post, the work-flow I define below is not “Rails” specific and can be applied to any project where multiple deployment branches need to be maintained. I assume the reader has a basic understanding of git and is comfortable with git branches. There are lots of configuration settings in git which help you setup things like you git author name, email and colors for git commands etc. There are two I would like to mention here though:

git config --global push.default "tracking"

This command tells git to perform a push only to the tracked remote branch in which you are currently working.

git config --global pack.threads "0"

This command tells git to auto-detect the number of threads to use for packing repositories and is useful when working on a machine with more than one core.

1. Generic Workflow

a. Start with a clean master branch.

git checkout master
git pull

You now have a clean master branch. Never work directly in the master branch, instead make all changes to a local branch.

b. Create a local branch.

git branch my_local_branch
git checkout my_local_branch

or do both in one command:

git checkout -b my_local_branch

This creates a new local branch named “my_local_branch” and switches to it. You can now perform all changes in this branch. One good practice to follow when using git is to commit often and in small chunks. This gives you finer control on the work done and allows you to fix mistakes without losing other work. Once you are satisfied, all those smaller commits can be consolidated in a single meaningful commit.

c. Merge with master branch.

git checkout master
git pull

if new changes were pulled do the following:

git checkout my_local_branch
git rebase master

A rebase will apply the newly pulled changes in the master branch to your local branch and then apply local branch changes on top of that. This will ensure a clean merge with master. Conflicts are very common during a rebase and will need to be resolved before you can have a successful rebase. You can also pass the “-i” option to rebase to perform an interactive rebase which will alllow you to squash multiple commits into one if you so require. Once you are finished with the rebase do the following:

git checkout master
git merge my_local_branch
git push

Once you are satisfied with the push you can delete the local branch:

git branch -d my_local_branch

2. Managing Multiple Deployment Branches

The master branch is set as the branch for production deployment and a new remote branch is created for development phase. Since I use capistrano for project deployment I set it up to have three separate tasks: “production”, “production_staging” and “development_staging”. The “production” and “production_staging” tasks use the master branch and the “development_staging” task uses the newly created remote branch. For both the remote branches you must follow the above work-flow i.e: never work directly in the branches themselves, instead create local branches to work in.

a. Create a new remote branch.

First create a new remote branch from our master branch:

git push origin master:refs/heads/development_phase_1

b. Track the remote branch.

Track the newly created remote branch:

git checkout --track -b development_phase_1 origin/development_phase_1

This will create a new local branch named “development_phase_1″ that is tracking the remote “development_phase_1″ branch. Everyone who needs to work on development branch tracks this remote “development_phase_1″ branch and pushes to it. The only pushes to master branch are production fixes.

c. Merge the development branch with the master branch.

Once work on development branch is finished we are ready to merge the two branches:

git checkout development_phase_1
git rebase master
git checkout master
git merge development_phase_1
git push
git branch -d development_phase_1
git push origin :heads/development_phase_1

Normally a rebase is not a good idea in a remotely tracked branch but since our phase is finished and we will create a new remote branch for the next phase, I do so here. Alternatively, I could do a force push for the remote development branch and everyone working on it would need to remove and retrack it again. The second last line removes our locally tracked development branch and the last one removes it from the remote repository.

Final Thoughts

As I mentioned before, the above presented work-flow is not perfect by any means but it works for me. I would appreciate feedback from anyone who reads this and has some suggestions/recommendations to help me manage my projects better.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

We live in a quick-fix society so it’s no wonder that many startups especially in technology look for the magic cure to increase their sales or get funding for their projects.  These projects follow funding driven development methodology. And here are few symptoms of  FDD :

• Most of these products start looking for investors  even when the core benefit web app is not properly conceptualized.
• The product manager spends more time with PR,investors and newspapers than with developers.
• The milestones for the project are strictly based on the next press release, media  interview or conference.
• Instead of driving real people and customers to sales pipeline, you meet people who are not your target audience.
• They always think of  raising capital and use major part of that in increasing/improving your sales force.
• They lack patience and you dont want to wait for few quarters to reach the right feature set after product launch based on feedback.
• They are least bothered about the backend and focus on UI. As long as the site looks cool , you are okay with that irrespective of the quality of  code running in the backend.
• Instead of a single marketing launch, They have a series of launch with some new stupid feature everytime which nobody needs in every launch.
• When investors see PR stuff of your project, they expect  significant momentum which usually is not there.PR is not writing code. You can not try it, iterate, learn, and try again.
• The founders feel great when they are covered by leading media instead of significant release that improves their product.
• They don’t understand the value of an early release, release often.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

For example, lets assume that we need to add a column ‘role’ in users table(User model). In this case generate a migration like:

Output:

Here AddRoleToUser plays the main role. ‘Add’ specifies the we want to add column(s) and ‘User’ separated by ‘To’ specifies the table.

Similarly, if we need to remove a column ‘role’ :

Output:

Here RemoveRoleFromUser plays the main role. ‘Remove’ specifies the we want to remove column(s) and ‘User’ separated by ‘From’ specifies the table.

Isn’t it cool?

And then I started writing my own ruby script for same purpose but with some addition and modification. Commit notification script is that script, you can download and configure it with your SVN post commit hook as follows.

Add following line at the bottom of your post-commit file:

* Please remember to change the path of you commit-email ruby script.

Now open commit-email ruby file and modify the following section according to your requirement:

You are done with that, now onwards whenever someone commits the code, you’ll get the commit notification mail like:

Now try following at console:

This will let you create three records in users table with same name, validates_uniqueness_of written in User class has no effect on it. validates_uniqueness_of automatically scoped with class names, that means it will not let you create two managers with same name or two customers with same name or two users with same name.

If you want uniqueness of an attribute in overall table, put the following code in some file in your lib dir and require that file in environment:

And then use validates_overall_uniqueness_of instead of validates_uniqueness_of.

You can also deploy your rails application with pound(a reverse proxy, load balancer and HTTPS front-end for Web server).

First you need to setup mongrel_clusters for your rails application by issuing ” mongrel_rails cluster::configure -e production -p 8000 -a 127.0.0.1 -N 3 -c ./ ” inside the rails application root directory(on client machine). This will create mongrel_cluster.yml in config directory. You can change parameters in this command, as -p 8000 specifies that mongrel instances will start up on port number starting 8000, -a 127.0.0.1 specifies that mongrel instances will listen to the localhost, -N specifies the number of mongrel instances and -c specifies the rails root directory.

Now you need to install pound(if not installed) by issuing following commands(as root):

• cd /opt/src
• wget http://www.apsis.ch/pound/Pound-2.3.2.tgz
• tar xzpf Pound-2.1.6.tgz
• cd Pound-2.1.6
• ./configure
• make
• make install

This will install pound in /usr/local/sbin/pound. In order to proceed further we need to create pound.cfg(pound configuration file) in /etc/pound/pound.cfg . Below is the content of pound.cfg:

Start mongrel cluster by issuing mongrel_rails cluster::start in you app root directory, start pound by /usr/local/sbin/pound -f /etc/pound/pound.cfg , now you are done. Pound is listening the port 80 and redirect all requests to mongrel instances running on 8000, 8001, 8002.

* Please Note that we have configured pound at port 80, if port 80 is being used by apache or any other application pound will not start. You need to stop any service using port 80, if it is apache then stop apache, change line ‘Listen 80′ to “Listen 8080″ and start apache.

In a specific case, when apache is running at some port (let say 8080), you may want to use apache to serve static content of your application, in order to reduce some load from mongrels. In that case use the following:

This will redirect all requests for image, stylesheets, javascripts, flash to apache. Now we need to configure apache to serve those static content. Just add a virtualhost for that:

Its all done. All requests for dynamic content at port 80 will be redirect to mongrel running at 8000, 8001, 8001 and requests for static content will be served by apache running at port 8080.

1. rake db:test:purge
2. rake db:migrate
3. rake test

This default was not working with my last project As I was using RSpec for my project. I found that we can overwrite default way of building by creating a rake task named cruise in our project. Means by building CruiseControl will run your custom rake task only, so you have to take care of all other things i.e. migrate etc.

Hence I created following rake task in RAILS_ROOT/lib/tasks/custom_cc.rake

and it worked for my rails project using RSpec.

Please visit this site to know more about this javascript library.

You need Apache 2.2 or later on your production server, and the following ruby gems on your both machine(server and local):

• capistrano
• mongrel
• mongrel_cluster

I haven’t mentioned rails and rake gem as we are deploying a rails application so these gems are obvious.

Lets install above gems (if not installed) by issuing:

Now make sure that the following modules are enabled (they are disabled by default) :

• mod-rewrite
• mod-proxy
• mod-proxy-http
• mod-proxy-balancer

to check if they are enabled issue ” /etc/init.d/apachectl -M ” on server, it will list all the enabled modules. For Debian systems all enabled modules are in /etc/apache2/mods-enabled directory and all available modules are in /etc/apache2/mods-available directory, to enable them issue ” a2enmod MOD_NAME “.

Now create the production database(on server) and update database.yml for production database settings.

After this configure mongrel by issuing ” mongrel_rails cluster::configure -e production -p 8000 -a 127.0.0.1 -N 2 -c ./ ” inside the rails application root directory(on client machine). This will create mongrel_cluster.yml in config directory. You can change parameters in this command, as -p 8000 specifies that mongrel instances will start up on port number starting 8000, -a 127.0.0.1 specifies that mongrel instances will listen to the localhost, -N specifies the number of mongrel instances and -c specifies the rails root directory.

Now its time to capistranize rails application, issue ” cap –apply-to ./ APP_NAME ” inside rails application root directory(on client machine), this will add two files(config/deploy.rb and lib/tasks/capistrano.rake) to the rails application. Edit deploy.rb according to your requirements. Also add the following code to deploy.rb :

Now on your local machine issue these two commands in only once ” rake remote:setup ” and ” rake remote:cold_deploy “, when you issue ” rake remote:setup ” it will prompt for the server password and create necessary directories on the server and ” rake remote:cold_deploy ” will deploy your code to the server. Next time whenever you want to deploy to the server you just need to issue ” rake remote:deploy ” not ” rake remote:cold_deploy “.

Now we are just one step back, we need to configure apache proxy balancer for mongrel instances. Add the following code to the httpd.conf file:

you need to change the above code according to you requirement. Also you need to restart apache server by issuing ” /etc/init.d/apachectl restart “. Now you are done.

But we also need to add a script to start mongrel instances when the server restarts, otherwise whenever the server restart there will no mongrel instance running.

Just create a file named mongrel_clusters (you can choose any name) in /etc/init.d directory with the following code:

You need to change the BASEDIR in the above code. Make this file executable by ” chmod +x /etc/init.d/mongrel_clusters ”
Issue these commands to add this script at system startup:

Debian: /usr/sbin/update-rc.d /etc/init.d/mongrel_clusters defaults
RedHat: /usr/sbin/chkconfig –add /etc/init.d/mongrel_clusters and /usr/sbin/chkconfig –level 2 /etc/init.d/mongrel_clusters on

Note: Use above instructions at your own risk, if your computer explodes its not my fault :-)