Ruby on Rails by Leila Hofer

SPEAKER: Awesome.
So today, I'm going to be talking about Ruby on Rails.
So, Ruby on Rails is a web framework.
It's basically a way to make awesome web apps, which a lot of you guys
will probably be doing for your final projects.
>> So it's also cool timing, because you're currently working
in PHP for this current problem set.
So, hopefully, a lot of these things that I'm talking about today
will ring some sorts of bells, and there'll
be some carryover between the stuff you'll learn today, the stuff you're
working on the problem sets.
>> All right.
So, what's on the agenda?
First, we're going to go over a review of MVC, model-view-controller.
Hopefully, you've learned about this some in lecture,
but it'll be a review of that.
>> Then we're going to talk a little bit about Rails,
which there are an infinite number of things I could talk about.
So we're going to go over some of the basic, what is Rails, what does it do.
>> And a little bit about Ruby 2, because Ruby on Rails is,
not surprisingly, built in a language called "Ruby."
Luckily, Ruby is a lot more intuitive than a lot of the languages
you've been working in.
So hopefully, it should be pretty easy to pick up.
>> And last, we're going to spend time going over a basic web app,
and digging into some code there.
>> So, this is the official guide to MVC.
This is what you'll find on Study 50 and lectures.
And MVC, obviously, has three parts.
So there's the model, persistent storage, managing and organizing data.
You can think about this as your MySQL database in the current problem set,
any data files you have.
There's the view, which is the presentation of information, the user
interface, and you can think about these as HTML pages and any
of the template pages you're building on this problem set.
And the controller, which handles all of the information,
kind of passes information between the databases and the view.
>> And you can think about these as your current PHP files
in the programs you're writing for Problem Set 7.
So I'm going to go into an unofficial guide, which is inspired, actually,
by last year's Ruby on Rails seminar.
I really liked the way they kind of thought about model-view-controller.
So, let's go now, into the unofficial guide.
>> So, we have a couple characters in the unofficial guide.
There is our "model," Madeline, who is very, very smart, loves data,
knows all about data, but she's a little bit anti-social,
and she doesn't usually interact much with people,
unless she's told to do so.
>> Next, there's our "view," Vicki, who is gorgeous.
She's absolutely gorgeous, but she's not so smart.
And lastly there's our "controller."
Hopefully, all of your controllers will be less nefarious than this controller
here, but this is our evil queen, Caitlyn,
who really likes ordering people around, but doesn't really
like doing things herself.
>> So, let's start with an analogy.
Let's say all of our characters work at CVS.
There are two scenarios we can think about.
For some reason, I have Scenario 2, Scenario 1, but that's all right,
we'll start with Scenario 2.
>> So, let's say a customer comes up to CVS, and Vicki is working in the front.
She's the cashier.
So, the customer asks Vicki for a piece of candy.
You know how, in CVS there's always that candy lined up in the front row.
So a customer asks for that candy.
What happens?
>> Well, Vicki doesn't know what to do, so she turns around and asks
Caitlyn. "Caitlyn, what do I do?
This customer just asked for candy."
Caitlyn, our very controlling manager says, "Well, the candy is right there,
Vicki, just give it to them.
And so Vicki says, "Oh, okay, good," She hands the candy back to the customer.
That's kind of our first scenario.
So, in this case, we're not even dealing with her model
This is just, say, a user went and clicked on a link to your web page.
The view is stupid.
It doesn't really know what to do, so it has to go to the controller.
It has to ask, "What do I do with this information?"
The controller then hands back the appropriate page,
and the view can display it.
>> We now have a second scenario, or our Scenario 1,
in this case, where a customer asks Vicki, the cashier,
for a cup that's sitting in the back, somewhere in storage.
Now, again, Vicki says, "Oh my gosh.
I have no idea what to do."
>> She turns to Caitlyn, the manager, she says, "Caitlyn,
I have absolutely no idea what to do.
They asked for a cup this time, what do I do?"
Caitlyn says, "All right, hang on."
She turns around, yells at Madeline, our model,
she says, "Madeline, go get a cut from the back."
Madeleine says, "Okay, okay."
>> Madeline goes, she knows exactly where the cups are,
she grabs the cup she hands it back to Caitlyn, our manager.
The manager hands it back to Vicki.
Vicki now can finally present the cup to the user, or the customer.
So, in this case, it's slightly more complicated.
We had a couple more parts, but basically the idea is pretty similar.
Something happens on the front end.
The user, the customer asks for something.
The view doesn't know what to do, it has to go to the controller.
The controller tells the view whether just
to hand back a certain amount of data to the user,
or to go get some data from the back, hand it back to the view,
and the view can present to the user.
>> So I think that's a useful way of thinking about MVC.
>> Now that we have that framework in mind, let's talk a little bit about Ruby
on Rails.
Ruby itself, Ruby the language, has a lot less syntax than PHP or C,
and the things you've been working on.
You'll see there are a lot fewer semicolons, a lot fewer
curly braces, which makes it a lot nicer to work with.
It reads a lot more like English.
>> Also, Ruby has some pretty fun features called
gems, which you can think about kind of like libraries in C,
or the things you include with the hash up at the top your files.
So, there are Ruby gems for just about everything.
It's a super well-documented language, and has lots of people working on it.
>> So, if you are thinking about implementing some cool feature,
try a little Googling, and there will probably
be a library for it that has some pre-built-in functions that make
whatever you want to do a lot easier.
And we'll talk a little bit about some that you
can use to enhance the web app that we're
going to talk about a little bit later.
>> All right.
Ruby on Rails, I said, is a framework.
What is a framework?
A framework is, basically, just a default structure.
It gives you a set of files and a set of procedures
for managing data, managing your views, and just
the general structure of your program.
So database, web service, web page is kind
of sets up a big chunk of your project for you,
and then you can go in and kind of change the things that you want.
>> So, that leads to kind of the second big pillar of Rails,
which is convention over configuration.
So, Ruby on Rails, the developers in the community around Ruby on Rails,
values convention over configuration.
And what that means is, there are standard procedures and ways
of doing things in Rails that are generally
accepted as the way you should, or the easiest
way to going about doing things.
>> And you can see that, when we'll actually start generating our app,
like I said, there are a bunch of files that are already built for you.
And this is kind of the convention thing.
It makes it a lot easier to navigate around your app
and find ways of doing things, if there's
a set structure, a set of procedures that you normally follow.
That said there's a lot of configuration you can do in Rails.
There's a lot of personalisation, a lot of big-- Twitter's built in Rails.
There are a bunch of other big companies that use Rails,
so this isn't to say that Rails can't do whatever you want it to do,
it's just that, generally, there's a set procedure that
makes it a lot easier if you follow it.
There's really good Rails documentation.
I'll point you to a couple other useful sources later in the presentation,
but this is just a link to the official Ruby on Rails documentation.
Definitely check it out if you're thinking of working in Rails.
>> All right.
A little bit about Ruby.
We'll address differences between Ruby and the languages
you've been working in more when we get into code examples,
but this is just kind of a cool thing that Ruby does,
which is iterating through numbers and an array.
>> So if you remember, in C, what you have to do is,
you have to set up a for loop, and you have to iterate through your array
by accessing each element.
So you have array [0], or array [1], or array [2].
In Ruby, they've taken care of a lot of that for you.
So for a for loop, you can instead use .each.
>> So, if I have an array numbers, and it has five numbers in it,
and I want to go through every number and print it out, I can just say,
numbers.each do number, which sounds a little cryptic at first,
but basically, what that's doing is, it's saying,
I have an array of numbers, I want to take each one,
and instead of saying numbers [0], numbers [1], I can just say number.
And it's going to go through each one and call
it "number" as it goes through it.
So then, I can just say, puts number, and the first time through, it'll
puts the number, which is one.
The second time through, it'll puts the number, which is two.
Third time through, et cetera.
>> So this is just a fairly common construction in Ruby,
so I thought I'd just show it to you guys,
so it's not overwhelming if you find it.
And the last difference is, at the end instead of curly braces,
we say, all right, we're done with our for loop, let's say end.
And we're telling our program that, okay, we're
done with this chunk of code.
>> So just a little bit of exposure to different types of syntax in Ruby.
>> Okay.
We are going to now just dive straight into an example,
and spend the next 40 minutes just kind of digging into it, going through it,
explaining things.
If you guys are here for the seminar, do you want to move up into the couches?
Cool, awesome.
And feel free to stop me at any point if you have questions.
Raise a hand, whatever, just shout out.
>> OK or actually, let's go back here.
>> So, I've put a link to all of the code that I've
written for this example on a website called GitHub, which
if you haven't been to GitHub before, it's
basically just a place where you can store a lot of code,
and interact with it.
It has a lot of cool features, but for now that's all that's really necessary.
>> So, there are two things that you can-- basically,
two options for dealing with this code-- you
can visit GitHub.com, and for their instructions
that you'll see for how to follow along and build your own app,
that's the same as the app in the example code,
or you can actually download all of the code
and there are examples for how to just run it right off the bat if you want.
Or sorry, instructions for how to just run it right off the bat,
if you want experiment and just kind of see what it does on your own.
We'll also be playing around with it some today.
>> So, in order to just get a copy of all of the code that's in this repository,
all you have to do is type this line into your command line,
and these slides will be available after, so no worries there.
So you can just copy this line into your command line.
It'll make a new folder with all of the example code,
or you can download it from the website because it'll be, from the CS50 website
because it'll be up there afterwards too.
>> All right, let's look at some code.
Okay.
So this is what the GitHub link looks like.
If you went to the first link that was just on the slide just displayed.
So, it tells you about the app, what's in it,
and then what's the four different kind of folders that you'll find in the app.
>> So, let's take a look at the first folder in app.
So to-do list, starting out.
Basically, what this app is going to do is, it's pretty simple,
it's just going to make a to-do list.
>> And on your to-do list, you'll be able to add items,
you'll be able to delete items, you'll be able to view individual items,
edit items, and see all of the items in your list.
>> So, fairly simple functionality, but this is what Rails is best at.
Well, Rails is good at a lot of things, but this
is kind of the foundation of Rails, and once you
know how to kind of do these four actions:
create, read, edit and destroy, it's kind of-- I
always find "destroy" a really violent word.
I don't know why they just use "delete," but anyway, the convention
is to say "destroy" so we're going to destroy items.
But once you can do these four things, basically, the world
is open to you in web development, and so it should be a useful example.
All right.
>> So, actually, first, I'm going to show you what this, in practice, what
this to-do list is going to do.
And, I'll explain.
So, if we go to, I always forget the exact syntax
for starting a Rails server, but that's why I wrote it down.
All right.
So, this is just starting a server.
You guys are all doing something similar on the Problem Sets, not
this exact syntax.
We'll go into it a little more later.
>> Okay, so this is what the final app is going to do.
We are going to be welcomed to our site, we can view our to-do list.
Right now, it's empty, so we can add an item.
Let's say, "Go to CS50 seminar today."
Save item.
>> All right, so now we're seeing exactly what we just wrote.
It makes sense.
And then, we can edit it if we want, or we could just go back to do list,
and now we see the item is, "Go to CS50 today."
Or sorry, to make it a little clearer, we
could add a little break here, "Go to CS50 seminar," the text is today.
We can also delete this item, and now our to-do list is empty.
>> So again, pretty basic.
There are some, I'm not sure if this year there's a seminar on Bootstrap,
but if you want to make your site beautiful,
you can use things like HTML, CSS, and Bootstrap.
Definitely view those seminars if you're interested in making prettier apps,
but we're working on functionality today.
>> All right, so let's get started.
So, if you go to, again from this home page on GitHub,
you could say "list starting out," and this
will walk you through just the basic setting up your framework in Rails,
starting your server, and getting something to display on the screen.
>> So this is just the basic setup.
So, making a new Rails project is really easy.
All you have to do, since it's pre-installed on the IDE,
is type "Rails new" and then your project name.
And that's going to generate a whole bunch of folders.
>> As you can see, if I go to todo_list_starting_out,
we have, it can be kind of overwhelming, because there's just
a ton of stuff that just appears.
Luckily, you don't have to deal with too much of it.
Especially, when you're starting out just building basic web apps.
>> The main folder you'll be concerned with is this app folder.
And you can see in this app folder, we have a couple things
that already look familiar.
So, we have models, views, and controllers.
>> So you can guess where the different code for models, views, and controllers
are going to go, and it's probably going to be in the appropriate folders.
So, the first thing we want to do, is basically,
we just want to make something appear on the screen.
In this section, we just want to welcome someone comes to our home page,
just say hello.
>> So, the way you do that is, you can generate a controller really easily
in Rails.
Right now, we don't have any controllers.
Or, if you've just gone this far, you won't have any controllers.
If you go to your controllers folder, all
it will have is this application controller, which is just telling you,
you can do some base configuration in your application controller,
but it's not going to tell your app what to do if someone
clicks on a specific web page.
>> So, the way that you set that it up, is there
is a line you can run in Rails, which basically, just says,
generate a controller.
Make me a file that's going to help me perform the functionality that I
need on this website.
And, in this particular one, we're making a welcome controller,
because all it's going to do is welcome users to the page.
And so, you generally want to name your controller something that makes sense
for the functionality it's going to perform,
and within that welcome controller, we want to have an index action.
Now, if you remember from your server Problem Set, one
of the things you had to do, was check to see if a user went to a home page
without, so if they just went to a directory,
you had to check for index.html or index.php.
That's because, by convention, "home pages"
are called "index" in web development.
>> So, you can think of index.anything, really as a home page.
So we're going to say, we want to be able to handle requests
to this home page.
And we want to have an action within our controller that can deal with that.
So what does that look like.
>> Well, once you run this line of code, you're
going to get a welcome controller.
And, within that welcome controller, it defines a method index.
And that's all it does.
It just says it exists.
And that's because, we don't really need any fancy functionality when
the people want to go to our home page, we just want to show them the page.
>> So, we just need to tell our controller, "All right, this action exists.
This page exists.
Don't freak out when you get here and just show us
this index page," which is all well and good, except we
haven't made an index page yet.
>> So that goes to the next thing we have to do,
which is once you set up your controller in Step 3, you have to go to the views,
because, although you've told your app what
to do when they go to the index page, you haven't made an index page.
>> All of our views, like I said before, are going
to be stored in this views folder.
And, as you can see, we already have a welcome folder.
That was generated when we generated our controller.
>> It assumed you're probably going to want to show
people views with the various things you want to do in this controller.
So, we're going to make a folder for you that's related to this controller
that you made.
And it's going to be called "welcome" because your controller was
called welcome.
>> You can put in any pages you want here.
So, like I said, we want an index page.
We want a home page.
So, we can create this index page.
It won't be here originally when you first type this,
so you'll have to make it.
And you want it to be called index.html.erb
because that's kind the Rails way of saying, this is a Rails view page.
>> So instead of just index.html, the convention is index.html.erb.
And, you can put whatever you want on this home page.
Right now, all I've said is "Hello."
>> So that means, what happens, let's see this in action.
Let's stop our server from our final to-do list, go to our starting
out to-do list, and start the server again.
Maybe.
Let's see.
Here we go.
>> Okay.
So now our server should be running, and it's going to be serving us this basic,
just starting out page.
So, when we visit the home page remember, we've--
>> Oh, sorry.
There's one other important area that you
need to configure when you're starting out your Rails app.
So, we've told the controller what to expect
when we get passed this information.
But we haven't actually configured the routes of our web app yet.
>> So, basically, we need to make sure that the controller gets
passed the right information at the right time.
So, how does our web app even know that when we go to the home page,
it should tell the welcome controller to be okay with the index page,
and then trigger the index page?
>> Right now, if we went to our home page, our app
doesn't really know that it's supposed to talk
to the welcome controller at all.
So, the last thing, kind of important area
to edit when you're setting up an app is routes.
And that's in config, routes.rb.
>> So, I do have that correct in my directions
on this Getting Started page, so if you're following along with that,
that should be easily discovered.
>> So, the one thing we have to do, is we have to say,
when you first arrive at this page, this line will be commented out,
because there are a lot of comments.
Again, this is just part of when Rails gets generated,
it puts a whole bunch of stuff in here.
It has all this stuff commented out, because you probably
don't need it originally, but this is kind of stuff that a lot of people
tend to use.
>> So, you can delete all of this if you want,
but you'll find some of the things you might
want to uncomment at various points, just because they tend to be useful.
So, this is something that Rails just sets up for you.
>> So, this will be a line that's commented out, but you can uncomment.
And, what this line says is, all right, if the user goes to the root,
goes to our home page, we want to trigger the welcome controllers index
method.
And that's how this all ties together.
>> User goes to the home page.
In routes, you set it up so that will trigger the welcome controller, that
will go to welcome controller, which will then say, all right.
Index, I want to call index.html.erb and give that back to the user.
>> Seems kind of convoluted, but you'll start to see a kind of pattern of,
we have to do something with routes, we have to do something with controller,
we have to do something with the views.
And then later, we'll add in, okay, once we have all our routes,
views, controller, model, controller, views, controller, model, controller,
views.
>> So, that's kind of a pattern you'll start to see.
AUDIENCE 1: Can I ask a question?
SPEAKER: Yeah, go for it.
AUDIENCE 1: Two.
One, is that I noticed you restarted the server, after you
put in the index thing.
Does that mean every time you change some code, you need to restart it?
>> SPEAKER: So, it, often times, especially if you're just
kind of changing around views, you just need to refresh the page.
Sometimes, if you make some major change,
you'll need to restart the server.
Generally, if something isn't showing up that you think
it should, just restart the server and often it'll come up.
>> AUDIENCE 1: So, just restart it.
>> SPEAKER: Yeah, usually, yeah.
Basically, usually, I just restart the server if I run into some sort issue.
>> AUDIENCE 1: And, my second question is, it seems, as you said,
seems a pretty convoluted process to fix your index page.
Now, I assume there's a lot of things that makes it powerful and versatile,
but I haven't seen that part yet.
Will you explain a little bit?
>> AUDIENCE 2: Go ahead and reiterate his question.
>> SPEAKER: Oh, sorry.
So, the first question was, I restarted the server,
and why did I do that at that particular time?
The specific reason for that one is because I was actually
changing folders, and so I had to restart it for the correct app.
But usually, you just have to restart the server if you make big changes.
>> The second question is, this does seem really convoluted.
Why is it so complicated to make just a single web page appear
and where is the power of Rails?
>> So, basically, the power Rails is going to come
in one of the next things I'm going to show you, basically.
So, although this does seem convoluted, and especially compared to your Problem
Sets, it's actually a lot more convoluted
in almost any other framework.
CS50 has kind of taken care of a lot of this back end
for you, when they've generated the code for your CS50 Finance.
So, a lot of this has just gone under the hood in what you're working in,
because they wanted you guys to focus on model-view-controller,
just those aspects, because that is the base of web development.
And it's really important to understand that stuff and how it fits together.
>> However, there's a lot of stuff under the hood that
has to go in before you can even get to model-view-controller.
So, that's kind of what you're seeing here.
And really, if you look step-by-step at the directions,
it actually only is about four steps.
You have to generate the framework, so just type "rails new."
You have to generate a controller, you have to generate an index,
and then you have to create a route.
>> So it's really only editing four files.
And a lot of the set up is done for you.
So it also seems more convoluted, because it's taken a lot more
time, since I've tried to explain the various steps and why they happen.
So, if you think about it only as of those four steps,
it seems less convoluted.
And also, what I'm about to show you, is kind part
of the reason why people love Rails so much.
>> Okay, so let's just first see this page that we've worked so hard to create.
"Hello!"
All right, very underwhelming.
Okay, let's continue.
So, after the second part, after to-do list starting out,
is to-do list with items.
>> So, if it's going to-do list, it probably
needs some items in the to-do list.
So, the first thing we have to do, or one of the first things to do
is to make a series of routes, because you're probably
going to want a page where you can make new items.
>> You're probably going to want to page where you can see the individual items.
You're probably going to want a page where you can edit the items,
and then obviously, deleting is, you might not want a page for that,
but you're going to want to be able to click on something to delete items,
and have that information available.
>> So, this is a really useful thing that Rails does.
So, if we go into the next folder, which is with items, we can see in our routes
again.
Config, routes.
We've added something new.
So before, we just uncommented this root welcome index.
And that was again saying, if you go to the home page,
go to the welcome controller, go to the index page.
Now we have this three extra lines.
They look a little cryptic.
It's kind of unclear what they're doing.
But basically, this is creating a Rails resource.
>> And a resource is just a set of instructions and procedures
relating to a specific, sorry, let me rephrase this.
A resource is a set of procedures relating to some construct
that you'll want to have.
So in our case, it's items.
We want to have items; we want to do a bunch of things to them.
>> And so what this couple lines does, is it
says, we want to be able to have a bunch of paths
that we can go to do different things with our items.
And it creates all these paths for us.
So, one way of demonstrating that, is if we go --
let's stop our server so I can use the terminal-- rake routes.
What this command does, is it, I'm still in starting out.
>> But this is, we can start with this actually.
So, as you can see, this showed us that we have, we can go to our home page,
and that will trigger the welcome controllers index method,
but we can also go to welcome/index, and that will do the same thing.
>> So this is two different routes that you can type in,
in order to get to the same home page.
So this is showing us all are available routes in our starting out app.
Now, if we go to our new app that has items in it, so todo_list_with_items.
>> And then we run rake routes again.
So, to show us all the available route to the user can type in.
Now, we have a bunch more.
And all we've done is added those couple lines in our routes,
but now we can go to slash items from our root,
and we'll see index page the items controller.
Or, we'll trigger the index action in the items controller.
We have "new," we have "edit," we have "delete."
>> So, this has created a bunch of available routes.
Now, we haven't made our index controller yet,
so we haven't actually made any valid, we haven't made these actions valid.
But now we don't have to add a different line in our routes controller
for every single one of these actions, not in our routes controller,
in our routes file.
>> So the system generates this automatically for you.
All you have to do is edit your routes to rb.
Already, we're seeing one of the perks of Rails.
It does all this for us.
And now, all we have to do, like we did before,
is edit our controller so we can handle all of these different paths
that the user may want to take, and edit our views so that we have files
that the controller can call.
>> Okay.
Let's go to, We want to edit our controller.
Right.
That's exactly what I just said.
Or make a controller.
>> So, you'll see right now, I have a new controller called "items controller."
And I generated that very similarly to the way
that I generated the previous controller.
So, if you go through the instructions in Part Two, with items,
you'll see that after you edit the routes, you make a new controller.
And, if you remember the syntax from the previous example, great.
If not, fine.
>> bin/rails generate controller items.
This is a little different, because we didn't say index right after,
because we just want to generate a blank controller,
because we'll be doing a lot of configuration within this controller.
So we didn't want to preset index method in it just on the start,
but that's a pretty small difference.
Basically, it's exactly the same.
We're making a controller so that we can handle any requests to deal with items,
and that will also make a file in our views to deal with controllers,
or to deal with items.
>> Can I get a gauge?
How are people doing?
It's a lot of information.
Is a generally making sense?
Are there things that are just absolutely way too confusing
that I should go over?
The purpose of something?
Doing okay?
Okay.
All right.
We'll go on then.
All right.
We've made an items controller.
We want to deal with items.
What do we want to do with our items?
Well, we want to be able to make new items,
and want to be able to create items.
These seem kind of similar.
What's the difference?
>> Well, there are a couple different ways that you can channel information
into a controller.
One, is through GET requests, so through URLs.
And we already saw that.
We went to welcome/index, we got our welcome controllers index page.
That was information channeled to the controller through a GET request.
>> There also POST requests, though.
And that's if you submit a form online, there's
still information that sent back and forth to the controller,
but it doesn't necessarily go through the URL.
So there are a couple different things we can do with these items.
We need a page to go to where we can type
in the information we want for the new item in our to-do list,
but we also need to be able to handle, once we
click Enter, what happens with this information that we've typed in.
So that's kind of the general purpose of "new" and "create"
"New" tends to be a page that you'll visit.
It's information that gets passed to the controller through a URL.
So when you go to /new, your routes are set up to handle that as information
that will get passed to the items controller,
and then you'll kind of render a page that shows a form that the user can
type in information.
>> But then there's "create."
So once you type in your information and press Submit,
create tends to be the action that will actually
take that information that you've entered, and do something with it.
So that's the distinction between those two which can be originally confusing.
>> So, all of that our create method does right now,
is render, plane, params, item, inspect.
All that means, is take the information you got relating to item, this item
that we typed in information for, and we'll
show you how that works in a moment, and just show it to me.
So after you type in information on this new page
show me what you typed in on the next page.
>> And, we can see that in action.
Let me close some of these so it gets less cluttered.
Let's go.
Oh, we're in with items.
So let's start our server.
All right.
I've just gone to items/new.
This is telling, because of the way we set up our routes in config,
this path is set up to give information to the items controller.
And specifically, the new action within the items controller.
So, if you remember all that said, it was "def new end."
So that's just going to try and find new.html.erb,
the HTML page that relates to the action that we're looking for.
And I'll show you that page in a moment.
But as you can see it just says make a form, basically.
>> That's what that page does.
We can type in another thing.
So "new item" and "made today again."
We're going to save it, and we see all that our create action does
is print it out to the screen right now.
Eventually, in the next section, we're going to put into a database,
but for now, we can see we were able to take that information and handle it.
>> And so again, this is still kind of underwhelming,
but at least we now can kind of start dealing with data.
So, what does our new page look like?
What does the HTML look like on that page?
>> So again, you kind of expect that to be in views,
because it's dealing with information that
actually gets displayed on the screen.
And when we generated our items controller,
that made a handy folder for us in views that relates to items,
and I made this new.html.erb page.
>> So, this is another reason why Rails is awesome.
It's really easy to submit and transfer data dealing with resources
that you made in routes.
So, all we have to do, in order to tell the app that this
is information about our to-do list items, is say form_for: item.
That's it.
>> And then, we're just telling it what URL to direct
to after we're done submitting the form, and it's items_path.
And we can look at what that is in a second.
But for now, let's just go out to the form.
>> So, if you remember from when I was talking about Ruby for loops,
it was array.each do number, and then, every time we went through the loop,
it did something to, or it printed out the next number in the list.
>> This is similar syntax doing something slightly different.
It's saying, basically, all it's saying is, I want to relate this form to,
it's giving, right.
Let me rephrase again.
>> It's relating the form items, so these things we see to this form,
that we've made for item.
So it's just a way of kind of tying everything together.
I'm not going to go into it too much detail.
But basically, what we've done is we're saying,
for this form that we've made for this item, we want to have a title field,
and the label will be "title," and it'll be a text field.
>> And this, all that this syntax is doing, is kind of generating HTML.
You'll see it doesn't look like HTML, mostly because
of these kind of weird symbols on either end of the text.
And what that's saying is, we are going to want Ruby code,
or we're going to want HTML eventually, but we want
to use some Ruby to generate that HTML.
>> And so this is just sticking Ruby code into HTML.
So, we can see this is plain HTML, H1 new item close H1.
That looks familiar.
That's stuff we've seen in lecture.
We can see these p-tags that also look pretty familiar,
but the form itself, the HTML is mainly generated by Ruby code
that you've stuck in there.
>> And you can see, actually why don't we do this.
I think we can do this.
This may be small.
Yeah, this is probably too small, but what you can do on your own,
is you can inspect the HTML of a page by right-clicking,
and then clicking Inspect Element.
And you can see the actual HTML that our Ruby code built.
And you'll see there is a form tag, there is a label tag,
there's a bunch of, a text field tag, and so
you'll see of the results of this HTML that we created
using Ruby, which is kind of cool.
>> All right, and, I believe that's it, for just making a new item
and showing on the screen.
Any questions now, before we get into our last chunk,
which is dealing with databases?
No?
Okay, cool.
>> And as you saw again, it actually really only took a couple steps.
It took generating a controller, adding a "new" and "create" action,
so that the controller could deal with requests for items/new
and so that the controller could deal with information
that came in after submit of this data relating to our item.
And then, making the form.
>> So, pretty simple actually, even though again, it seems like a lot of steps.
>> AUDIENCE 1: Did you already create a model for items?
>> SPEAKER: No, so, we don't have a model yet.
Right now, all we have is this Rails construct, a resource,
that really can take any shape.
So, what we're about to do is make a model,
so that we can put this resource, an item,
into a database with a set structure.
>> So the way that creating models work in Rails,
let me go to the next, So to-do list with MVC see Part 3 of 3.
>> So the way you create a model in Rails is, again pretty easy,
it's kind of a one-line thing.
You say "rails generate model," similar to "rails generate controller."
You give it a name.
We're going to call it "Item."
And again, by convention, you usually capitalize and don't
pluralize the names of models.
You can call them whenever you want, but just by convention,
and so it makes your code more readable by others,
generally this is the convention.
>> And then, you tell it, basically, what columns
do you want in your database for this particular model.
So we're saying, we want a title column, and that's
going to hold strings, which, not surprisingly, is similar to the string
data type that you worked with that CS50 library implemented.
It's just a set of characters.
>> And we're going to have a notes column.
So, we're kind of items and then notes about those items.
And that's just going to be a bunch of text, so similar to string,
but just gives you more space.
>> So, you can think about this as setting up the structure of a database.
This hasn't actually made a table yet.
All this does is says, I'm going to make a file that's
going to basically be able to be made into a database
once you kind of confirm that everything's okay.
>> So, if you run this, it makes a file with a really long name.
It's going to be in the database folder, in the migrate folder,
and it's going to have a bunch of numbers,
and then say create-- this is a typo, it should be items--
but, it's going to look something like this.
This is the format that it'll look like.
So it's a bunch of numbers, and then create, and then
whatever your model name is.
>> And if we go to that file, it won't be in this one, it will be in MVC one.
If we go to that file, migrate, we can see
that this file is now set up to create a table with a string column called
"title" and a text column called "notes."
So we're all set up to make our database.
We haven't yet, but we're set up to do it.
And then, in order to make it, luckily, this is all set up for you on the IDEs,
but basically, Rails by default uses a database called SQLite.
Often, when you push to production mode you'll
want to switch to different databases, but for the sake of this final project,
and honestly, for small web apps in general, SQLite is fine.
>> And it has the word SQL in it, so, not surprisingly, it's
kind of similar to the MySQL databases you're using.
It's kind of a lighter version of it.
>> Another beauty of Ruby is that you don't actually
have to deal with any SQL whatsoever.
Ruby deals with all of those.
I think you've seen at this point "INSERT table at"
and you have a bunch of long SQL commands.
Ruby does that for you which is amazing.
Or sorry, not Ruby.
Rails does that for you, which is awesome.
So you don't have to deal with any SQL when you're dealing with Ruby.
>> So we have this file, which we don't need to edit,
because we already set it up when we said "rails generate controller"
and we gave it the types.
And now, we can create this database.
And the way you do that, is by running the command "rake db:migrate."
And that says, actually make this table, with these columns,
this set up, that I can now insert data into.
At this point, you've made your table, and it's
ready to be queried in any way you want.
So, not surprisingly, we have a database,
but we don't really know what to do with it.
Where do you think we go?
Which of our MVC tells us what we're going to do with information?
>> AUDIENCE 1: Controllers?
SPEAKER: Controllers, yeah.
So we're going to go back to our controller
in order to set up a way to actually put data into the database,
and take data out of the database.
And we don't have to make a new controller this time,
because this is all still dealing with our items, right?
We're putting items in, we're taking items out,
so it's still in our items controller.
>> And we can see, let's go to app, controllers, items controller.
>> Okay.
There are a lot of changes, but the important ones are,
we have a "show," which now accesses this Item model that we made.
So remember, we called our model Item with a capital I.
And this is basically taking care of the SQL command for you.
This is saying go to the database, get out an item with the specific ID
that I'm looking for.
>> And it knows which ID you're looking for by way
of passing data in through the "view" which I'll show you later.
And, also now, our "create" looks a little different.
We are now, again, dealing with a SQL command.
We're saying, "Put this new item into the database."
>> And, this is basically just for security reasons.
We have a private method that just kind of takes
care of making sure inserting and taking things out of the database
is done safely.
So, you don't really have to know too much about that,
but it's just a security thing.
>> And, we're going to save an item to the database,
and then redirect to the show page.
>> So this is a lot to take in.
I think I'm going to stop here, and pause, talk a little bit more
about, generally, the structure that we've seen, and a couple key takeaways.
And, I think that you'll find, if you follow
through the instructions on the GitHub page,
this was a lot of information thrown at you.
It's a whole new framework, but I think it really
boils down to a couple key steps.
>> Like I mentioned before, setting up the web app is four steps.
We went over them before, they're laid out pretty clearly
in the Getting Started page.
And basically, any action want to implement
is kind of, max, three or four steps.
>> You usually have to add some item into the controller
in order to tell the app how to handle a certain set of information that
gets passed to it, and you have to edit a view in order
to tell your web app what to do with that information
that it gets passed from the controller.
>> And then, dealing with the model, I think, again, there
are a couple of key syntax things.
Basically, the @items is kind of like a global variable.
You can pass it into your view, which is pretty cool.
So, if I go to my views for these things--
"for these things," that was very specific-- if I go to my view for,
let's say, "items index," you can see that I can access this items
variable if I use Ruby code.
So, what that did in the controller is, it says,
I want to make a global items variable.
>> And what I'm going to do with it, is this SQL command.
I'm going to go into my table, get all of the items,
and put them all into this items variable.
And then in my view, I'm going to use these items variable, which
just has a big list of all of the items, and this is the for loop syntax
we talked about earlier.
For each of them, I'm going to print out the title, and the notes about them.
So this is super convenient.
If you'll notice, a SQL command, two words, instead of, however many, 15.
And, a global variable, all you have to do is say, @items.
>> So, this is a really easy way of passing information back and forth
from the model, view, and controller.
You'll notice, all three of those, all three parts,
are accessed in these very simple three lines.
This is saying go to the model, or go to the database, get out data.
This is saying, pass it into the view.
>> So, I think that example is actually a pretty nice way
of demonstrating why Rails is so cool.
Three lines, we were able to access our database,
get information to our controller, and then pass it back to the view.
And again, you'll see a very similar theme
for all of the rest of the methods you might want to do.
>> You'll see of some reference to the database,
and the way of passing it into the view.
And, then the views are responsible for handling
that data in whatever way you want.
>> So in the final version, again, I've added a couple more fields
to this controller, which allow you to delete, and allow you to edit.
The edit looks pretty similar to create, because it makes sense,
you'll also want to be putting data back into the database,
like you do when you save a new item.
>> Delete is a little bit different, because like I
mentioned before, it doesn't have its home page that you visit in order
to delete an item.
That'd be kind of annoying, if you had to go to items/delete/ and then you
have to tell it which specific item to delete.
So, the delete procedure is slightly different,
but still follows the same general conventions.
>> It'll have some reference to the database, where it goes,
in order to find the correct information and delete it,
and it'll have some reference back to the view,
so that the view knows what to do.
>> So this is Ruby on Rails.
I would take a look at the GitHub, if you're interested.
There's a lot of really cool documentation setting up
users is really easy in Rails, compared to almost anything else.
There's a gem for it called "devise" that
takes care of a lot of authentication issues,
makes a bunch of pages and controllers in the background
that you just have to set up links to, and your sign-in sign-out functionality
is pretty much taken care of.
>> It has cool visualization features, it has really cool, basically everything.
So, I would highly recommend using it.
It's super popular these days, too.
Yeah.
If you have any questions, feel free to email me, or stick around,
I'll be here.
And thank you so much for coming.