Ruby on Rails Tutorial: A Toy App
- 2.1 Planning the Application
- 2.2 The Users Resource
- 2.3 The Microposts Resource
- 2.4 Conclusion
- 2.5 Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this chapter, we’ll 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 1.2, the rest of the book will take the opposite approach, developing a full sample application incrementally and explaining each new concept as it arises. For a quick overview (and some instant gratification), though, there is no substitute for scaffolding. The resulting toy app will allow 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: The full example 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.3, we’ll start by generating the application skeleton using the rails new command with a specific Rails version number:
$ cd ~/workspace
$ rails _4.2.0_ new toy_app
$ cd toy_app/
If the command above returns an error like “Could not find ‘railties’,” it means you don’t have the right version of Rails installed, and you should double-check that you followed the command in Listing 1.1 exactly as written. (If you’re using the cloud IDE as recommended in Section 1.2.1, note that this second app can be created in the same workspace as the first. It is not necessary to create a new workspace. 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.
Listing 2.1 A Gemfile for the toy app.
____________________________________________________________________________ source 'https://rubygems.org' gem 'rails', '4.2.0' gem 'sass-rails', '5.0.1' gem 'uglifier', '2.5.3' gem 'coffee-rails', '4.1.0' gem 'jquery-rails', '4.0.3' gem 'turbolinks', '2.3.0' gem 'jbuilder', '2.2.3' gem 'sdoc', '0.4.0', group: :doc group :development, :test do gem 'sqlite3', '1.3.9' gem 'byebug', '3.4.0' gem 'web-console', '2.0.0.beta3' gem 'spring', '1.1.3' end group :production do gem 'pg', '0.17.1' gem 'rails_12factor', '0.0.2' end ____________________________________________________________________________
Note that Listing 2.1 is identical to Listing 1.14.
As in Section 1.5.1, we’ll install the local gems while suppressing the installation of production gems using the --without production option:
$ bundle install --without production
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 by clicking the “Create” button at Bitbucket (Figure 2.1), and then push up to the remote repository:
$ git remote add origin git@bitbucket.org:<username>/toy_app.git $ git push -u origin --all # pushes up the repo and its refs for the first time
)
Figure 2.1 Creating the toy app repository at Bitbucket.
Finally, it’s never too early to deploy, which I suggest doing by following the same “hello, world!” steps provided in Listing 1.8 and Listing 1.9.1 Then commit the changes and push up to Heroku:
$ git commit -am "Add hello" $ heroku create $ git push heroku master
(As in Section 1.5, you may see some warning messages, which you should ignore for now. We’ll eliminate them in Section 7.5.) Apart from the address of the Heroku app, the result should be the same as in Figure 1.18.
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. In our case, the toy app will be a microblog, with only users and short (micro)posts. Thus, we’ll begin with a model for users of the app (Section 2.1.1), and then we’ll add a model for microposts (Section 2.1.2).
2.1.1 A Toy Model for Users
There are as many choices for a user data model as there are different registration forms on the web; we’ll go with a distinctly minimalist approach. Users of our toy app will have a unique integer identifier called id, a publicly viewable name (of type string), and an email address (also a string) that will double as a username. 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
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 11) how this user_id attribute allows us to succinctly express the notion that a user potentially has many associated microposts.