The Power of Rails Development
- 2.1 Planning the Application
- 2.2 The Users Resource
- 2.3 The Microposts Resource
- 2.4 Conclusion
Get a high-level overview of Ruby on Rails programming, and web development in general, by working through these steps to building a toy demo application.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this chapter, we develop a toy demo application to show off some of the power of Rails. The purpose is to get a high-level overview of Ruby on Rails programming (and web development in general) by rapidly generating an application using scaffold generators, which create a large amount of functionality automatically. As discussed in Box 2.1, the rest of the book will take the opposite approach, developing a full sample application incrementally and explaining each new concept as it arises, but for a quick overview (and some instant gratification) there is no substitute for scaffolding. The resulting toy app will enable us to interact with it through its URLs, giving us insight into the structure of a Rails application, including a first example of the REST architecture favored by Rails.
As with the forthcoming sample application, the toy app will consist of users and their associated microposts (thus constituting a minimalist Twitter-style app). The functionality will be utterly under-developed, and many of the steps will seem like magic, but worry not: We will develop a similar application from the ground up starting in Chapter 3, and I will provide plentiful forward-references to later material. In the meantime, have patience and a little faith—the whole point of this tutorial is to take you beyond this superficial, scaffold-driven approach to achieve a deeper understanding of Rails.
2.1 Planning the Application
In this section, we’ll outline our plans for the toy application. As in Section 1.2, we’ll start by generating the application skeleton using the rails new command with a specific Rails version number:
$ cd ~/environment $ rails _6.0.2.1_ new toy_app $ cd toy_app/
If you’re using the cloud IDE as recommended in Section 1.1.1, note that this second app can be created in the same environment as the first. It is not necessary to create a new environment. To get the files to appear, you may need to click the gear icon in the file navigator area and select “Refresh File Tree.”
Next, we’ll use a text editor to update the Gemfile needed by Bundler with the contents of Listing 2.1.
Important note: For all the Gemfiles in this book, you should use the version numbers listed at gemfiles-6th-ed.railstutorial.org instead of the ones listed below (although they should be identical if you are reading this online).
Listing 2.1: A Gemfile for the toy app.
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem 'rails', '6.0.2.1'
gem 'puma', '3.12.2'
gem 'sass-rails', '5.1.0'
gem 'webpacker', '4.0.7'
gem 'turbolinks', '5.2.0'
gem 'jbuilder', '2.9.1'
gem 'bootsnap', '1.4.5', require: false
group :development, :test do
gem 'sqlite3', '1.4.1'
gem 'byebug', '11.0.1', platforms: [:mri, :mingw, :x64_mingw]
end
group :development do
gem 'web-console', '4.0.1'
gem 'listen', '3.1.5'
gem 'spring', '2.1.0'
gem 'spring-watcher-listen', '2.0.1'
end
group :test do
gem 'capybara', '3.28.0'
gem 'selenium-webdriver', '3.142.4'
gem 'webdrivers', '4.1.2'
end
group :production do
gem 'pg', '1.1.4'
end
# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]
Note that Listing 2.1 is identical to Listing 1.18.
As in Section 1.4.1, we’ll install the local gems while preventing the installation of production gems using the --without production option:
$ bundle install --without production
As noted in Section 1.2.1, you may need to run bundle update as well (Box 1.2).
Finally, we’ll put the toy app under version control with Git:
$ git init $ git add -A $ git commit -m "Initialize repository"
You should also create a new repository at GitHub by following the same steps as in Section 1.3.3 (taking care to make it private as in Figure 2.1), and then push up to the remote repository:
)
Figure 2.1: Creating the toy app repository at GitHub.
$ git remote add origin https://github.com/<username>/toy_app.git $ git push -u origin master
Finally, it’s never too early to deploy, which I suggest doing by following the same “hello, world!” steps from Section 1.2.4, as shown in Listing 2.2 and Listing 2.3.
Listing 2.2: Adding a hello action to the Application controller.
app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
def hello
render html: "hello, world!"
end
end
Listing 2.3: Setting the root route.
config/routes.rb
Rails.application.routes.draw do root 'application#hello' end
Then commit the changes and push up to Heroku, and, at the same time, GitHub—it’s a good idea to keep the two copies in sync:
$ git commit -am "Add hello" $ heroku create $ git push && git push heroku master
Here we’ve used the double ampersand operator && (read “and”) to combine the pushes to GitHub and Heroku; the second command will execute only if the first one succeeds.1
As in Section 1.4, you may see some warning messages, which you should ignore for now. We’ll deal with them in Section 7.5. Apart from the URL of the Heroku app, the result should be the same as in Figure 1.31.
2.1.1 A Toy Model for Users
Now we’re ready to start making the app itself. The typical first step when making a web application is to create a data model, which is a representation of the structures needed by our application, including the relationships between them. In our case, the toy app will be a Twitter-style microblog, with only users and short (micro)posts. Thus, we’ll begin with a model for users of the app in this section, and then we’ll add a model for microposts (Section 2.1.2).
There are as many choices for a user data model as there are different registration forms on the web; for simplicity, we’ll go with a distinctly minimalist approach. Users of our toy app will have a unique identifier called id (of type integer), a publicly viewable name (of type string), and an email address (also of type string) that will double as a unique username. (Note that there is no password attribute at this point, which is part of what makes this app a “toy.” We’ll cover passwords starting in Chapter 6.) A summary of the data model for users appears in Figure 2.2.
){kind=link}
Figure 2.2: The data model for users.
As we’ll see starting in Section 6.1.1, the label users in Figure 2.2 corresponds to a table in a database, and the id, name, and email attributes are columns in that table.
2.1.2 A Toy Model for Microposts
Recall from the introduction that a micropost is simply a short post, essentially a generic term for the brand-specific “tweet” (with the prefix “micro” motivated by Twitter’s original description as a “micro-blog”). The core of the micropost data model is even simpler than the one for users: A micropost has only an id and a content field for the micropost’s text (of type text).2 There’s an additional complication, though: We want to associate each micropost with a particular user. We’ll accomplish this by recording the user_id of the owner of the post. The results are shown in Figure 2.3.
){kind=link}
Figure 2.3: The data model for microposts.
We’ll see in Section 2.3.3 (and more fully in Chapter 13) how this user_id attribute allows us to succinctly express the notion that a user potentially has many associated microposts.