2.2.1 What’s in Book One

Book One is a self-help book that can change your life, though here you won’t find any inspirational quotes or magical thinking.

I explain the culture and practices of the Rails community. I introduce the basic concepts you’ll need to understand web application development. You’ll learn how to be a successful learner and how to get help when you need it. I also provide a plan for study so you can learn more when you need it. There’s so much to learn, it helps to have a map so you know where to go next.

Programming can be frustrating and Rails isn’t easy for beginners. The chapter, “Rails Challenges,” describes many of the problems learners encounter. It’s natural to get discouraged so take a look when you begin to feel overwhelmed.

Two chapters, “Crossing the Chasm”, and “Level Up”, will help you after you put the book down. Many learners feel stranded if their only experience is step-by-step tutorials. These chapters are designed to give you a strategy for building an application on your own.

2.2.2 What’s in Book Two

You’ll start coding in Book Two. It’s a hands-on tutorial that will lead you through the code needed to build a real-world web application. Don’t skip around in Book Two. The tutorial is designed to unfold in steps, one section leading to another, until you reach the “Testing” chapter.

You can complete Book Two in one long weekend, though it will take concentration and stamina. If you work through the book over a longer timespan, try to set aside uninterrupted blocks of two hours or more for reading and coding, as it takes time to focus and concentrate.

Feel free to start Book Two before you finish this book. Begin coding with Book Two while you get background knowledge from this book at your leisure.

Visit tutorials.railsapps.org to learn how to get Book Two.

2.2.3 A Warning About Links

My books are densely packed with links to background reading. If you click every link, you’ll be a well-informed student, but you may never finish the book! It’s up to you to master your curiosity. Follow the links only when you want to dive deeper.

2.2.4 What Comes Next

The best way to learn is by doing; when it comes to code, that means building applications. Hands-on learning with actual Rails applications is the key to absorbing and retaining knowledge.

After you read this book, you’ll be able to work with the example applications from the RailsApps Project. The project provides open source example applications for Rails developers, for free. Each application is accompanied by a tutorial in the Capstone Rails Tutorials series, so there’s no mystery code. Each application can be generated in a few minutes with the Rails Composer tool, which professional developers use to create starter applications.

The RailsApps Project is solely supported by sales of the books, videos, and advanced tutorials. If you make a purchase, you’ll keep the project going. And you’ll have my sincere appreciation for your support.

2.2.5 Versions

Book One is relevant and useful for any version of Rails. Book Two requires a specific version of Rails (the newest at the time it was revised) and shows how to install the latest version of Rails.

2.2.6 Staying In Touch

If you obtained this book from Amazon or another retailer, take a moment to get on the mailing list for the book. I’ll let you know when I release updates to the book.

• Get on the mailing list for the book

2.2.7 A Note to Reviewers and Teachers

This book approaches the subject differently than most introductions to Rails. It introduces concepts of product planning, project management, and website analytics to place development within a larger context of product development and marketing. In Book Two, rather than show the student how to use scaffolding, I introduce the model-view-controller design pattern by creating the components manually. Lastly, though every other Rails tutorial shows how to use a database, Book Two doesn’t, because I want the book to be a short introduction and I believe the basic principles of a web application stand out more clearly without adding a database to the application. Though this tutorial is not a typical Rails introduction, I hope you’ll agree that it does a good job in preparing Rails beginners for continued study, whether it is a course or more advanced books.

2.2.8 Using the Book in the Classroom

If you’ve organized a workshop, course, or code camp, and would like to assign the book as recommended reading, contact me at daniel@danielkehoe.com to arrange access to the book for your students. The book is available at no charge to students enrolled in qualified workshops or classes.

2.2.9 Let’s Get Started

In the next chapter, we’ll start with basic concepts.

3.4.1 JQuery

In 2006, a group of developers released jQuery, a robust collection of scripts that are a foundation for most of the simple interactive user features found on websites today. Rails includes jQuery as part of any Rails application. You’ll find jQuery on 65% of websites.

To understand jQuery, you need to know that every web browser takes an intermediate step between receiving an HTML file and displaying a web page. After a web browser receives a file from a web server, it creates code in the computer’s memory that describes the web page, complete with text and formatting, which we call the Document Object Model, or DOM. JQuery scripts manipulate the DOM, which is the web browser’s internal representation of web page. JQuery commands make changes to the DOM. For example, you can write Javascript that replaces words on the page with different words. Or you can hide and reveal sections of the page.

Many Rails applications use jQuery or pure JavaScript to add interactive browser features. Though it is easy to add JavaScript to web pages generated by Rails, the result is often “JavaScript gravy” or “soup:” a sloppy mix of JavaScript snippets and jQuery plugins poured over Rails views. After seeing applications built with JavaScript soup, developers often get an urge to adopt a framework like Rails for JavaScript, with standard structures and conventions to organize code.

We’ll look at JavaScript frameworks later in this chapter. But first, consider a universe where JavaScript is the only language you need to know. Not all developers use Rails; some use full-stack JavaScript.

3.4.2 Full-Stack JavaScript

In the last few years, developers have been improving the JavaScript language so it can be used for server-side development as well as development of applications that run in the browser. System administrators can install the Node.js code library to enable servers to run JavaScript. Server-side JavaScript web application frameworks are available, such as Express and Meteor, but none are as popular as Ruby on Rails. Some code schools are now teaching “full stack JavaScript” using the “MEAN Stack,” which combines four popular JavaScript technologies; MongoDB, Express, AngularJS, and Node.js.

There are at least a dozen popular languages that developers use to build web applications. This will continue to be true. Full-stack JavaScript is now an option but Rails is not going away. For now, the Rails ecosystem is better known with more resources for building web applications and learning development. There will always be jobs for Rails developers. Startups will always be able to find developers who have experience with Rails. Your effort in learning Rails will continue to be worthwhile. However, it is important to learn JavaScript as well.

3.7.1 AngularJS and Ember.js

AngularJS and Ember.js are the most popular JavaScript frameworks used to build single-page applications. They provide the structure and conventions that developers want for maintainable code. For complex, richly interactive web applications, these frameworks get rid of the “JavaScript soup” that is common in Rails applications.

Unlike Rails, which is hugely popular, none of these JavaScript frameworks have achieved hegemony or dominance among developers. For a learner, these frameworks require more programming experience than Rails. All of these frameworks break the familiar request-response cycle of the web. Just one URL delivers the entire single-page application. There are no web pages, only views that change completely or partially in response to user actions. Drawbacks to single-page applications are a slow initial load of the application, difficulty using analytics tools such as Google Analytics which rely on new pages loading in the browser, and views that won’t show up in Google search results. For all these reasons, single-page applications are best used to deliver services, not information, and require advanced skills to develop.

3.7.2 React

There’s a newer framework that can be used to dry up JavaScript soup. It’s React, a JavaScript framework developed by engineers at Facebook. It can be used for single-page applications or to organize JavaScript for interactive features in ordinary Rails applications. Unlike AngularJS or Ember.js, React only manages views, not connections to databases or routing of requests, so it is not a full-stack framework, just a framework for the view layer. React’s approach to building web pages is abstract and complex. But React is a good choice for complex interactive features, if you’re determined to avoid JavaScript soup in your Rails application.

Ultimately, your decision to use JavaScript, and how much, depends on the kind of web application you want to build. If you want to build a product catalog, with many simple pages populated by a database, a full-stack Rails application may be all you need, perhaps with a few jQuery plugins. If your application is like Facebook, with lots of interactive features and many different pages, React may be a good choice as part of a full-stack Rails application. If you want to deliver a service such as live stock-market charts, you may want to build a complex single-page application using AngularJS or Ember.js, plus IOS and Android apps, connected to a Rails API server.

If you’re going to use JavaScript, either full-stack, or combined with Rails, use a JavaScript framework to avoid JavaScript soup. React could be a good place to start.

You’ll have a better idea of the importance of Rails if you understand “What is Rails?” Let’s look at that next.

4.2.1 Web Browser Perspective

From the perspective of the web browser, Rails is simply a program that generates HTML, CSS, and JavaScript files. These files are generated dynamically. You can’t see the files on the server side but you can view these files by using the web developer tools that are built in to every browser. Later you’ll examine these files when you learn to troubleshoot a Rails application.

4.2.2 Programmer Perspective

From the perspective of a programmer, Rails is a set of files organized with a specific structure. The structure is the same for every Rails application; this makes it easy to collaborate with other Rails developers. We use text editors to edit these files to make a web application.

4.2.3 Software Architect Perspective

From the perspective of a software architect, Rails is a structure of abstractions that enable programmers to collaborate and organize their code. Thinking in abstractions means we group things in categories and analyze relationships. Conceptual categories and relationships can be made “real” in code. Software programs are built of “concepts made real” that are the moving parts of a software machine.

Notice that we are talking about abstractions, using language like a philosopher. Most tutorials give you step-by-step instructions, like following a recipe. You’ll get that in Book Two in this series. But to really understand programming, you should grasp that we are working with “abstractions made real.” The area of your brain that follows instructions is distinct from the area that thinks abstractly. To be a programmer, you’ll need both parts of the brain working together. Don’t worry; I’ll explain the abstractions in terms anyone can understand.

To a software architect, classes are the basic parts of a software machine. A class can represent something in the physical world as a collection of various attributes or properties (for example, a User with a name, password, and email address). Or a class can describe another abstraction, such as a Number, with attributes such as quantity, and behavior, such as “can be added and subtracted.” You’ll get a better grasp of classes in Book Two when you learn “Just Enough Ruby.”

To a software architect, Rails is a pre-defined set of classes that are organized into a higher level of abstraction known as an API, or application programming interface. The Rails API is organized to conform to certain widely known software design patterns. You’ll become familiar with these abstractions as you build a Rails application. In Book Two, you’ll learn about the model–view–controller design pattern. As a beginner, you will see the MVC design pattern reflected in the file structure of a Rails application. That’s where you will first see “abstractions made real.”

If you’ve subscribed to the video series or purchased the advanced tutorials, this eight minute video introduces the model–view–controller concept:

• Model View Controller in Rails

4.2.4 Gem Hunter Perspective

We can look at Rails from the perspective of a gem hunter. Rails is popular because developers have written and shared many software libraries (RubyGems, or “gems”) that provide useful features for building websites. We can think of a Rails application as a collection of gems that provide basic functionality, plus custom code that adds unique features for a particular website. Some gems are required by every Rails application. For example, database adaptors enable Rails to connect to databases. Other gems are used to make development easier, for example, gems for testing that help programmers find bugs. Still other gems add functionality to the website, such as gems for logging in users or processing credit cards. Knowing what gems to use, and why, is an important aspect of learning Rails.

You don’t need a subscription to view this free video introducing RubyGems:

• Free Video Lesson: What Are RubyGems

4.2.5 Time Traveler Perspective

We can also look at Rails from the perspective of a time traveler in order to understand the importance of software version control. Specifically, we use the Git revision control system to record a series of snapshots of your project’s filesystem. Git makes it easy to back up and recover files; more importantly, Git lets you make exploratory changes, trying out code you may decide to discard, without disturbing work you’ve done earlier. You can use Git with GitHub, a popular “social coding” website, for remote backup of your projects and community collaboration. Git can keep multiple versions (“branches”) of your local code in sync with a remote GitHub repository, making it possible to collaborate with others on open source or proprietary projects. Strictly speaking, Git and GitHub are not part of Rails (they are tools that can be used on any development project). And there are several other version control systems that are used in open source development. But a professional Rails developer uses Git and GitHub constantly on any real-world Rails project.

4.2.6 Tester Perspective

Finally, we can consider a Rails application from the perspective of a tester. Software testing is part of Rails culture; Rails is the first web development platform to make testing an integrated part of development. Before Rails, automated testing was rarely part of web development. A web application would be tested by users and (maybe) a QA team. If automated tests were used, the tests were often written after the web application was largely complete. Rails introduced the discipline of Test-Driven Development (TDD) to the wider web development community. With TDD, tests are often written before any implementation coding. It may seem odd to write tests first, but for a skilled TDD practitioner, it brings coherence to the programming process. First, the developer will give thought to what needs to be accomplished and think through alternatives and edge cases. Second, the developer will have complete test coverage for the project. With good test coverage, it is easier to refactor, rearranging code to be more elegant or efficient. Running a test suite after refactoring provides assurance that nothing inadvertently broke after the changes. TDD is seen as a necessary skill of an experienced Rails developer. Book Two will introduce you to the basic concepts of test-driven development and show you how to write simple tests.

You’ve seen Rails from six different perspectives. You understand Rails is a software library plus an API, as well as a community of developers. Now let’s dive deeper and consider how Rails fits in to a larger technology stack and how it can vary within the stack.

4.3.1 Full Stack

A technology stack is a set of technologies or software libraries that are used to develop an application or deliver web pages. “Stack” is a term that is used loosely and descriptively. It is a collection of technologies that fit together, interacting with each other, and providing different types of services. We say “stack” because we use different software systems or software libraries as if they were building blocks or bricks deployed in layers.

Often we consider a stack as layers added to the operating system. For a web application, we need a web server, a database, a programming language, and perhaps additional software libraries.

Earlier we learned that full-stack developers have skills to work with operating systems, web servers, databases, web applications, and JavaScript programs in a web browser. That’s a formidable stack of technologies.

There is no organization that tells you what building blocks you must use. As a technologist, your choice of stack reflects your experience, values, and personal preference, just like religion or favorite beverage.

For example, Mark Zuckerberg developed Facebook in 2004 using the LAMP application stack:

• Linux (operating system)
• Apache (web server)
• MySQL (database)
• PHP (programming language)

Zuckerberg chose an operating system, a web server, a database, and a programming language with which he was comfortable. In 2004, Rails was not well known and Zuckerberg chose to implement his ideas using PHP without any additional web application software library.

For this tutorial, your application stack will be:

• MacOS, Linux, or Windows
• Puma (web server)
• SQLite (database)
• Ruby on Rails (language and framework)

You’ll use an operating system that’s familiar to you, a basic web server that comes with Ruby, a database that’s preinstalled with Mac or Linux operating system, the Ruby language, and the Rails web application software library.

4.3.2 Rails Stacks

Sometimes when we talk about a stack, we only care about part of a larger stack. For example, a Rails stack includes the gems we choose to add features to a website or make development easier. When we select the gems we’ll use for a Rails application, we’re choosing a stack or layers of services we need just for a web application.

Sometimes the choice of components is driven by the requirements of an application. At other times, the stack is a matter of personal preference. Just as craftsmen and aficionados debate the merits of favorite tools and techniques in any profession, Rails developers avidly dispute what’s the best Rails stack for development.

The company 37signals, where the creator of Rails works, uses this Rails stack:

• ERB for view templates
• MySQL for databases
• Minitest for testing

It is not important (at this point) to know what the acronyms mean (we’ll learn later).

Another stack is more popular among Rails developers:

• Haml for view templates
• PostgreSQL for databases
• RSpec for testing

We’ll learn later what the terms mean. For now, just recognize that parts of the Rails framework can be swapped out, just like making substitutions when you order from a menu at a restaurant. The Rails stack can vary, and it is part of a larger stack that includes an operating system, web server, and database.

You can learn much about Rails by following the experts’ debates about the merits of a favorite stack. The debates are a source of much innovation and improvement for the Rails framework. In the end, the power of the crowd prevails; usually the best components in the Rails stack are the most popular.

The proliferation of choices for the Rails stack can make learning difficult, particularly because the components used by many leading Rails developers are not the components used in many beginner tutorials. In this tutorial, we stick to solid ground where there is no debate. In the advanced Capstone Rails Tutorials, we’ll explore stack choices and choose components that are most often used by professional developers.

5.3.1 Rails is Opinionated

In the mid-1990s, web applications were often written in Perl, a programming language that promised, “There’s more than one way to do it.” Perl is a prime example of “non-opinionated” software; there’s no “right way” or “best way” to solve programming problems in Perl. Famously, Perl’s documentation states, “In general, [Perl’s built-in functions] do what you want, unless you want consistency.”

In contrast, Rails is said to be “opinionated.” There is a “Rails way” for many of the problems that must be solved by a web application developer. If you follow the Rails conventions, you’ll have fewer decisions to make and you’ll find more of what you need is already built. The benefit is faster development, improved collaboration, and easier maintenance.

5.3.2 Rails is Omakase

Omakase is a Japanese phrase that means “I’ll leave it to you.” Customers at sushi restaurants can order omakase, entrusting the chef to make a pleasing selection instead of making their own à la carte choices. In a famous essay Heinemeier Hansson declared Rails is Omakase, and said, “A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework…. When we, or in some cases I — as the head chef of the omakase experience that is Rails — decide to include a dish, it’s usually based on our distilled tastes and preferences. I’ve worked in this establishment for a decade. I’ve poured well in the excess of ten thousand hours into Rails. This doesn’t make my tastes right for you, but it certainly means that they’re well formed.”

Understanding that Rails is omakase means accepting that many of the opinions enshrined in the Rails API are the decisions of a Benevolent Dictator for Life, informed by discussion with other developers who have made significant contributions to the Rails code base. For the most part, Heinemeier Hansson’s “opinions” will serve you well.

5.3.3 Convention Over Configuration

“Convention over configuration” is an example of Rails as “opinionated software.” It is an extension of the concept of a default, a setting or value automatically assigned without user intervention. Some software systems, notably Java web application frameworks, need multiple configuration files, each with many settings. For example, a configuration file might specify that a database table named “sales” corresponds to a class named “Sales.” The configuration file permits flexibility (a developer can easily change the setting if the table is named “items_sold”). Instead of relying on extensive configuration files, Rails makes assumptions. By convention, if you create a model object in Rails named “User,” it will save data to a database table named “users” without any configuration required. Rails will also assume the table name is plural if the class name is singular.

“Convention over configuration” means you’ll be productive. You won’t spend time setting up configuration files. You’ll spend less time thinking about where things go and what names to assign. And, because other developers have learned the same conventions, it is easier to collaborate.

5.3.4 Don’t Repeat Yourself

Known by the acronym DRY, “Don’t Repeat Yourself” is a principle of software development formulated by Andy Hunt and Dave Thomas and widely advocated among Rails developers. In its simplest form, it is an admonition to avoid duplication. When code is duplicated, an application becomes more complex, making it more difficult to maintain and more vulnerable to unintended behavior (bugs). The DRY principle can be extended to development processes as well as code. For example, manual testing is repetititive; automated testing is DRY. Software design patterns that introduce abstraction or indirection can make code more DRY; for example, by eliminating repetitive if-then logic.

Code reuse is a fundamental technique in software development. It existed long before Andy Hunt and Dave Thomas promoted the DRY principle. Rails takes advantage of Ruby’s metaprogramming features to not just reuse code but eliminate code where possible. With a knowledge of Rails conventions, it’s possible to create entire simple web applications with only a few lines of code.

5.4.1 When Rails has No Opinion

As you gain experience with Rails, you may encounter areas where Rails doesn’t state an opinion. For example, for years there was no “official” approach to queueing background jobs. (Tasks that take time, such as contacting a remote server, are best handled as “background jobs” that won’t delay display of a web page.) Fortunately, by 2015, the Rails core maintainers released the ActiveJob feature which implemented queueing. Much of the lively debate that drives development of new versions of Rails is focused on thrashing out the “opinions” that eventually will be enshrined in the Rails API.

5.4.2 Omakase But Substitutions Are Allowed

Implicit in the notion of “Rails is omakase” is an understanding that “substitutions are allowed.” Most of Heinemeier Hansson’s preferences are accepted by all Rails developers. However, many experienced developers substitute items on the menu at the Rails café. This has led to the notion that Rails has Two Default Stacks, as described in an essay by Steve Klabnik. Professional developers often substitute an alternative testing framework or use a different syntax for creating page views than the “official” version chosen by Heinemeier Hansson. This complicates learning because introductory texts often focus on the omakase selections but you’ll encounter alternatives in blog posts and example code.

5.4.3 Conventions or Magic?

One of the joys of programming is knowing that everything that happens in an application is explained by the code. If you know where to look, you’ll see the source of any behavior. For a skilled programmer, “convention over configuration” adds obscurity. Without a configuration file, there is no obvious code that reveals that data from a class named “Person” is saved to a datatable named “people.” As a beginner, you’ll simply accept the magic and not confound yourself trying to find how it works. It’s not always easy to learn the conventions. For example, you may have a User object and a “users” datatable. Rails will also expect you to create a “controller object.” Should it be named “UserController” (singular) or “UsersController” (plural)? You’ll only know if you let Rails generate the code or you pay close attention to tutorials and example code.

5.4.4 DRY to Obscurity

The risk that “convention over configuration” leads to obscurity is compounded by the “Don’t Repeat Yourself” principle. To avoid repetitive code, Rails often will offer default behavior that looks like magic because the underlying implementation is hidden in the depths of the Rails code library. You can implement a simple web application with only a few lines of custom code but you may wonder where all the behavior comes from. This can be frustrating when, as a beginner, you attempt to customize your application to do more than what’s shown in simple tutorials.

In the next chapter, we’ll consider some of the challenges that make it difficult to learn and use Rails.

6.1.1 It is difficult to install Ruby.

The installation process for Ruby on Rails is more difficult than downloading and installing any consumer software applications. You are setting up a development environment and you need system software as well as Ruby. Depending on what you’ve done before, you may have altered your system, introducing potentials for conflicts. Book Two provides links to good installation guides in the “Get Started” chapter. But installation instructions can’t accommodate the specific configuration of your computer. Sometimes you just have to look for someone to help. You can also use a hosted development environment, such as Cloud9.

6.1.2 Rails is a nightmare on Windows.

Windows is very popular, so why is it difficult to develop with Rails on Windows? It seems the Rails community has a bias against Windows. It does, and there’s a reason. Rails is an open source project. Most open source developers use Unix-based system tools. It is difficult and time-consuming to convert Unix-based system tools to the Microsoft Windows operating system. Open source developers prefer to spend their time maintaining and improving their Unix-based projects. And expert Windows developers are seldom interested in porting Unix-based system tools to Windows. So system utilities such as RVM are not available for Windows. And developers who create gems are seldom interested in spending time to solve the problems that arise when code has to be adapted for the idiosyncrasies of the Windows platform. This situation is not going to change, so you have to make a choice. Stay with Windows or get comfortable with Unix-based systems.

6.1.3 Why do I have to learn Git? It is difficult.

Real software development requires version control and Git is the standard tool for Rails developers. If all you do is build applications as a classroom exercise, you don’t need to learn Git. You can skip all the parts of the book that mention Git. But sooner or later, if you start doing real projects, you’ll need Git. Simple Git commands are not difficult to learn. When you’ve developed your skills and confidence you can learn the more advanced Git functions, such as branching.

6.1.4 Why worry about versions?

For simple projects you don’t need version management. My books introduce version management and prepare you to handle version conflicts. As you tackle more complex projects, and as new versions of Rails are released, you’ll face version issues and version management will be helpful.

6.1.5 Do I really need to learn about testing?

For student projects, no, you don’t need to learn about testing. But as soon as money or reputation is at stake on a project, you’ll need to begin using test-driven development. Book Two introduces TDD but you’ll need intermediate-level tutorials to develop proficiency. Once you’ve grasped the basics, testing will become easy, and it actually is fun and satisfying.

6.1.6 Rails error reporting is cryptic.

Actually, Rails error reporting is quite good. Stack traces are detailed and error messages are descriptive. Beginners have a problem because the stack traces and error messages provide a technical analysis of a problem in terms that an experienced developer can understand. If error reporting was “simplified” it might not be as intimidating but it would not as accurate. It’s up to you to gain enough knowledge to understand the error messages. Finally, the error reporting mechanism can point you to the line in your code that triggers a problem, but it can’t know what you trying to do, or describe the error in anything but technical terms.

6.1.7 There is too much magic.

The Rails “convention over configuration” principle leads to obscurity. Default behavior often looks like magic because the underlying implementation is hidden in the depths of the Rails code library. If you like to know how things work, this can be frustrating. You really have only two choices when you encounter Rails magic. You can take time to dig into the source code. If you do so, you’ll encounter frustration as you encounter complex and sophisticated code, but you may also improve your understanding and skill as a Ruby programmer. Or you can take on faith that “it just works.” Often, you just need to use the convention several times in different projects to get comfortable with the magic and stop worrying that you don’t fully understand it.

6.1.8 It is difficult to grasp MVC and REST.

Even if you learn that the acronyms mean model-view-controller and representational state transfer, MVC and REST are abstract concepts. If you simply follow a tutorial, the author will show you how to build an application that uses MVC or REST, but you won’t see any alternative, or understand why MVC or REST are best practices. When it is time to build your own application, if you don’t understand the importance of separation of concerns you won’t be sure how to structure your application. Understanding software architecture requires abstract reasoning, imagination, and experience, which takes time. It is difficult to grasp but approach it with curiosity, seek explanations, and you’ll grasp it soon enough.

6.1.9 Rails contains lots of things I don’t understand.

If you look at the Rails directory structure, you’ll see many files and folders. If you look at the Rails API, or pick up a Ruby tutorial, you’ll also see code that is unfamiliar. Book Two describes some of what you see. As you build more applications, you will gain proficiency and master more of Rails and Ruby. Yet even as you gain mastery of Rails, there will be aspects that remain unfamiliar. Don’t let the sheer complexity stop you. The truth is, you don’t have to know “all” of Rails or Ruby to build web applications.

6.1.10 There is too much to learn.

Very true. To be a full-stack web developer you need to know HTML, JavaScript, CSS, Ruby, testing, databases, and much, much more. You might think that developers who started ten years ago have an advantage because there wasn’t as much to learn when they started. But today there are many more high-quality tutorials and educational programs to accelerate your learning. And resources like Google and Stack Overflow have many more answers to questions. As the knowledge domain has grown, so have the learning resources. You don’t have to learn everything. Get a foundation in the basics and then dive deep as a specialist in an area that appeals to you.

6.1.11 It is difficult to find up-to-date advice.

Rails has been around since 2004 with major new versions released every two years. Chances are, answers to questions you find on Stack Overflow or Google were written for an older version of Rails. There is no easy way to determine if the answer is out of date. A particular aspect of Rails may have changed—or not. Even worse, the answer may work, but there may be a better way that reflects current best practices. To filter the outdated in Google, use the “Search Tools” options for specifying a timeframe. Look closely at the date of a blog posting or Stack Overflow answer. Try to find a newer answer. Usually, if there are a series of answers and things have changed, you’ll see the current best answer. If you’re uncertain, don’t be shy about posting your question to Stack Overflow. More importantly, make it your business to keep up with the community, reading Peter Cooper’s Ruby Weekly email newsletter or his daily RubyFlow site.

6.1.12 It is difficult to know what gems to use.

There are so many gems available for Rails. Some add useful features, like tagging or a mailing list API. Some are basic, such as gems for a database or front-end framework. Even among basic gems, Rails offers choices. Which are best? The Ruby Toolbox can help, but mostly you will find guidance from looking at example projects and noticing what other developers are using. There’s wisdom in the crowd.

If you’ve subscribed to the video series or purchased the advanced tutorials, this three minute video explains:

• How to Find Rubygems

6.1.13 Rails changes too often.

If you look at the Ruby on Rails Release History you’ll see there is a new major release approximately every 1.5 years. Each major release is well tested and relatively free of bugs. But new features or new approaches often require rewrites of older applications. Commercial software products often make a priority of keeping the API consistent over time. That’s not Rails. Rails is an open source project and the core team embraces innovation. The maintainers expect that you’ll keep up with changes.

6.1.14 It is difficult to transition from tutorials to building real applications.

Copying and pasting from tutorials is a good way to begin learning Rails. But you’ll only become a skilled Rails developer when you build something that is not shown in a tutorial. The first few hours (or days) when you start building a custom application can be very difficult. Focus on the basics that are described in this book. Start with user stories. Build pieces that you know how to do. Look for code samples on blogs or GitHub or Stack Overflow. Try “spikes,” little experiments that test ideas for implementation. Seek advice from peers or mentors. At first it will be slow going. But you will pick up momentum. The chapter, “Crossing the Chasm,” will provide specific strategies to help.

6.1.15 I’m not sure where the code goes.

If you follow tutorials, you’ll learn “where the code goes” with the model–view–controller design pattern. With a sense of the request-response cycle, RESTful actions in the controller, and a few guidelines such as “skinny controller, fat model” you’ll be able to build intermediate-level Rails applications. Front-end code, particularly JavaScript, can be difficult because not a lot has been published about Rails best practices. In particular, the Rails asset pipeline can be confusing for anyone who has done front-end development without Rails. If you don’t know what you’re supposed to do, do whatever works, then look for someone who can help you by providing a code review.

6.1.16 People like me don’t go into programming.

Until recently in most countries, most Rails developers have been young men with an engineering background. For people who don’t fit the stereotypical profile, it can be hard to find role models or peers who demonstrate that Rails is something everyone can learn. The challenge can be subtle, as when you have the feeling that maybe if you were different you’d find it easier to make progress. Or the challenge can be overt, when behavior of fellow students or co-workers is disturbing or hurtful (often they don’t even know!). Lack of diversity, and the cluelessness that accompanies it, is unfortunate in the Rails community. But many people are working to make the community more welcoming and inclusive. Organizations such as Rails Girls and Railsbridge are creating more diversity in the community. You may find support from peers there to affirm that you, too, are entitled to knowledge and success.

These are some of the challenges you will face in learning and using Rails. Next, we will look at how to get help.

7.2.1 RailsGuides

The Rails Guides are Rails’s official documentation, written for intermediate-level developers who already have experience writing web applications. The Rails Guides are an excellent reference if you want to check the correct syntax for Rails code. You’ll be able to use the Rails Guides after completing this tutorial.

7.2.2 Cheatsheets

Tobias Pfeiffer has created a useful Rails Beginner Cheat Sheet that provides a good overview of Rails syntax and commands.

Even better than a cheatsheet, for Mac users, is an application named Dash that offers fingertip access to reference documentation for Ruby, Rails, HTML, CSS, JavaScript, and many other languages and frameworks.

7.2.3 API Documentation

The API documentation for Ruby and Rails shows every class and method. These are extremely technical documents (the only thing more technical is reading the source code itself). The documents offer very little help for beginners, as each class and method is considered in isolation, but there are times when checking the API documentation is the only way to know for certain how something works.

• Rails Documentation - official API docs
• apidock.com/rails - Rails API docs with usage notes
• apidock.com/ruby - Ruby API docs with usage notes

I recommend Dash as a tool to look up classes, modules, and methods in Ruby and Rails. Dash is a macOS app; use Zeal on Linux. Dash and Zeal run offline (they don’t need an Internet connection) so you can use them anywhere.

10.3.1 MacOS

See this article for macOS installation instructions:

Install Ruby on Rails - macOS

10.3.2 Ubuntu Linux

See this article for Ubuntu installation instructions:

Install Ruby on Rails - Ubuntu

10.3.3 Hosted Computing

Cloud9 is a browser-based development environment. Cloud9 is free for small projects. If you have a fast broadband connection to the Internet, this is your best choice for developing Rails on Windows. And it is a good option if you have any trouble installing Ruby on Mac or Linux because the Cloud9 hosted environment provides everything you need, including a Unix shell with Ruby and RVM pre-installed, plus a browser-based file manager and text editor. Using a hosted development environment is unconventional but leading developers do so and it may be the wave of the future.

See this article for Cloud9 installation instructions:

Install Ruby on Rails - Cloud9

The article shows how to get started with Cloud9.

10.3.4 Windows

Here are your choices for Windows:

• Use the Cloud9 hosted development environment
• Install the Railsbridge Virtual Machine
• Use RubyInstaller for Windows

Cloud9 is ideal if you have a fast Internet connection. If not, download the Railsbridge Virtual Machine to create a virtual Linux computer with Ruby 2.2 and Rails 4.2 using Vagrant. Other tutorials may suggest using RailsInstaller, but it will not provide an up-to-date version of Ruby or Rails. Also, RVM does not run on Windows.

11.6.1 Prompt

The $ character is the prompt. Sometimes you’ll see extra information before the prompt:

My-MacBook:~ danielkehoe$

The prompt can be customized to provide useful information, such as the name of the current folder or the current user. Some people change the $ character to a different character, such as the > character.

Don’t be confused by a custom prompt and don’t worry about customizing your prompt right now. Just remember that when you see a $ character on the command line, the computer is waiting for you to enter a command.

11.6.2 Command

$ command -option argument

Each Unix command is a tiny software program that is already installed on your computer. Each command does a few simple things, such as list the contents of a folder or create an empty file. There are dozens of Unix commands but you only need to learn a few to develop a Rails application.

Entering a command at the prompt and pressing “Return” (or “Enter”) will result in either of two things. The computer will respond “command not found” or it will run the command and return a result to the terminal window (“the console”).

Sometimes a command is not found because it is not a built-in command and it is not installed on your computer. More often, you’ve made an error in typing the command. Unix doesn’t like capital letters (“uppercase”) so unless there is a capital letter in a filename, you probably will need to type lowercase characters.

11.6.3 Option

$ command -option argument

Most Unix commands have a default response. Many commands have options for different responses if you set an option “flag” or “switch.” You indicate an option with a - character. Most people call that character a hyphen or dash. You may hear programmers call it the “minus” character. Sometimes an option is set with –, that you might describe as “dash dash” or “minus minus.” It’s difficult to see on the typeset page of this book, but to get the - character you type the “dash” character once. In this book, –, which appears as a slightly longer dash, is actually typed as two dashes.

Two options are common among Unix commands: –help and –version (with double dashes). There are also abbreviated versions: -h and -v (with a single dash).

If you have a terminal window open on your computer, try typing:

$ man -v
man, version 1.6c

If I was coaching a beginner, I would say, “Type man space minus v. Don’t forget the space and be sure to type ‘Enter.’”

The computer returns the version number of the current installed man Unix command.

The Unix man command provides online documentation for every Unix command. Try:

$ man man
.
.
.

You’ll see the “man pages” that show exactly what to do with the man command.

You can type man followed by the name of a command to see the documentation for the command.

It is nice to know that every Unix command comes with complete instructions for use. But try reading some man pages and you’ll understand why most developers never look at man pages. Instead they use Google to search online for instructions about how to use Unix commands. Man pages suffer from the worst features of technical documentation. They are complete to the point of obscurity, providing massive detail without highlighting the most common use cases. You’re better off googling for examples of how to use Unix commands.

You’ll be stuck inside the man pages after you enter man man. Refer to your notes about how to exit a Unix program. To get out of the man program, type q to quit.

11.6.4 Argument

$ command -option argument

The term “argument” is borrowed from mathematics. Many Unix commands like a good argument. It is information that will be processed by a Unix command. Often it is a filename, if the command will operate on a file or output to a file.

For example, we can create a file with the Unix touch command or remove a file with the Unix rm command:

$ touch myfile
$ rm myfile

In both cases, we must supply a filename as an argument.

11.7.1 cd

Computers use file systems to control how data is stored and retrieved using s storage system such as a hard drive. By separating the data into individual pieces, and giving each piece a name, the information is easily separated and identified. In offices in the 20th century, documents were grouped together as files and kept in file folders in filing cabinets. Computers don’t really need to organize information as files but early computer users apparently thought of computer storage as electronic file cabinets.

In Unix, you are always expected to be somewhere in the filing cabinet. The folders, or directories, are hierarchical, so a root folder contains multiple folders, which each contains many more folders and files. One set of nested folders contains the programs and utilities which make up the operating system and system utilities. Another set of nested folders contain folders for every user who can sign in to use the computer.

Unix systems can have more than one user account. Each user is given a home directory that contains the files needed by any software programs he or she will use.

Unix expects you to always be somewhere in your computer’s file system. If you get confused or lost, you can always return to your home directory. Unix programmers like cryptic shortcuts that use unique keys from the keyboard. To get to your home directory, you can enter the directory name, which is your user name, or just type the “tilde” or “squiggle” character. On most keyboards, it is the uppercase (shift key) character to the left of the numeral 1. Look at the typeset character ~ in this book. It may look like a smudged dash, but if you look closely, you’ll see the squiggle.

Use the cd (change directory) command to go to your home directory:

$ cd ~

The computer will not return a response to the terminal window, but you’ll be positioned in your home directory. That means Unix commands will look for files in your home directory or save files in your home directory unless you specify another location.

11.7.2 pwd

Discover where you are by asking for the “present working directory.”

$ pwd
/Users/danielkehoe

The Unix pwd command will show the file path of your current directory.

It is easy to get confused and not be sure where you are. When you feel lost, use the pwd command.

11.7.3 ls

Use the pwd command to figure out where you are. Then look around with the ls command.

The ls command lists the files and folders that are contained in your present working directory.

$ cd ~
$ ls
Applications Documents    Movies       Pictures
Downloads    Music        Public
Desktop      Library

The response shows a list of files and folders. Your list will be different.

You can use options for many different lists of files and folders.

For example, you can see a list of files and folders in a single column with ls -1:

$ ls -1
Applications
Desktop
Documents
Downloads
Library
Movies
Music
Pictures
Public

Using ls -1p, you can see a single column list with slash characters marking the folders:

$ ls -1p
Applications/
Desktop/
Documents/
Downloads/
Library/
Movies/
Music/
Pictures/
Public/

It seems there are no files in my home directory. But is that true?

11.7.4 Hidden Files and Folders

The Unix operating system allows filenames and folder names that start with a dot. These files are hidden unless you use an a option to view them.

$ ls -la
total 400
drwxr-xr-x+ 53 danielkehoe  staff   1802 Sep 27 15:48 .
drwxr-xr-x   6 root         admin    204 Dec  8  2014 ..
-rw-r--r--@  1 danielkehoe  staff  16388 Dec  8 05:52 .DS_Store
drwx------   4 danielkehoe  staff    136 Dec  8 13:13 .Trash
-rw-------   1 danielkehoe  staff  98661 Dec 12 09:00 .bash_history
-rw-r--r--@  1 danielkehoe  staff   4926 Nov 20 22:10 .bash_profile
-rw-r--r--@  1 danielkehoe  staff    792 Sep  2  2013 .bashrc
drwx------   6 danielkehoe  staff    204 Jun 26 20:24 Applications
drwx------+  5 danielkehoe  staff    170 Dec  7 08:33 Desktop
drwx------+ 12 danielkehoe  staff    408 Dec  7 08:06 Documents
drwx------+  9 danielkehoe  staff    306 Dec 12 10:57 Downloads
drwx------@ 57 danielkehoe  staff   1938 Aug 30 20:27 Library
drwx------+  3 danielkehoe  staff    102 Jul 28  2013 Movies
drwx------+  5 danielkehoe  staff    170 Sep 21  2014 Music
drwx------+ 22 danielkehoe  staff    748 Nov 26 20:57 Pictures
drwxr-xr-x+  5 danielkehoe  staff    170 Aug 11  2013 Public

Now the response is very detailed, showing hidden files as well as information about file permissions, owner name, groups that have access permissions, file size, and creation date.

Hidden files are often files that contain configuration settings or user preferences. In the example above, the .DS_Store file is created by the Mac operating system to store the screen position of a Finder window. The .bashrc file contains configuration settings for the Unix shell program named bash.

Box 11.1. Hidden Files in Cloud9

If you’re using Cloud9, you must change preferences to see hidden files. In the window that contains the file list, there is a gear icon (dark in color and difficult to see). Clicking the gear option will give you options:

• Show Root File System
• Show Home in Favorites
• Show Hidden Files

You must select all three options to see the hidden files.

11.7.5 Dots

You might notice that the response lists two files that have dots for names:

$ ls -la
drwxr-xr-x+ 53 danielkehoe  staff   1802 Sep 27 15:48 .
drwxr-xr-x   6 root         admin    204 Dec  8  2014 ..

These are not really files. These are Unix shortcuts for navigating the file system.

The single dot “file” refers to the present working directory.

The double dot “file” is a shortcut for navigating up one level in the file system hierarchy.

Dot files make Unix commands even more mysterious but they are convenient.

11.7.6 open

On a Mac, you can enter a command in the terminal that opens a Mac Finder file browser window. The command and argument open . (open space dot) opens the present working directory. Try it:

$ open .

You should see files and folders listed in the Finder window that are the same as those displayed in the terminal window. Whether you use the Mac Finder graphical user interface or the terminal, you are looking at the same file system.

On the Mac, you can point and click to move around the file system. If you want to move or delete a file, and you don’t remember the appropriate Unix command, you can use open to open a Finder window and make changes the Macintosh way.

11.7.7 mkdir

You can create a new folder with the Unix mkdir command.

Let’s be sure you are in your home directory by using the pwd command. Then create a workspace folder.

$ cd ~
$ pwd
/Users/danielkehoe
$ mkdir workspace
$ cd workspace
$ pwd
/Users/danielkehoe/workspace

After creating the workspace folder, we cd into the folder and check where we are with the pwd command.

11.7.8 touch

You can create a new file with the Unix touch command.

Often it is easier to use a text editor to create and save a new file. But we’ll use the touch command here to create a file we’ll remove later. It is called the touch command because its intended purpose is update the timestamp on files or folders by “touching” the file or folder. But the command is also useful for creating new files.

If you haven’t done anything since entering the previous commands, you’ll still be in your workspace folder. But let’s enter a command to move you to the workspace folder, just in case you are elsewhere.

First we cd using a filepath that contains the ~ “tilde” shortcut for the home directory. In essence, we are saying, “move to the workspace folder contained in the home directory.”

$ cd ~/workspace
$ pwd
/Users/danielkehoe/workspace
$ touch myfile.txt
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
-rw-r--r--   1 danielkehoe  staff     0 Dec 12 15:11 myfile.txt

You’ve created a file myfile.txt inside the workspace folder. Then we list the contents of the folder so we can see the new file.

11.7.9 mv

Unix provides the mv command to rename files and folders. It’s an abbreviation for “move” and was originally intended to move a file from one directory to another. You can use it to move files and folders. And you can use it to “move” the name of the file as well.

Let’s rename myfile.txt:

$ mv myfile.txt my_file.txt
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
-rw-r--r--   1 danielkehoe  staff     0 Dec 12 15:11 my_file.txt

We’ve changed the name of the file by adding an underscore character. The underscore character is commonly used as a substitute for a space between words in a filename. The Mac operating system can accommodate spaces in filenames but it is bad practice to use spaces in filenames when you work on the command line. You can work with filenames that contain spaces by surrounding the filename with single quote characters (like ‘my file.txt’) but it is inconvenient and most developers simply avoid spaces in filenames.

11.7.10 cp

You can copy a file with cp command. You must enter two filenames as arguments: the name of the original file and the name you want for the copied file.

$ cp my_file.txt my_file_2.txt
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
-rw-r--r--   1 danielkehoe  staff     0 Dec 12 15:11 my_file.txt
-rw-r--r--   1 danielkehoe  staff     0 Dec 12 15:16 my_file_2.txt

The ls response shows we have two files.

The cp command requires flags if we want to copy a folder.

We’ll use the mkdir command to create a folder:

$ mkdir myfolder
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
drwxr-xr-x   2 danielkehoe  staff   68 Dec 13 05:13 myfolder

Let’s try to copy it:

$ cp myfolder myfolder2
cp: myfolder is a directory (not copied).

The error message indicates we cannot copy a directory.

Let’s try it with the -r flag to recursively copy contents from one folder to another:

$ cp -r myfolder myfolder2
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
drwxr-xr-x   2 danielkehoe  staff   68 Dec 13 05:13 myfolder
drwxr-xr-x   2 danielkehoe  staff   68 Dec 13 05:21 myfolder2

With the added flag, we are able to copy a folder.

11.7.11 rm

Let’s remove the files we just created. Unix provides rm, the “remove” command.

First, let’s check that you are still in the workspace folder.

$ pwd
/Users/danielkehoe/workspace
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
-rw-r--r--   1 danielkehoe  staff     0 Dec 12 15:11 my_file.txt
-rw-r--r--   1 danielkehoe  staff     0 Dec 12 15:16 my_file_2.txt

Then enter the rm command, providing the filename as an argument:

$ rm my_file.txt
$ rm my_file_2.txt
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..

The ls command shows the files are gone.

When you delete a file using the Mac Finder file browser, the file is moved to a Trash folder. When you use the Unix rm command, the file is gone forever. There is no Trash folder for recovering a file when you use the rm command.

11.7.12 Removing a Folder

Let’s remove a folder. We’ll assume you are in the workspace folder and the folders you created earlier are still there.

$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:21 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
drwxr-xr-x   2 danielkehoe  staff   68 Dec 13 05:13 myfolder
drwxr-xr-x   2 danielkehoe  staff   68 Dec 13 05:21 myfolder2

The ls command shows we have folders myfolder and myfolder2.

We can’t remove a folder with the ordinary rm command:

$ rm myfolder
rm: myfolder: is a directory
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..
drwxr-xr-x   2 danielkehoe  staff   68 Dec 13 05:13 myfolder
drwxr-xr-x   2 danielkehoe  staff   68 Dec 13 05:21 myfolder2

We get an error message and the ls command shows the file is still there. This can be frustrating for someone who is not skilled with Unix.

You’ll need to “set a flag” (use an option) to remove a folder using the rm command.

$ rm -rf myfolder
$ rm -rf myfolder2
$ ls -la
total 8
drwxr-xr-x   7 danielkehoe  staff   238 Dec 12 15:11 .
drwxr-xr-x+ 53 danielkehoe  staff  1802 Sep 27 15:48 ..

Now the ls command shows the folders are gone.

We use the r option to remove the contents of the folder recursively. And the f option to force the removal without asking for confirmation.

11.7.13 The Mouse and the Command Line

The mouse belongs to the graphical user interface. That’s why it doesn’t work as expected on the command line. Try entering a command at the prompt:

$ rm -rf notmyfolder

If you want to edit the argument and change “notmyfolder” to “myfolder,” you can try clicking with your mouse at the point where you wish to change the text. But your mouse click will be ignored. It seems you must use the delete key to back up from end of the line to retype the argument.

But there’s a trick that works on most computers. If you press “Option” and click with the mouse, you can edit the command and argument as you would expect.

You can also move around on the command line with Ctrl-a to go to the beginning of a line, Ctrl-e to move to the end of the line, and Ctrl-u to delete everything on the command line. If you can’t remember these shortcuts, don’t worry, you can just use the delete key to move backward and retype when you need to make changes to commands.

11.7.14 Arrow Keys

The most useful trick for typing text on the command line is the “up arrow” key, which scrolls through a list of previous commands. The “down arrow” key scrolls the history of commands in the opposite direction (forward if you’ve moved backward).

With Unix, you only need to type a command once and then you can scroll back to it with the “up arrow” key. It is a real timesaver.

11.7.15 Tab Completion

There’s another trick developers use to save time when entering commands and arguments in the terminal. If you are entering a filename, and the file already exists in the present working directory, you can press the “tab” key to autocomplete the filename after typing a few unique letters of the filename.

If there is more than one filename with the same initial letters, the Unix shell will balk and beep. Pressing tab again will list all the matching filenames. Continue typing a few more letters until the Unix shell can identify one unique filename and autocomplete.

12.2.1 Install Atom

Atom is an open-source text editor, developed by a team at GitHub. It is the newest of the text editors. If you have not yet installed a text editor, I recommend getting Atom. It can be downloaded and used for free.

If you don’t have a text editor yet, download and install Atom now.

12.2.2 Other Choices

Sublime Text has been popular since 2008, particularly among developers who began learning Rails in the last seven years. Developers are expected to pay $70 USD for use of Sublime Text, which removes a nagging popup that reminds users to pay for Sublime Text.

Textmate has been around since 2004 and remains popular among a small group of veteran Rails developers who have never bothered to learn vim or switch to Sublime Text or Atom. It is a commercial product priced at $56 USD.

12.2.3 How To Use a Text Editor

You can find tutorials for these text editors on YouTube. Or skim the Atom documentation or Sublime Text documentation.

For a book with tips and tricks about using a text editor efficiently, see Learn Enough Text Editor to Be Dangerous.

13.2.1 Collaborative Learning

The best way to learn Ruby is to actually use it. That’s the concept behind this site:

• Exercism.io

With Exercism, you’ll work though code exercises and get feedback from other learners.

13.2.2 Online Tutorials

• TryRuby.org - free browser-based interactive tutorial from Code School
• Codecademy Ruby Track - free browser-based interactive tutorials from Codecademy
• Ruby Koans - free browser-based interactive exercises from Jim Weirich and Joe O’Brien
• Ruby in 100 Minutes - free tutorial from JumpstartLab
• Code Like This - free tutorials by Alex Chaffee
• RailsBridge Ruby - basic introduction to Ruby
• CodeSchool Ruby Track - instructional videos with in-browser coding exercises

13.2.3 Books

• Learn To Program - free ebook by Chris Pine
• Learn To Program - expanded $18.50 ebook by Chris Pine
• Learn Ruby the Hard Way - free from Zed Shaw and Rob Sobers
• Beginning Ruby - by Peter Cooper
• Programming Ruby - by Dave Thomas, Andy Hunt, and Chad Fowler
• Eloquent Ruby - by Russ Olsen
• Books by Avdi Grimm, including Confident Ruby and Objects on Rails.

13.2.4 Newsletters

• Practicing Ruby - over 90 helpful articles on Ruby
• RubySteps - weekly lessons by email from Pat Maddox

13.2.5 Screencasts

• RubyTapas - $9/month for access to over 100 screencasts on Ruby

14.3.1 Making an Effort

It is important to have a strategy to get started on your own, as described above. You must make an initial effort, even if picking yourself up by your bootstraps doesn’t get you very far. No one, particularly software developers, wants to help someone who can’t show they’ve made a best effort on their own. You may surprise yourself when you make an initial effort; you’ll find out what you know and identify what you need to learn. Start a list of topics you need to research or questions you need to answer. Do research. If no clear answer emerges, list the possibilities and show them to someone else. Even if you think you’ve found the answer on Stack Overflow or a blog, show someone your initial problem and the solution you’ve found. Find out if your colleague agrees or has another perspective. Showing someone your research shows you’ve made an effort and it will make it easier to ask for help when research doesn’t provide a solution. (Refer to the “Get Help When You Need It” chapter if you’re not sure where to do research.)

14.3.2 Conversation Starters

You can ask people to answer questions online, on Stack Overflow, Reddit, Quora, mailing lists, forums, IRC channels, or even by directly sending email to developers. This counts as social activity but it is inherently limited. Open-ended interaction is better, either in person or through video chat. Prime the pump with to-the-point questions, as you would on Stack Overflow, but allow the conversation to meander. Make sure your conversation includes conversation helpers like these:

• What do you think?
• How would you do this?
• Is there a better way?
• What do you think I should look at next?

Ask the kind of questions that elicit opinions that you can’t ask on Stack Overflow. Never forget to acknowledge the gift you’re receiving of time and knowledge. Express your thanks, state clearly how the conversation has benefited you, and offer to report back on how the collaboration has helped your progress.

14.3.3 Pay It Forward

Don’t be shy about asking for help. If you’ve made a best effort to solve a problem on your own, and you’re willing to help others in the future, you’ll get all the help you need, and more.

There’s an unwritten rule of the open source movement. It applies whenever you ask a stranger for help, whether opening an issue on GitHub or asking for help with a project. You are not entitled to anything, whether its software code, a bug fix, or just help, if you’re only consuming. Open source is free for the taking but you’re not welcome if you’re a mooch. Luckily for all of us, causality rules do not apply (or at least there’s no temporal causality). That means, if you contribute something in the future, help will be forthcoming, sometimes more profusely than you’ve asked for. You must contribute in kind, of course. If you offer to pay money to have a bug fixed, you’re violating the spirit of open source, and you can expect either grumpiness, a hefty consulting fee, or both. If you indicate you’re willing to help with documentation or code, you’ll be welcomed even if you’re currently incapable of contributing. This applies in an interesting way to beginners. If you show you’ve tried to solve a problem on your own, and ask for help, many developers will help without any compensation other than the conviction that someday you’ll help someone in a similar situation. Software development relies on a booming pay it forward economy.

14.5.1 Online

When you ask for help on Stack Overflow, Reddit, or Quora, the answers will be most useful when you focus narrowly on a specific question. Mentorship comes from open-ended interaction, when a conversation can move in unanticipated directions, so most online interactions seldom turn into mentorship moments.

Online interactions may help you find people who can coach you. Clicking on a user’s name on a site such as Stack Overflow, Reddit, or Quora will show you a user’s profile. When someone is helpful or knowledgeable, check if they show their geographic location in their profile. If they don’t, perhaps they’ve provided a link to their website or Twitter account. If not, you may be able to send a private message. Reach out and ask where they are located, if they have time to meet to answer more questions, or can suggest anyone in your city who might be helpful. It is worth checking to see if someone is local even though most people online are not nearby.

14.5.2 GitHub

GitHub is a special case. Interactions on GitHub are at the core of the Rails community. It’s where open source software gets built. Collaboration on GitHub leads to mentorship, friendships, and business partnerships. That’s why it is so important to build a credible GitHub profile by uploading the projects you build while learning, to show that you are working steadily at becoming a better programmer.

When you look at a repository on GitHub, look at the account of the person who maintains the project. Look at the commits and the issues. Click through to the profiles of the people who’ve made the commits or commented on the issues. Experienced developers often show their location in their profile and provide their email address. If you find someone in your city, make contact. Of course, don’t ask a stranger point-blank to be a mentor! Tell them about your experience and what interests you. Ask where you can meet developers locally. You may learn about a meetup or user group meeting. If your contact is helpful, you may have an opportunity to meet for coffee.

14.5.3 Meetups

Meetups are a prime place to cultivate in-person mentorship moments. All large metro areas have active meetups for web developers, Rails developers, programmers, or startup entrepreneurs. If you’re in a rural area, make the drive once a month to the big city to connect with the community. To find the meetups, search Meetup.com or google “ruby rails (my city)”. If you’re near a university campus, check for activity on the campus. If you’re in a tech hub such as San Francisco, there’s a meetup almost every night of the week. Smaller cities have relevant meetups monthly. If you can’t find a meetup, start one!

When you visit a meetup, remember that mentorship can be hidden in anyone. Like any public event, you’ll meet people who are flakey, bigoted, garrulous, prone to halitosis or innumerable personality quirks, as well as a minority who are fascinating and obviously knowledgeable. Don’t dismiss anyone. You’ll find mentorship moments where you least expect them.

14.5.4 Workshops and Classes

You may be surprised that workshops and classes are not the ideal place to find a mentor. Obviously, given a good instructor and a relevant curriculum, a workshop or class is a great place to learn. However, it is very unlikely that a teacher will become an ongoing mentor. The instructor’s goal is to share knowledge with a group of people, so any focus on you as an individual has to be limited. Furthermore, the instructor is probably not available outside of the class or on an ongoing basis. Don’t sign up for a class hoping the instructor will become your mentor.

However, a workshop or class is an ideal place to connect with peers. There is no other place where you’ll easily find other people who want to learn the same things as you. When I teach, I’m surprised how often people come to a class expecting their education will end as soon as the class is over. If you take a class, seize the opportunity to make one new friend who will be your study partner after the class ends. Better yet, organize a study group to continue after the class is over. If you have only one new study partner, he or she can flake out. Instead, get together with three or four other learners once a week. Support each other, share your excitement, and invite mentors to come speak to your study group.

Peer learning has much in common with mentorship. The leading code camps recognize that collaborative problem-solving skills are as important as technical skills. When students team up to work through exercises or build applications, there’s a natural give-and-take as each takes turns making discoveries and sharing knowledge. You don’t have to enroll in code camp to be part of a peer learning environment; you can create it yourself in a study group. This isn’t a relationship of mentorship, but it is an opportunity to experience mentorship moments.

14.5.5 On the Job

You are most likely to find a commitment to mentorship on the job. If you’ve been hired to work as a Rails developer, at a company with Rails developers on the team, you’re in an ideal environment to learn. Not everyone has the skills to be a good mentor and you may struggle if you are stuck with a senior developer who is a know-it-all or assumes you know more than you do. Still, you have immediate access to developers with knowledge and the company has every reason to encourage you to learn. Unless the company has an explicit program to assign coaches to new hires, you will probably not call someone your mentor. Instead, recognize that you can cultivate mentorship moments by asking for guidance beyond the immediate assignment. In a stressful environment where your team is delivering code against deadlines, not everyone may be able to devote time to teaching. You should seek mentorship moments where you can.

Some companies are committed to building a culture of mentorship. When you are looking for a job, make it your priority to seek a job offer from companies where you will find mentors. For a first job as a developer, the opportunity to learn on the job is far more valuable than any other benefits. When you interview, ask if the company encourages pair programming. Ask if you will have time to work on a pet project to learn new skills, and if it will be acceptable to ask your teammates to answer questions or provide a code review for your pet project. Ask if the company encourages team presentations about new technologies. Ask if anyone from the company volunteers to teach at workshops or gives presentations at meetups or conferences. Some hiring managers will be proud to describe the company’s commitment to developer education. If they’re not, it’s a red flag that the company may not be a good fit for you.

Small startups are not a good place to look for mentorship, if the runway is short and the founders are trying to launch before funding runs out. Companies that have closed a Series A round (the first release of stock to venture capital firms and other private equity investors) will still be tightly focused on getting a product to market, with no time to coach new hires. As a company takes additional rounds of investment, beyond the Series B round, the company will have grown beyond an initial two or three engineers and may recognize the value of hiring and coaching inexperienced developers. To some companies, mentorship is part of a strategy to develop their technical depth. These are the companies that are ideal for new developers.

14.6.1 Entrepreneurs

If you want to launch a startup, stop and ask yourself what your priorities should be. Startup success depends on asking yourself every day, “What is the most important task I need to accomplish today?” Chances are, it is not learning to code. Working through my books, you’ll learn enough to work with a skilled developer, whether a cofounder, an employee, or contractors. Your most important task is to determine the product/market fit for your business idea. You must develop a Minimum Viable Product (MVP) and start the process of acquiring customers who can tell you if your product has value. Anything else defers the day of judgment when real customers will tell you whether they are willing to spend money on your product.

If you are pursuing your own business vision, you’ll only delay judgment day if your priority is to learn Rails. If you haven’t already, start looking for a technical cofounder or people you can hire (if you have your own funds). Angel investors and venture capitalists are reluctant to fund a solo founder, even when an entrepreneur is highly skilled technically. Investors place more importance on the ability and track record of the team than on a business idea; obviously, a skilled team is a better investment risk than a solo founder who just started learning Rails. In today’s investment climate, you won’t be seeking investment if you don’t yet have an MVP and customer traction. But you should start recruiting your team. The good news is that you’ve learned enough about web development to have credibility when approaching a potential technical cofounder. Among developers, there is no one more ridiculed than the non-technical founder who makes no effort to learn to code and expects someone else to do all the technical work. You’re not that guy or girl. You could build your web application yourself, given enough time. But in the best interests of your business, you should look for a partner who will be your technical mentor, guide, and helpmate as you become a better coder and build out your MVP.

You can seek a technical cofounder in the same way you seek mentorship moments. Your agenda will be larger; anyone who is a mentor or peer may be a potential business partner. Look for help to improve your technical proficiency. As you build a personal relationship with a mentor or peer, you may have an opportunity to introduce someone to your business vision. It is very unlikely you can build a business on your own, so start looking for a partner while you continue to learn to code and develop your MVP.

You won’t be having meetings with potential partners every day. On days when you are not looking for a partner, work on the user stories that will define the requirements for your MVP. You don’t need anything more than you’ve learned in this book to develop your user stories and plan your product. Work on wireframes and show your ideas to anyone who will listen. Take a break from product planning to work on your coding skills. Try tackling one or two user stories and see if you can implement a basic feature you need for your MVP. There’s no better way to learn to code than building the product that you need for your business, especially if you get help and feedback along the way.

14.6.2 Lifestyle Businesses and Personal Projects

Don’t let anyone discourage you if you have an idea for a web application that will supplement your earnings from a job, or even let you quit your job to enjoy a “lifestyle.” The investment community disdains lifestyle businesses that have limited “upside” (the revenue growth that rewards investors). Personally, I think lifestyle businesses are great. Without the pressure from investors, and with income from an existing job, you can take your time to learn to code, enjoying the process of learning application development with your goal in mind. It is still worthwhile to seek out a mentor, but you can continue to pursue learning on your own with all the resources we list in the next chapter.

Personal projects can become lifestyle businesses when they begin to generate revenue. Of course, there are many personal projects that are not intended to be moneymakers, for example, a web application for a faith group or a charity, or just a side project that helps you learn to code. Again, seek mentorship moments, or work in a group that learns together, and you’ll develop your skills faster. Play around with user stories and wireframes to see if it helps you organize your project. Try writing feature tests. You may not need to write tests for a personal project but you may discover a feeling of competence and confidence that goes with testing. With a personal project, the journey is the reward. Indulge in the luxury of learning for its own sake and focus on the satisfaction of seeing applications run that you’ve built with technologies that are new to you.

15.1.1 Databases

Book Two will explain how to create a model, a software object that represents data in a database.

When you create a model, you create an object that handles data only for the brief life of the request-response cycle, when it is active in a computer’s working memory. You’ll want data to persist beyond the brief request-response cycle, after objects disappear from working memory. Rails does not include a built-in database. It offers the flexibility of using several different industrial-grade database systems. Relational database management systems such as SQLite, PostgreSQL, MySQL, and Oracle all use Structured Query Language (SQL) as an interface to store and retrieve data. These databases run separately from a web application, requiring their own database servers.

Rails provides a component, named Active Record, that connects to these database servers. Active Record is a framework for Object-Relational Mapping (ORM), connecting application models to database tables in a relational database management system (DBMS). Active Record makes it possible to save model data as a record in an external database, preserving complex relationships among the data.

Application development would be easy if we could just use spreadsheets to save our data. However, some data, such as a document, is too large to fit in the columns and rows of a spreadsheet. More significantly, database management systems are designed to accommodate relationships among the data. That’s why they are called relational database management systems. For example, an ecommerce application might have a Customer model and an Order model. Active Record allows developers to use the Rails API to describe associations among models and interact with a database. For example, you can make sure that an order is not created unless it is associated with a customer. Additionally, Active Record provides a query interface. You can use the query interface to find all orders associated with a particular customer.

15.1.2 Testing

You learned about the basic concepts and terminology of testing in Book Two. If you’re working on a personal project or your own startup, you can learn more about Minitest to gain the skill you need to write robust tests. If you expect to work with other Rails developers professionally, you’ll need to learn to use RSpec for testing.

15.1.3 Authentication and Sessions

Most web applications need a way for users to sign in, permitting access to some features of the application only for signed-in users. The popular gem Devise is used to add authentication for users who register with an email address and password. OmniAuth is a gem for authentication using a service such as Facebook, Twitter, or GitHub. Most Rails developers will use these gems because they are robust and well-tested.

To understand how authentication works, you’ll need to learn about sessions in a web application. The web, as originally built, was stateless. A server simply responded to a request by delivering a file. To enable ecommerce applications, cookies were adopted in 1997 as a way to preserve state. Each time the browser makes a request, it will send a cookie. A web application will check the value of the cookie and, if the value remains the same, the application will recognize the requests as a sequence of actions or a session. A session begins with the first request from a browser to a web application and continues until the browser is closed. Cookie-based sessions give us a way to manage data through multiple browser requests. Rails does all the work of setting up an encrypted, tamperproof session. The data we most often want to persist throughout a session is an object that represents the user.

15.1.4 Authorization

We use authentication to verify a user’s registered identity, so we know the person signing in is the same person who signed up earlier. We use authorization to limit access to pages of a web application. Authorization is typically restricted by role, so users are assigned roles with differing access privileges. In the simplest implementation, we check if a user has a specific role (such as administrator) and either allow access or redirect with an “Access Denied” message. Roles are attributes associated with a user account, and often implemented in a User model.

There are no standard conventions for implementing roles and authorization in Rails. Developers often implement roles from scratch and use gems such as Pundit or CanCanCan to implement authorization. For most web applications, you’ll need to learn how to implement roles and authorization.

15.1.5 JavaScript

JavaScript is a general-purpose programming language (like Ruby). It is the language used to manipulate web pages within a browser. Every web developer needs to know JavaScript. For a Rails application, you might develop application features such as auto-complete search forms using a combination of jQuery and AJAX techniques. For more sophisticated web applications, such as a single-page application (SPA) that loads in the browser as a single web page and offers a fluid user experience similar to a desktop application, you’ll need to learn to use a JavaScript framework such as Ember.js, AngularJS, React, or Backbone.js. If you intend to specialize as a front-end developer, focusing on user interaction and the browser interface, you’ll need to become an expert in JavaScript.

15.1.6 Other Topics

There is much more to learn before you gain full proficiency as a Rails developer. Here’s an illustration:

Figure 15.1: Rails Competencies.

The graphic above is from a blog post, This is Why Learning Rails is Hard, by Brook Riggio of the Code Fellows code camp in Seattle. You can see the graphic in detail. The first time I saw it, I felt despair. It is a mind map of all the topics a skilled developer should know. The branches on the right side are topics that are specific to Rails, as well as general skills required of a Rails developer, such as Git, the Ruby language, and software engineering competencies. The branches on the left are general areas of knowledge that would be understood by any web developer, such as the Unix command line, web fundamentals, deployment, testing, and SQL. Brook Riggio says, “If this looks intimidating to you, you’re not alone…. Learning Rails is hard because there are many independent concepts to learn.” I recommend you spend half an hour each day googling each topic listed on Brook Riggio’s map. In three months, you’ll have a “big picture” of the knowledge areas that are important to a Rails developer. You can’t learn everything at once, so dive further into the topics that interest you. As you tackle new projects, you’ll learn more, and you’ll add depth to your understanding of each topic on the map.

15.1.7 Curriculum Guides

Brook Riggio’s map gives you a list of topics for learning. But it is helpful to tackle the topics in a sequence that makes sense. You’ll also need recommendations for the best learning materials. For a curriculum that organizes the topics you need to become a web developer, I recommend:

• The Odin Project

It is a unique community-driven curriculum, organized by Erik Trautman, the founder of Viking Code School, that gives you a roadmap of what to learn, and where to learn it.

15.2.1 Code Camps

Starting in New York City with General Assembly in 2011, and Dev Bootcamp in San Francisco in 2012, the market for developer education has been booming. Right now, in San Francisco, there are a dozen organizations offering immersive code camps, and dozens more in large cities worldwide. These organizations offer eight- to twelve-week courses, priced around $10,000 to $12,000 USD. For a list of code camps, see these websites:

• Course Report
• Switch
• Techendo Reviews

Code camps are a great way to become a developer, if you can afford the cost, and intend to recover the cost by finding a high-paying job as a developer. The best code camps create an environment of peer-based learning, where you pair with other students to solve technical problems and build applications, just as you would in the workplace. Code camps also provide relentless pressure to learn, from teachers and peers, but primarily from yourself. The quality and depth of technical knowledge you’ll acquire varies greatly depending on the code camp curriculum and the individual instructors they’ve hired. All code camps provide the motivation and social context for accelerated learning, delivering self-confidence that comes from the encouragement and feedback of teachers and peers.

If you don’t have money to pay for code camp, all is not lost. You can teach yourself Rails with books and, with effort, you’ll be good enough to start a web-based business or look for a job. I recommend that you build your self-confidence by developing applications on your own. And certainly, find other learners and study together. Most Rails developers are self-taught, at least within the domain of web application development, so code camps or university programs are wonderful, if you can afford the cost, but not essential.

15.2.2 Other Classrooms

It’s unusual to find a university or community college that offers classes in web development with Rails. In the US, university computer science programs focus on analytical reasoning and the conceptual underpinnings required for advanced research in the field. Some community colleges teach web development but it is difficult for the schools to find experienced Rails instructors, especially given the disparity in salaries between teaching and software engineering. However, universities or community colleges are good places to meet other students and form a study group, to provide social support for learning.

Classes taught in the community, often free or low-cost, are surprisingly good places to learn. Teachers and organizers are highly motivated and may be experienced Rails developers giving back to the community. Community-based classes or workshops are often poorly publicized, so you’ll have to search hard for these courses.

Women have a good chance of finding peer organizations that teach programming and web development with Rails. Start by looking at the course schedules for these organizations:

• Rails Girls
• RailsBridge
• Girl Develop It
• Women Who Code

These organizations only offer introductory classes, so you’ll have to study on your own for deeper knowledge. Short courses such as weekend workshops are valuable because you can find other students who want to start a study group.

15.2.3 Online Courses

It’s no longer necessary to go to a classroom to go to school. Online courses range from online code camps that provide videos and one-on-one coaching, to websites that offer a selection of pre-recorded videos packaged as a course, to MOOCs (massive open online courses) offered by consortiums of universities.

Chasing the runaway success of classroom-based code camps, you’ll find a number of companies that offer code schools delivered online. Here are a few that combine videos with personal coaching:

• Flatiron School Online Campus
• Bloc.io
• CareerFoundry
• Code Union
• Launch School (formerly Tealeaf Academy)
• The Firehose Project
• Thinkful
• Thoughtbot Upcase
• Viking Code School

The online code schools provide some of the benefits, specifically curriculum and coaching, of the classroom-based code camps, at a fraction of the cost. Videos, homework projects, and online mentors can’t reproduce the intense peer-based learning of the classroom code camps. But you don’t have to quit your job or move to a another city.

MOOCs provide university-level education online. You can search a database of MOOCs at the Class Central website. I recommend the edX course:

• CS169.1x Engineering Software as a Service

It is a nine week class, it is free, and it is taught four times a year. It is based on a software engineering class taught at the University of California, Berkeley. The professors have written their own textbook to accompany the class, Engineering Software as a Service: An Agile Approach Using Cloud Computing. The class is very worthwhile, if you have the time and it fits your schedule.

15.2.4 Videos

Online code camps and MOOCs provide supervised learning, combining videos with access to coaches or instructors. If you want self-paced study, without access to a coach, you’ll find hundreds of videos online, varying greatly in quality. There’s one big problem with videos: The ones that are easiest to find are often outdated. It is very difficult for producers to revise videos and, as you know, Rails changes often.

Michael Hartl, author of the Ruby on Rails Tutorial, a book I recommend, offers screencasts to accompany the book. The cost is $149 USD.

Go Rails offers dozens of intermediate and advanced screencasts. Chris Oliver started producing the videos in mid-2014, so they are newer than most Rails screencasts you’ll find on the web. These are task-focused videos, good for supplementing a book or course. Some are free, some are available with a $19 USD subscription.

RailsCasts seems to always be recommended by Rails developers, and these screencasts were once among the best ways to learn about Rails. RailsCasts creator Ryan Bates left the community in mid-2013 and, unfortunately, many of the screencasts are no longer current or relevant. Still, they are worth a look.

Lynda.com offers a Ruby on Rails 4 Essential Training 12 hour video series at a cost of $25 USD for a monthly subscription. It covers Rails 4.0 and is an adequate introduction at a very low cost.

Thoughtbot Upcase, formerly known as ThoughtBot Learn Prime, is a program from the respected ThoughtBot consulting firm that provides videos for $49 USD monthly, with coding exercises and a personal coach at a higher price. You can see the Upcase curriculum for an overview. The program is well-regarded.

Code School is famous for its Rails for Zombies course, and the company offers a dozen additional courses that cover both Ruby and Rails. The courses combine instructional videos with in-browser coding exercises at a cost of $29 USD per month. The quality is high, the videos are current, and the company tries to make the topics entertaining.

Pragmatic Studio, publishers of many high-quality Rails books, offers a series of 26 videos for $179 USD. The course is a solid introduction to Rails.

Baserails.com is a video series, available with a $25 USD monthly subscription, that shows you how to build an application. It’s good if you want practice before building something on your own.

One Month Rails is an 8 hour video series aimed at beginners. It’s priced at $99 (though you can find discount codes if you search). If you’ve read Book Two, you should skip One Month Rails and focus on intermediate-level books and courses.

Treehouse is a subscription site ($25 USD per month) with a big budget and many course offerings. The courses on Ruby and Rails don’t provide enough depth to take you beyond a beginner level.

Tuts+ offers several Rails courses. Some are out of date.

Codecademy offers a series of courses that combine videos with interactive quizzes on Ruby and JavaScript. The course on JavaScript is often recommended. However, the format is very much classroom-oriented without practical context.

Udemy offers a range of video courses on Ruby and Rails. This is crowd-sourced content (like YouTube) and the quality varies greatly. If you’ve found a great course on Udemy, email me and I’ll list it here in the next version of the book.

Skillshare is another source of crowd-sourced video courses. Many offerings on Ruby and Rails are out of date.

As you can see from the long list, videos are plentiful. Avoid the old ones.

15.2.5 Books

At the beginning of this chapter, I recommended Easy Active Record for Rails Developers by Jason Gilmore because it is focused on databases and Rails, the next thing you need to study. Other books deserve mention.

One book stands out among all:

• Ruby on Rails Tutorial by Michael Hartl (free online)

More Rails developers read, and recommend, Michael Hartl’s book than any other. For you, after reading this book and Easy Active Record for Rails Developers, Michael Hartl’s book will be a review of what you’ve learned. I hope you will breeze through it, given the fundamental concepts you’ve already learned.

Two other books on Rails are notable:

• Agile Web Development with Rails 5 by Sam Ruby
• The Rails 5 Way by Obie Fernandez

Both are dense, comprehensive, and authoritative. In my opinion, you should start building Rails applications before digging into these books. As you begin building applications, dip into any of these books for further explanation and insight.

I recommend the book by Justin Weiss, Practicing Rails: Learn Rails Without Being Overwhelmed. The book provides useful technical tips and tricks, such as techniques for debugging, but the focus of the book is overcoming challenges that new developers commonly face. You’ll find advice about keeping up with the Rails community and managing time and motivation when learning Rails, as well as overcoming “the tutorial gap” to begin building your own applications.

Several other books should be on your reading list to improve your skill:

Rebuilding Rails by Noah Gibbs. If you like to discover how things work, you’ll gain a deep insight into Rails from Noah Gibbs’s book, as he shows you how to build a framework like Rails from scratch.

Practical Object-Oriented Design in Ruby by Sandi Metz. A must-read that teaches the techniques of master programmers.

In addition to the books listed here, I recommended several books to help you learn the Ruby programming language at the the end of the chapter, “Just Enough Ruby.”

17.1.1 Financial Backers

The following individuals provided financial contributions of over $50 to help launch the book. Please join me in thanking them for their encouragement and support.

Al Zimmerman, Alan W. Smith, Alberto A. Colón Viera, Andrew Terry, Avi Flombaum, Brian Hays, Charles Treece, Dave Doolin, Denzil Villarico, Derek Rockwell, Eito Katagiri, Evan Sparkman, Frank Castle, Fred Dixon, Fred Schoeneman, Gant Laborde, Gardner Monks, Gerard de Brieder, GoodWorksOnEarth.org, Hanspeter Leupin, Harald Lazardzig, Harsh Patel, James Bond, Jared Koumentis, Jason Landry, Jeff Whitmire, Jesse House, Joe Wilmoth Jr., John Shannon, Joost Baaij, Juan Cristobal Pazos, Kathleen Sidenblad, Laird Hayward, Logan Hasson, Ludovic Kuty, Mark Gilbert, Matt Esterly, Mike Gilbert, Niko Roberts, Norman Cohen, Paul Philippov, Robert Nadar, Rogier Hof, Ross Kinney, Ruben Calzadilla, Stephane Moreau, Susan Wilson, Sven Fuchs, Thomas Nitsche, Tom Michel, Youn Shin Kang, Yuen Lock

17.1.2 Editors and Proofreaders

Dozens of volunteers offered corrections and made suggestions, from fixing typos to advice about organizing the chapters.

Alberto Dubois Ribó, Alex Finnarn, Alex Zielonko, Alexandru Muntean, Alexey Dotokin, Alexey Ershov, André Arko, Andreas Basurto, Ben Swee, Brandon Schabel, Cam Skene, Daniella Zimmermann, Dapo Babatunde, Dave Levine, Dave Mox, David Kim, Duany Dreyton Bezerra Sousa, Erik Trautman, Erin Nedza, Flavio Bordoni, Fritz Rodriguez Jr, Hendri Firmana, Ishan Shah, James Hamilton, Jasna Vukovic, Jeremy Schneider, Joanne Daudier, Joel Dezenzio, Jonah Ruiz, Jonathan Lai, Jonathan Miller, Jordan Stone, Joreal Whitfield, Josh Morrow, Joyce Hsu, Julia Mokus, Julie Hamwood, Jutta Frieden, Laura Pierson Wadden, Marc Ignacio, Mark D. Blackwell, Mark Everhart, Michael Wong, Miguel Herrera, Mike Janicki, Miran Omanovic, Neha Jain, Norman Cohen, Oana Sipos, Peter Rangelov, Richard Afolabi, Robin Paul, Roderick Silva, Sakib Ash, Sebastian Lobato Genco, Silvia Obajdin, Stas Sușcov, Stefan Streichsbier, Sven Fuchs, Tam Eastley, Tim Goshinski, Timothy Jones, Tom Connolly, Tom Michel, Tomas Olivares, Verena Brodbeck, Will Schive, William Yorgan, Zachary Davy

17.1.3 Photos

Images provided by the lorempixel.com service are used under the Creative Commons license. Visit the Flickr accounts of the photographers to learn more about their work:

• photo of a white cat by Tomi Tapio
• photo of a cat by Steve Garner
• photo of a cat by Ian Barbour

The photo of a fluffy white cat by Tomi Tapio is used in the application.