The one thing that is different about this article from others around the web is that I wanted to do simple and easy stuff. I did not want to have a model or to put pictures in a database and so on I just wanted to store a resized image to the file system. Why the filesystem and not database? Database is like a funnel. You put and put and use and it isn’t something that you can easily extend or expand to fit easily your needs. There are extends and so on… and you can always hack around problems but why running into them in the first place? So my way was simple and easy without putting much effort in things that I don’t actually need.

Read the rest of this entry »

This article is part two of the series about Rails Migrations and it will explain on a deeper level how to use the Ruby on Rails migrations.

After we spoke about Migrations in our previous article found here we understood the basics needed to use Migrations in Ruby on Rails.

Now to begin with the code and something we did not mention earlier.

You see indexes are something that a good database design MUST contain!
This example shows how to add and remove an indexed field.

And now let’s take a look at some examples which might or might not be so obvious to make.

Read the rest of this entry »

This article is part one of the series about Rails Migrations and it will explain on a basic level how to use the Ruby on Rails migrations.

1. What are Migrations ?

Migrations in Rails is a way of describing what the database should look like and synchronize it with the respective model.
Migrations are abstract to the database they are used with. This means that if you have used a MySQL database server when developing the application and the production database server is different let’s say Postgresql the database you defined within the migrations will remain intact and will run just fine on the new database server.
Migrations provide a way to make the database development SVN like… I will cover this latter on so just keep in mind this for now.

2. Creating and Running Migrations

A migration is a simple Ruby file in the db/migrate directory.
Each migration file has a name starting with three digits and an
underscore. Those digits are the representation of the migrations version (a bit like SVN),
because they define the sequence in which the migrations are applied.

To generate a migration type:

Notice: This will generate a model and a migration to it.

Read the rest of this entry »

Setting up a Ruby on Rails Application in a production environment could be a bit tricky. This is because the standard servers for running ruby could serve only one request at a time. As a result if there’s a slow database connection or any other process away from the application server no other requests could be served. On contrast Apache httpd spawns a new child if there’s a necessity to process a new request. In this article I’ll guide you how to solve this problem. Generally there will be an apache httpd server which will be used as a gateway to a cluster of mongrel_rails processes. So, all users will be accessing the apache as a frontend, however the whole processing burden will be let down to the mongrel servers. Here it is an example:

First to mention, I’m making this setup on Fedora Core 6. However it should be almost the same on older versions or other distributions. Note: Your apache should support mod_proxy_balancer (it is distributed with apache 2.2.x). So, the basic software requirements are:

• Ruby - You won’t go without a ruby interpreter (preferably version 1.8.5). On a Fedora 2 I did a source “compile and install” without any complications
• ruby-devel package - In case that you’ve installed ruby as a package you should install ruby-devel in order to compile a few mongrel related gems
• gem - The tool to install most of the extensions which are related to ruby. If you want to install from sources (it’s pretty easy: ruby setup.rb) you can download it from here: gem sources

Read the rest of this entry »