English | MP4 | AVC 1280×720 | AAC 44KHz 2ch | 54 Lessons (8h 9m) | 989 MB
Intro and Setup
Welcome! After taking a peek at the apps we’re going to build in this course, we’ll help you get your development environment set up so you can start building Rails apps.
Create the App
To make sure everything is up and running smoothly, we start by generating a skeleton Rails app and then get a quick lay of the land.
Views and Controllers
Rails has some strong opinions about how web apps should be designed. You’ve probably heard about the MVC design in the abstract, but we break it down in practice so you understand where to put your code and the benefits of a decoupled design.
Models
Well-designed models are the foundation of any good Rails app. Active Record is the object-relational mapping library that Rails uses to connect your models to your database tables. We don’t yet have a web interface for our app, so instead we see how to create, read, update, and delete records in the database via the console.
Connecting MVC
Now that we have some events stored in the database, the next step is to display them on the index page. To do that, the model, view, and controller must all work seamlessly together.
Migrations
The details about our events are looking a little sparse. So we add more attributes, which requires knowing how to manage the database schema with migrations.
View Helpers
The new event attributes are now displayed on the index page, but their formatting leaves a lot to be desired. We use both built-in and custom view helpers to give our app a lift and make things more reusable. We also answer the question: “Where does business logic belong?”
Layouts
To give our app a consistent look and feel, all the common layout elements need to live in one definitive place. Because when it comes to the layout of your app, consistency never goes out of style.
Stylesheet and Image Assets
It’s always more enjoyable to work on an application that has some style and images. Adding in these assets gives us an opportunity to learn about the Rails asset pipeline.
Routes: Show Page
The Rails router receives incoming requests and, depending on a set of rules, dispatches these requests to an appropriate controller action. We start by defining a route that recognizes requests to show an event’s details.
Routes: Linking Pages
In addition to being able to map requests based on defined routes, the router can also generate URLs that match these routes. We learn how to use route helper methods to generate links to navigate between pages.
Forms: Editing Records
Rails has a bunch of conventions to help you create robust and friendly forms with minimal code. We unveil the “magic” as we design a form for editing records, store submitted form data in the database, and display updated records.
Forms: Creating Records
Reinforcing what we learned about forms for editing records, we tackle creating records as we continue to implement the full range of CRUD actions using resource routes.
Partials
Crafting good Rails apps isn’t just about implementing features that work as advertised. Good Rails apps also have clean, well-organized code. To that end, we learn how to use partials to structure the view layer into reusable, manageable chunks.
Destroying Records
We finish up implementing the resource routes by deleting records. Here’s the cool part: All resources follow the same routes and conventions. So at this point in the course, you can confidently build a CRUD interface for any resource!
Custom Queries
Next up, we need to fetch a subset of events from the database and order them in a meaningful way. Thankfully, Active Record has a rich query interface that insulates us from having to write raw SQL to query our data. Master these query methods and you can slice and dice your data with ease, regardless of which database you use.
Migrations Revisited
To meet a new requirement, we need to add new fields to a database table. Time for a new migration! And anytime you migrate the database, you also need to think through the ripple effects. Come along as we work through all the steps to accommodate a new migration.
Model Validations
To prevent bad (invalid) data from making its way into the database, we add a variety of model validations and explore how they work in detail.
Handling Validation Errors
With our model validations in place, we’re ready to handle and display any validation errors when submitting form data. You’ll come away with a solid strategy for ensuring the integrity of your application’s data while providing actionable feedback in the user interface.
The Flash
While on the topic of user feedback, we have a few cases where we need to flash a stylish message up on the page. It’s common for web apps to flash messages between requests, and so Rails makes it easy.
One-to-Many: belongs_to
Up to this point, we’ve been focused on one resource: events. Now we want to let folks register for events. To do that, we first create a registration resource and then start designing a one-to-many relationship between events and registrations. One of the most powerful features of Rails is the ability to easily create these types of associations. But knowing the magic incantations isn’t enough. To be empowered, you also need to how what goes on behind the scenes.
One-to-Many: has_many
Now it’s time to flip over to the other side of the one-to-many association. An event has many registrations, otherwise it wouldn’t be a very exciting event. This video shows you how all the dots are connected!
One-to-Many: Nested Resources
Registrations only make sense in the context of their associated event. To mimic that one-to-many relationship in our routes, we nest registration resources within an event resource. This is a common design technique that you’ll definitely want to have in your arsenal!
One-to-Many: Forms
How do you design a form for a one-to-many relationship so you can create child records that are associated with their parent? Answering this gives us an opportunity to apply (and reinforce) everything we’ve learned so far.
One-to-Many: Logic
Once you start making associations between models and collecting data, you’ll likely discover some interesting things you can do with it. For example, what does it mean for an event to be sold out? What’s the average star rating for a movie? What determines if it’s a cult classic? The code that answers those type of questions is part of the business logic of your domain. And knowing where to put that code is vital to designing a maintainable application.
User Account Model
User accounts are a central part of any web application. By learning how to design a basic account management and authentication system from scratch, you’ll know exactly how it works. With that understanding, you’ll have the confidence to roll your own custom solution or integrate (and troubleshoot) a third-party solution. We start by designing a solid User model that securely stores passwords using best-practice Rails conventions.
User Signup
Now we’re ready to design a signup form so users can create accounts and a profile page that displays their account information. To make the sign-up process more friendly, we also add a custom route.
Edit User Account
Obviously, users also want to be able to edit their account information, and (dare we say) perhaps even delete their account. Then, with a complete UI for user accounts in place, the stage is set for authentication and other account-related features.
Sign In
Now that users can create an account, the next logical step is to let them sign in. We start by designing a sign-in form.
Authentication
Next, we confirm you are who you say you are by authenticating a user given their sign-in credentials.
Current User
Once authenticated, we use a session to identify the current user as they navigate from page to page.
Sign Out
And of course no authentication system would be complete without a way to sign out!
Authorization
Now that we know whether a user is signed in or not, it’s time to start restricting access to parts of the application. This process is commonly referred to as authorization. And while authorization rules vary widely depending on the nature of the application, once you understand the basic technique you can apply it as you see fit.
Admin Users
Only super-special users we trust should be able to perform highly-sensitive actions in our app. So we need a way to distinguish admin users from regular users, and restrict access accordingly.
Many-to-Many Associations
With user accounts and authorization in place, we can now streamline processes within the app for currently signed in users. To do that we create our first many-to-many association which connects a user to an event using a join model and a form.
Another Many-to-Many Association
Rails has powerful conventions to help you manage many-to-many associations, but the conventions alone only take you so far. It’s up to you to model the associations with the full stack in mind: from the database tables all the way through to the user interface. We look more in-depth at these details in a second many-to-many association.
Through Associations
In the absence of a direct relationship between two models, which is the case with many-to-many relationships, how do you efficiently traverse between them? Thankfully, Rails offers a really convenient way: through associations. They can seem a bit magically at first, but we quickly dispel any confusion.
Many-to-Many with Checkboxes
Many-to-many associations are really common, so to continue building your confidence we design a third many-to-many. This time we use a through association in the models and a collection of checkboxes in the user interface to assign multiple categories to events and multiple genres to movies.
Custom Scopes and Routes
One approach to defining a custom query is to write a class-level method. But a more idiomatic and concise way to write a custom query is in a declarative style using the scope method. Doing so lets us slice and dice our events and movies into all sorts of interesting categories. With our scopes in place for specific criteria, it’s time to show them off. We set up custom routes so that users can easily filter what they’re looking for.
Friendly URLs and Callbacks
URLs are the user interface of the web. We browse to them, bookmark them, post them to Twitter, email them to friends, and share them in other ways. And don’t forget the search engines that crawl them! As part of your app’s user interface, URLs require intentional design. One common technique is to include meaningful and friendly names (rather than numeric ids) in resource URLs. We show you exactly how to do that, exploring Active Record callbacks along the way.
Deployment
Putting your Rails app into production shouldn’t cause fear and trembling. Deploying Rails apps has gotten a lot easier over the years thanks in large part to cloud services such as Heroku. We’ll show you how to deploy your Rails app for the first time, and incrementally roll out application updates with ease!
Active Storage File Uploads
Rails has a built-in solution for letting users upload files. Active Storage facilitates uploading files to a variety of destinations, including cloud storage services such as Amazon S3, Google Cloud Storage, or Microsoft Azure. To get things started, we set up Active Storage to store uploaded images on the local disk in development. We also go behind the scenes to see how Active Storage manages uploads using two database tables and a polymorphic association.
Encrypted Credentials
All the cloud-based storage services require a set of super-secret credentials to verify who we are. Here’s the rub: we need a way to encrypt those credentials so we can safely deploy them along with the application code. And when the application runs in production, we need a way to decrypt the encrypted credentials so Active Storage can use them to communicate with our storage service. Thankfully, Rails has a tried-and-true way to do that.
Uploading Files to Amazon S3
Finally we’re ready to use Active Storage to store uploaded images on Amazon S3 in production! And from there, it’s pretty straightforward to store uploaded files in any supported storage service.
Table of Contents
1 Introduction
2 Create the App
3 Views and Controllers Part 1
4 Views and Controllers Part 2
5 Models Part 1
6 Models Part 2
7 Connecting MVC
8 Migrations
9 View Helpers
10 Layouts
11 Stylesheet and Image Assets
12 Routes Show Page
13 Routes Linking Pages
14 Forms Editing Records Part 1
15 Forms Editing Records Part 2
16 Forms Creating Records
17 Forms Creating Records
18 Destroying Records
19 Custom Queries
20 Migrations Revisited
21 Model Validations
22 Handling Validation Errors
23 The Flash
24 One-to-Many belongs_to
25 One-to-Many has_many
26 One-to-Many Nested Resources
27 One-to-Many Forms
28 One-to-Many Logic
29 User Account Model
30 User Signup
31 Edit User Account
32 Sign In
33 Sign In
34 Current User
35 Sign Out
36 Authorization Part 1
37 Authorization Part 2
38 Admin Users
39 Many-to-Many Associations Part 1
40 Many-to-Many Associations Part 2
41 Another Many-to-Many Association
42 Through Associations Part 1
43 Through Associations Part 2
44 Many-to-Many with Checkboxes Part 1
45 Many-to-Many with Checkboxes Part 2
46 Custom Scopes and Routes Part 1
47 Custom Scopes and Routes Part 2
48 Friendly URLs and Callbacks
49 Deployment
50 Active Storage File Uploads Part 1
51 Active Storage File Uploads Part 2
52 Encrypted Credentials
53 Uploading Files to Amazon S3
54 Wrap Up
Resolve the captcha to access the links!