Posted September 1, 2012 by Spyros in Ruby on Rails

Your First Rails 3 Application : How to Create, Organize and Proceed


I decided to create a tutorial for Rails newcomers, that will hopefully help you with making your first steps with a new Rails 3 project. It may seem a bit intimidating at first, but it really is not that hard. Notice that i will describe what is my personal way of doing things. Other Rails developers may prefer to go about doing different things, but hopefully this will at least help you get a good grasp on what you should be looking for when designing your application.

Create a Fresh Application

As you probably already know, the command for creating a new rails project, say one with the name ‘test_project’, is :

rails new test_project -d mysql

Once the generator creates all the files and the bundler runs, you should just change to the newly created test_project directory where the actual app resides. Your new project has just been created. Notice that i prefer to use mysql, even locally, but you may want to omit the -d switch and stay with the default mysqlite.

Start Server

To start WEBrick, the local web server that comes with Ruby on Rails and is mainly used for development purposes, you just enter you new app directory and execute :

rails s

Notice that ‘rails s’ is sort for ‘rails server’. Both do the same thing. You can access your local web server through your browser at http://localhost:3000/. Upon doing that, you will see the standard new Rails project page. The first thing to do is remove the public/index.html file, which just serves as an introduction to your project, that you no longer need. So, you did that and you now get an error :

No route matches [GET] "/"

I will not go into great detail about rails routing here, but will definitely write a dedicated post about it soon. This error simply states that the server was not able to serve a GET request for the / path, that is, the root path of your application. Now, our first step would be to create a new controller and then a route that points to the index action of that controller. But before doing that, take a deep breath and let’s talk a bit about scaffolding.

Rails Scaffolding – Making Things Simpler, the Hard Way

Before talking about scaffolding, let me tell you how my scaffolding perception evolved while learning Rails and gaining more and more experience and knowledge on the subject :

1) Oh, it seems lovely, it creates so much code automatically. It works great, i can make a blog in 15 minutes, whoohoo.

2) Hmm, all right,i don’t understand anything. What is this respond ? And why xml ? And all these flashes here ? Wow, pretty intimidating.

3) This scaffolding idea seems nice, but too overbloated, i will be generating my controllers myself.

4) Ohh, i am not doing it the RESTful way. Damn, i think i will switch back to scaffolding.

5) Still overbloated, i will write my own generators. Heck, i don’t need responders.

6) Then again, nifty_scaffold  does exactly what i want. I will be using that then !

This was my story. Does anybody relate ? :) You may want to go through that steps as well, but in case you do not really want to waste too much time, I would HIGHLY recommend that you use the nifty generators gem. It simply allows you to create nice scaffolds(along other things, like layouts), without inserting probably irrelevant responders like json and so on. To add this gem, just open your Gemfile, located under the root project directory, and write :

group :development do
  gem 'nifty-generators'

Now open up your console, again in your main project directory and let’s go about creating a Home controller. Notice that the home controller is not really a REST resource, but just a static controller that is normally used to create the first page that a user views when viewing your website. Based on the needs of your application, you could directly be having a users controller or something else, but i normally like to create a home controller first, which just has the index action. So, let’s go about creating our first home controller with :

 rails g controller home index

Notice that ‘rails g’ stands for ‘rails generate’. Now that our new controller is created and we do have an action, we can inform our routes that we want our home route to point to our new home controller and specifically to the index action. To do that, we open up the ‘config/routes.rb’ file and the first thing to notice is the line :

get "home/index"

This was automatically created by the generator controller command that we just run. It informs the routing system that the /home/index url is served by the home controller in its index action(the controller name and action is derived from the url names, a typical rails convention). The next thing to do is create our root route. To do that, right above this line, we write :

 root :to => 'home#index'

Great. We now open up our localhost:3000 root url again, and we get this :


Find me in app/views/home/index.html.erb

Which means that things are going pretty well. Now the controller action index is found and executed, but it points to a Rails generator file. It’s pretty explanatory though, we just find this file and write our contents in it, refresh the browser and we actually see the new content.

Create Our First Nifty Scaffold

Let’s now go about creating our first real scaffold. We normally need to create a scaffold when we have a need for both a model and a controller. In the home controller case, we did not have that need. It was just created to display a static webpage. However, imagine that we now need a way to create, edit or destroy users, a very common need in web applications. In this case, we would need a scaffold generator. Let’s go ahead and create a new one with :

rails g nifty:scaffold user name:string email:string

You will notice that a model with the name User and the attributes name and email was created. Moreover, a users_controller was created and the generator also created test files, helper files and so on. I don’t want to make this post longer, so i will finish with a last thing that i think is pretty important. Since everybody tends to have their own personal generator preferences, it would be nice if we would be able to define default behavior, like using Rspec instead of test/unit. We can actually do that by editing the file ‘config/application.rb’, inside the config block :

<pre>		config.generators do |g|
		  g.stylesheets false
		  g.test_framework :rspec
		  g.fixture_replacement :factory_girl
		  g.assets false
		  g.view_specs false
		  g.helper_specs false
		  g.routing_specs false
		  g.helper false

I think it is pretty self explanatory. I personally prefer not to generate stylesheets, assets or helpers automatically. As i will describe in more detail in the posts to come, it is a better practice to use more explicit helper/style file names, instead of the ones the generator makes for you. For instance, if you have a user_membership controller and model, you may not really need a user_membership_helper, but you may need an avatar_helper. It is always a better idea to be more concise and refrain from using the default helper.

Hope that gives you some first insight on how to go about creating your first Rails projects. There will be more advanced matters to come soon, like nested resources and so on. Please stay tuned :)