Ruby on rails…what does this even mean? When I first started learning Ruby, I heard rumblings of a mysterious entity known as “rails”. With statements like “rails is magical”, “just wait until rails”, and “you won’t even need this anymore when you are using rails” being thrown around haphazardly, I couldn’t help but wonder what the big deal was. After all, isn’t rails just a framework? It’s not like rails actually writes code for you, does it? The answer to that is a bit of a yes and no.

As a fan of motorsports(Formula 1 in particular) when I hear the term that something is on rails, my mind immediately goes to the meaning of the phrase in regards to a race car. The ubiquitous saying that a car is on rails basically means that the car drives itself. The concept is that similar to a rollercoaster or train, the car sticks to the track and never deviates from the intended path. Requiring minimal effort, the driver is almost like a passenger. As hyperbolic as a car on rails statement is, I feel like it can be analogous to Ruby on rails. Do either actually drive themselves? No, of course not, you still need to use precision and skill to arrive at your desired destination. Are a racecar on rails and Ruby on rails the best way to get to said destination? In my personal opinion…absolutely! Like most everything else, using the best tool available merely magnifies the outcome that a skilled craftsman is able to produce.

Before I ever even knew what a terminal was I had visions of grandeur in regards to coding. I romanticized having the ability to create with the only limitation being my ability to come up with ideas…fast forward to the present and all of that is still true. Naturally I was excited to create something using the newly introduced Ruby on rails framework. The only downfall, with so many options it was hard to decide what I wanted to create. I decided to start with something a bit simple but with a lot of room for expansion and freedom to be a bit adventurous stylistically. With a few friends in the industry, I determined that I would make a simple appointment application for a fictitious salon.

Planning: The first step that I would recommend to anyone starting out on a project using rails is to develop a thorough plan with the end goal in sight.

The drawing above illustrates the general concept behind my salon application. I have three models that need attributes and associations. Since the appointment model belongs to the user and employee, it will take on both of their id’s.

Starting with Rails: Once we have our local environment setup properly, starting a project with rails is a breeze. All it takes to setup the entire rails framework is a simple terminal command. Assuming that we wanted to create a new project named “salon” the terminal command is simply

rails new salon

Making a Model: Now that we have a basic idea of what we are going to make we can create our models. A cool feature of using rails is that we now have access to rails generators. We know that we need our models and we know that those will need migrations but we can take it a step further and create our model, migration table, and add routes to our project all from a single command line prompt. All it would take to do this for our appointments class is a the line.

rails g resource appointment name:string appointment_date:datetime user_id:integer employee_id:integer

So what exactly did the “resource” in the line above do that differentiates it from a model or migration generation? Simply put, we have added a line to a file ‘cofig/routes.rb’ that we part of creating our project with rails new.

The line that we added is ‘resources :appointment’ and gives us restful routes for full C.R.U.D.

Rails routing: Routing in rails is a bit different than routes in Sinatra. If we wanted to go to an index for our appointments page in Sinatra our Appointment controller would have something like:

get '/appointments' do
@appointment = Appoitment.all
erb :'appointments/index'
end

the same command in the Appointment controller in our rails project would be:

def index
@appointment = Appointment.all
end

With our resources for appointments declared in the ‘config/routes.rb’ file we get some pretty cool routing setups but the most interesting to me is the paths setup.

When we run our app in the browser with the ‘rails s’ command we get to our default landing page at http://localhost:3000. Rails also gives us ‘http://localhost:3000/rails/info/routes’ which is a page that shows us all the available routes that we have already established. A prime example of that is my use of the home page or root path. Since we have our routes listed out for us, it is easy to complete the process by adding adding something like ‘def index’, ‘def new’, ‘def edit’, and the rest of our restful routes.

The home page for my app exists in the views directory under a sub folder named “static” on file “home.html.erb”

“root to: “static#home” establishes that the route now exists

Vibrant Views: With our routes taking shape, it is a great time to start working on our HTML. The ‘V’ in our “MVC(Models, Controller, Views” application is the aspect of the app that our users interface. This is where you can really get creative and display things in a way that really put the overall idea of you application into perspective. Since I decided that I wanted to go with a clean layout without much color there wasn’t really a ton going on with most of my views pages. Under the surface though I used partials for the form page.

The code above is the form for making an appointment at the fictitious salon. Since it exists in a the file “_form.html.erb” we need to call it on the “appointments/new” and “appointments/edit” pages . The process to do that is a simple line on our “new.html.erb” and “edit.html.erb” pages

line to render partial in ‘new.html.erb’

Since everything in our form aside from the buttons on both pages is the same, we just call the form in and assign the local button names to their respective pages

line to render partial in ‘edit.html.erb’

Controlling it all: The final piece to making all of this work together is to setup our controller. The controller is the important part that ties the Models and Views all together. Since we used ‘resources’ to generate the models for our app, we have all the restful routes setup for us. All we have to do to finish the path is write the method for the model in it’s respective controller. If we want to have a show page for our appointments all we have to to in our appointments controller is write the method “show”.

The simple code above is all that it takes to do get your show page route functional.

Overall, there is are a lot of ways that someone can use Ruby to create a web application. Rails is a great resource to use and can really simplify the process but ultimately, rails is just ruby. You use your ruby knowledge to to help rails steer you to your destination.