Ruby for Programmers – Part 11: Railtying It Together

Having all this on one script is okay for now, but it’s best to start splitting up files just to make it easier to follow. So let’s create some folder conventions for us:

  • app/controllers will contain our controllers as determined by our routes
  • config/routes.rb will contain the routes drawer
  • config/boot.rb will contain the boot script
  • config/application.rb will contain information specific to our application, and hold information between files.
  • config/environment.rb will have the initializers after our application.
  • public/ will contain public files like CSS or error files

So first in boot.rb we’ll put the require ‘bundler/setup’. Since it’s in another folder, we’re going to need to tell that the file is in another castle:

ENV is a sweet built-in Ruby variable that contains the shell environment variables. This is useful if you want to store different configurations for different setups. Instead of different that may or may not be uploaded, it’s far better to store this information in an environment variable. You can setup this on the server so as to hide passwords or API keys too.

Below that is a really short version of the Rails application initializer. So we created a Rails module (for now think of modules as function containers), and made it so that Rails.application is accessible from anywhere. We then created a class named Application and used a Ruby auto-function named “inherited” where if a new class is made, it will run that function. In this case it sets Rails.application to a new instance of the child class. (If you’re confused, don’t worry, this is all automagicked away soon).

We also create the routes and the routes file:

Which is just a copy/paste of our original routes. Note that it uses our Rails.application that was created, which means we need to create the child class to be inherited and instanced:

Pretty boring here except this is where we create the class to be inherited. It also requires the boot file and mainpage_controller.rb file here too. mainpage_controller.rb itself is just a copy/paste:

Exactly like the old one.

For now, our environment.rb will just include the application and the routes file:

And will just include the environment.rb and run the routes:

This boots and shows the same stuff as before with our routes.

You can view the working example here:

Now before I go, there’s a reason why all this moving around, it’s just to show how Rails ties things together. In fact, the gem that holds all this together is “railties”. So let’s add it to our Gemfile, and update our scripts to use it:

And run bundle install. Now we only need to make a few small changes to a few files. boot.rb will get it’s Rails stuff removed since it’s now handled in the railties gem:

environment.rb now tells Rails to initialize (which will auto-load important files like routes.rb):

And will run Rails.application instead of the routes, since Rails will handle some automagic for us:

Since railties will automatically load the controller files for us, we just need to make a couple small modifications to our application.rb file:

We tell it to look for Rails and ActionController (which is next lesson, but railties/routing was whiny without it). Also, we started on the config because Rails complained without it.

And it works. bundle exec rackup will boot your app and it will still work like before, but now running on Rails. Once you load, you’ll notice it whining about eager_loading, so lets add an environment file config/environments/development.rb:

You can ignore the actual settings until we need to go for them. However, this file is important because it defines some of the eager loading that makes Rails great. We’ll also add the default Rakefile too, while we’re at it.

Now you can run the app a different way bundle exec rails server. This boots the server a different way, but has all trimmings. rackup still works, but the rails server has better logging and debug files.

So this lesson just really moved things around, which is nice. But the controllers are still using the weird array output and a bad way to create HTML. So next lesson, let’s add some ActionControllers with some ActionViews.

The final code for this part is here: