Ruby on Rails Welcome Welcome to Ruby on Rails Essential Training. In this course, we're going to learn the popular open source web development framework. We will walk through each part of the framework, while we also cover best practices. In real world web development techniques. We'll route browser requests to controller actions that return dynamic page content. We will learn to interact with the database, and to manage the database schema. We'll walk through the steps that go into creating, reading, updating and deleting database records. We will discover how to work with relational database associations effectively. We will learn about Rails built-in helpers. Form validations and security protections. And throughout the process, we will gain practical, hands-on experience. By building a complete Ruby on Rails application, a content management system. Let's get started learning Ruby on Rails. Using the exercise files The exercise files for this title are arranged by chapter and you can find the exercise files that correspond to the chapter that you're first looking for the chapter number. In order to make use of the exercise files, you'll also want to make sure that you first install the software, as shown in chapters two and three, which is Ruby, Ruby Gems, Ruby on Rails, and MySQL. Once you're confident that you have everything installed, then you will want to copy the folder of exercise files into your web directory or another convenient location. It's always a good idea to make a copy, so that you'll still have the original to refer back to if you make changes. On Mac, put those files into my sites directory, which is inside user directory, and which we created during the installation chapter. You will open that up, and then, you have option drag over the exercise files to create a new copy. Don't forget that you can also use the exercise files, to check your work as you go along. Beginning in chapter six we'll be incorporating a database into our project. An for the exercise files to work, your database needs to match what the files expect. After moving the files to the correct location, you will want to make sure that you have a database created. An if you set a different database password than we did, change your configdatabase.yml file, to use your password instead of mine. Then, go to your command line. And navigate to the root of your application. From there you can run rake space o t l colon import. To run an import script which will import the data the code needs. Emoarding can also be useful if you do a lot of
experimenting on your own, but then want to get your data back in sync with mine. The script will walk you through the process, with a series of prompts. If in doubt, you should be able to select the default option, for each one of those. You could hit Return to except local host as my, host name. Hit return to accept simple_cms_development if that's the name of my database and if the username used to connect to the database is simple_cms then we can hit return again. And then the import file path should be inside those exercise files at that location. Inside the database folder inside the file called simple_cms_development.sql. Once you get there you'll want to type in your password. And then it says import complete. Now both your files and your database will be in sync with mine and you'll be ready to follow along with me. What is Ruby on Rails? Introducing Ruby on Rails The first thing that you need to understand, is that Ruby on Rails is made up of two parts. Ruby and Rails. And it will be important to understand the difference, and to keep them straight in your head. So what is Ruby? Ruby is an object- oriented programming language. It was created in 1995, by Yukihiro Matsumoto, who often goes by the nickname Matz. Ruby can be used for many purposes, not just for web applications. It's just a general programming language. Now Ruby is the first half then Rails, or Ruby on Rails, is the second half. So what is Rails? It's an open-source web application framework that's written in the Ruby language. It was created in 2003 by David Heinemeier Hansson. Who the community often refers to as simply DHH for short. Rails was created as the foundation of 37signals' Basecamp application. Rails was then released as open source software, for anyone to use in 2004. Now if you remember, Ruby was created in 1995. So Ruby had been in existence for ten years, before DHH came along. And decided that Ruby would be a great programming language, for writing a web application framework. So what is a web application framework? Here's my definition. A framework is a set of code libraries and datastructures that provide generic functionality which can be used, overridden or further specialized. So Rails is made up of code libraries and data-structures. And Rails is going to do things for us, and help us to do things as we develop applications for the web. Then why not just call it a library, right? A simple code library? Well the main difference, is that a framework is going to do more for you than a simple code library would. It's going to provide more structure, dictate the flow control of the program, and have a lot of default
behaviors built in. Libraries typically don't do anything, until you ask them to. The Rails framework is actually going to do a lot, on its own, as a default behavior. Ruby on Rails is not the only web framework that's available. There're frameworks in other languages, Java, PHP, Perl, Python, and ASP.net. But Ruby on Rails has become one of the most popular web frameworks. In the next chapter, we'll look at why that is. And why you will want to choose Ruby on Rails. Why use Ruby on Rails? Now that we understand what Ruby on Rails is. Let's talk about why you would want to choose Ruby on Rails, as your web application framework. The single thing that most about Ruby on Rails, is the Ruby programming language. Ruby's just a real pleasure to work with. It's object-oriented. It's easily readable. It has an unsurprising syntax and behavior. It's easy to write the code. And it avoids some of the headaches that are common in other languages. Such as ending every line with a semi colon. It's a great language to use when building a web application framework. Ruby on Rails is also designed using two guiding principles that help to make it powerful and effective. The first of those is DRY code. But it's actually three letters, d r y. Which stands for, don't repeat yourself. This is a fundamental principle of software design. That says that every piece of information should be expressed in just one place. And then you can refer to that information from other places. If you need to use it more than once. And it makes sense that the easiest code to maintain is going to be DRY code. Because duplication can lead to inconsistency, can make our code unclear. And can make it harder maintain and update. So if we follow the DRY principle, we're going to end up with concise, consistent code. That's easy to maintain. And Rails was built using that very same principle. And because of the way that the framework is structured, Rails is going to encourage us to follow that same principle when we write our code. The best practice for working with Rails, is going to be to continually ask ourselves, is our code DRY? It's a good habit that we want to encourage. The second guiding principle of Rails, is convention over configuration. Rails is built using sensible default choices for everything. Those default options are what we'll use, unless we override those defaults with our own choices. That means we only need to specify the unconventional aspects. The things that are different for our code that speeds up development a lot. Most of the time we can sort of ride on those defaults, to get most of the way there. And then we only have to write code for the things that are different. Having default code that we can use, also gives us less code to maintain as well. We only have to maintain our customizations. The other benefit of these conventions and sensible defaults, is that they follow all of the best practices of web application development.
We're going to have these best practices built in, and right there. Ready for us to use and take full advantage of. It's going to help our code to be better. And our end product to be better. Now the one thing you need to be aware of though, is that Rails is very opinionated about what those best practices are. Now I'd say that 95% of the time, these are not controversial. And everyone agrees on what these best practices are. But there are some cases, where there might be two competing ideas for the best way to do something. Rails is going to take a stand. And say this is the way Rails is going to do it. It will make it a default. You can still configure your code to do things a different way. But by default, you'll get the Rails choice. So just be aware of that. The other great thing about these sensible defaults that are built into the framework, is that a lot of the time, we get extra features for free. Maybe we only need feature a and b right now. But down the road, feature c is built into the framework. And it's just there waiting for us. All we have to do is start using it. It pays a lot of dividends down the road as we continue to grow and expand our web application, and add new features. So who should use Ruby on Rails? Well, say that just about anyone can use Ruby on Rails. But the people who are going to get the most benefit out of it, are going to be developers who have some previous web experience. So they already understand a lot of the way that the web works. Developers who've been building sites that interact with databases. And those who are tired of creating and recreating the same site functionality from scratch each time. They're going to get a big benefit out of switching to a framework. And Rails is great for developers who are concerned about best practices, web standards and security. Rails is going to help us with all of those things. And last of all it's for developers who are not afraid of the command line. In Rails, we're going to be doing quite a bit of working from the command line. More so than if you've been working in something like PHP. So you have to be ready to embrace that, as you dive into Ruby on Rails. Now, many people wonder about the prerequisites to learning Ruby on Rails. we would say that the first thing, is that you want to make sure you have the web basics down already. That you understand the way that browsers work. And the way that web servers and web pages work. You don't need all of the intricacies, but just make sure that you have a fundamental understanding of how the web works. You also need to understand HTML. It is the fundamental language of the web. And everything we do in Ruby on Rails is going to output HTML. So you want to make sure that you understand HTML. It's essential to have a good understand of SQL. You don't need to be an expert, but you need to have some essential SQL under your belt. Even though Ruby on Rails is going to write a lot of the SQL for you. The concepts are still going to be present. And it's important to have an understanding of what it means to join two tables together, using a foreign key. So SQL
is going to help you a lot. Now if you don't have that already, don't worry. We will cover some of those basics as we go along. we would also recommend, that you'd learn CSS and JavaScript. They're not essential. And you can certainly develop in Ruby on Rails without having either one of them. But they enhance the experience, and make your sites better. But the biggest prerequisite, it that you should learn Ruby. Now you don't have to stop, and run off to learn Ruby before you take this course. You can absolutely dip your toe in the water, by taking this training. And then go and improve your Ruby skills later on. It's sort of like how you could have a nice visit to another country, without actually speaking the language fluently. But if you're going to live there, to work there, to dive deeper in the culture. Then you have to take the time to really learn the language of the country. That's the same way here. We can get started with Ruby on Rails, without knowing Ruby. And get around just fine. We'll have a perfectly nice visit. But if you really want to get the most out of Ruby on Rails, then you will want to learn Ruby. It's the foundation of everything that we do in Rails. Understanding MVC architecture In the last chapter, Rail is structured in such a way that it helps us to write DRY code. Remember, DRY stands for don't repeat yourself. In this session, you should take a closer look at MVC architecture that Rails uses. It's a fundamental aspect of Rails that's important to understand right from the start. So we have M, V and C. The M, stands for model. The V stands for view. And the C stands for controller. The model refers to the data objects that we use. It's the object oriented approach to design. Many things can be objects in our models, but the data in our database will be the most common type of object that we'll put there. The view is the Presentation layer. It's what the user sees and interacts with, essentially the web pages. The HTML, the CSS and the JavaScript. The controller processes and responds to user events, such as clicking on links and submitting forms. The controller will make decisions based on the request and then control what happens in response. It controls the interaction with our models and with our views. Let's take a look at a couple of diagrams that will make this clear. First, let's take a look at basic web architecture, this is a non MVC architecture. We have a browser that interacts with a web page. Of course there is a web server sitting in between them, but this is a simplified view. This web page might have lots of code,that makes decisions, and finally outputs something back to the browser. And if it database enable, it can interact with the database, pull information out, and then return that back to the browser. But the code to all of these things is in one page. A single long script.
The MVC architecture, breaks that single page up by a function. The browser communicates to the controller. Which contains only the code involved in making decisions about what should happen based on that browser request. Then if we need to interact with the database, the controller will talk to our model and our model will put all the code related to our data, and to connecting to the database. And then the model will return its results back to the controller. The controller can go back to the model if it needs, and the model can go back to the database and so on. But finally, when the controller is ready to return a result to the browser, it will send its results to the view, the Presentation layer, which contains the code related to what HTML, CSS, and JavaScript should be returned back to the browser. Essentially, we've just taken that one single webpage and broken it up, based on its function, into the controller, the model and the view. The controller handles decisions, the model handles the data, and the view handles presentation. Rails is built using the MVC architecture. We may want to try and follow this architecture and keep our code in the right places. Decision code goes in the controller, data code goes in the model, and presentation code goes in the view. Rails actually has names for the code libraries it uses for these three parts. It calls the controller ActionController, and the view ActionView. And the model is ActiveRecord. Notice that that's active record, not action record, like the other two. Those names will become familiar as we work with Rails. We're going to be accessing parts of active record when we write code in a model. Rails also package us together action controller and action view as action pack. So if you ever see the term action pack, it's just action controller and action view grouped together as one thing. They're very closely related. So keep this MVC Architecture in mind as we continue to work. We'll come back and look at this diagram periodically, it will help you to understand how Rails structures things and where we should be putting our code.