[MUSIC PLAYING] STEPHEN TURBAN: So I'm Stephen Turban. Over on the side here, maybe we can get some people to dive in. We have Gabriel and Zack. So for a brief roadmap on what this is going to look like, I'm going to be doing some extremely high-level look at what MVC is. Gabe? GABRIEL GUIMARAES: I'm going to talk about Ruby and a little bit how Rails works and how it can help you build web applications. ZACK CHAUVIN: And I'm going to show you a specific example of how to use Rails to build a super awesome app. STEPHEN TURBAN: Awesome. Sweet. All right. So let's talk about MVC. So let's go to the next slide, which I will do by pressing this button. And let's go to the next-- development, I like to think about going to CVS, because CVS is a store and also has a V in the center. And so let's imagine to a store. And let's make this store sell only one thing. So we're going to have this store only sell these red cups. And imagine you walk in, and you go to the front of the store, and person. And his name is Vince. And Vince waves hello at you, says hi. And you notice one thing about Vince. So whenever we think about Vince, we have to think about two key adjectives. Vince is beautiful, but he's stupid. OK. So you know, no fault of his own, unfortunately, he's beautiful. He is our view. So our first cast member is there. Keep that in mind. Now, you ask Vince, you go, hey Vince. I'm a customer. He says hi. I really want one of your red cups. And what does Vince say? Does anyone have any idea what Vince says? I'm going to cold call. What do you think Vince says? AUDIENCE: He says, I can show you where it is, but I can't give you one. STEPHEN TURBAN: He says, I can show you where it is, but I can't give you one. Even worse. Anyone else have another idea what Vince might say? AUDIENCE: He has to go check if they have any red cups. STEPHEN TURBAN: Vince doesn't even know he has to check. Anything else? So you said, has to check if he has red cups. Go ahead. AUDIENCE: What's a red cup? STEPHEN TURBAN: What's a red cup? What's a red cup? Vince is confused. So Vince is going to talk to our next cast member, Carl. And when we think about Carl, we gotta think about two big adjectives-- he's controlling, but he's incapable. So Vince goes-- he goes, what is a red cup? I don't know what a red cup is. He turns around, and he asks Carl. He says, Carl, someone asked for a red cup. Can you do that? And what does Carl say? Let's figure it out. Does anybody have any idea what Carl says? And I'll just repeat it back to you. I saw a hand movement. AUDIENCE: He tells someone else to get the red cups. STEPHEN TURBAN: He tells someone else to get the red cup. Exactly. And do we have an idea who that person might be? It's a hint. It's going to start with an M. Mob? AUDIENCE: Model. STEPHEN TURBAN: The model, yes. His name is not Model, unfortunately, because that's a silly name. We have Mitt. And when we think about Mitt-- no, this is not a picture of Zack. We have to think of two key adjectives with Mitt. He's capable, but he's submissive. So Mitt knows what he has to do, but he really can't do anything. Or he really can't decide on his own. So we have Carl. Carl shouts at Mitt. And he says, hey Mitt, we need red cups. And Mitt goes to his red cup depository. He grabs a cup, and he gives it back. Does anybody have any idea what happens then? Gives the cup. So far Mitt has gone to his red cup repository, taken it out, checked it off, said, I took one red cup. And he's giving it to Carl. Do you have an idea? What do you think Carl does? AUDIENCE: Carl gives it to Vince. STEPHEN TURBAN: Carl gives it to Vince. Vince. AUDIENCE: And Vince shows it to [INAUDIBLE]. STEPHEN TURBAN: Exactly. So that's exactly it. So Vince takes the cup, doesn't even know what it is, but he shows it to the user. So let's try to recreate this really briefly. And we're gonna need three silent volunteers, as you guys are not going to be able to speak. So could I grab three? OK. And who would you like to be? AUDIENCE: I'll be Vince. STEPHEN TURBAN: Vince, OK. Beautiful but stupid. Great. Anyone else? We're looking for a capable but submissive. Anybody else want to be capable? AUDIENCE: I could be Carl. STEPHEN TURBAN: Sweet. We've got Carl. AUDIENCE: Mitt. STEPHEN TURBAN: Mitt, OK. And we're going to need a-- I'll be the customer. So come on up, come on up. And is everyone in view? So I'm going to ask Vince to stand in the front, just smiling, just smiling as bright as possible. And we're going to ask Carl, right, why don't you, like, stand right behind her? And Mitt, why don't you just go off in the back, and then I'll give you a group of cups to hang out with. So I'm a customer. I come. And I make [INAUDIBLE] I say, hi, I'd like a cup. Perfect. So Vince has no idea. So what does Vince do next? Vince-- OK, so I'm going to be narrating now. Vince shouts at Carl, cup! What does Carl do? Carl yells at Mitt. Mitt grabs a cup. Mitt gives it to Carl. Carl returns it to Vince. And Vince shows it to the user. And that is a high, high, high, so high look at MVC. We divide it by having a view, what the user sees, a controller, someone who does everything in the background but really can't update anything or can't do anything of any significance except calling the view and the model. And then we have Mitt, the model, who updates whatever data we have. So thank you so much for our beautiful, controlling, and capable volunteers. And I think that was it. [APPLAUSE] I think Gabe is going to talk now on a hopefully less high level. GABRIEL GUIMARAES: OK, guys. Now let's talk a little bit more about code and about Ruby on Rails itself, and about how it relates to all of this MVC story. Basically, Ruby on Rails is a framework. More about that in a second. But just to give you a sense of who's using it, like, all of these big companies-- so GitHub, Groupon, Twitter-- they're all using Ruby on Rails as their main framework to implement their website. So I'm sure a lot of people have used these websites here. And it's all Ruby on Rails to implement the model, the view, and the controller on all of these websites and many more. OK? So as I said, Ruby on Rails is a framework. And you can kind of think of a framework in the sense of like building a house. So if you're going to build a house-- and you can always start from scratch, right? You can try to come up with a way to saw the wood, and to bring the wood to the place, and to get the stones in the right shape, and then all of that. But that's going to take probably lots of years until you get all the material, and you get everything together, and you actually start to build your house. So it turns out if you start out with a framework with something that's already kind of in place for any type of house that you want to build-- something that's very generic but that you can then model towards your own goals-- then you can leverage this power of the frameworks to build them something much, much faster. OK. So this is the same idea in a framework for a web application or for any type of application, for that matter. You actually start out with half an application already there in place for you. And by that, I mean you get lots of files that already have functions, like libraries, like functionality, and commands that you can run in order to make your life much simpler and easier. OK. So in this case, we're going to talk about Ruby on Rails. There are lots of different frameworks out there. There's Django for Python. There's Zend framework or Laravel for PHP. There are lots of different ones. Ruby on Rails is a pretty nice new one. A lot of people use that in startups and this kind of environment. And some of these very big companies that I showed here before are also using Ruby on Rails. So just to give you a sense of what Ruby is like, since you guys are more used to, like, C and a little bit of PHP now, so Ruby is going to be the equivalent of your PHP in this sense. This is not Ruby. This is C. OK? But this is like the DJBHash function that I know many people used for PSET misspellings. And in Ruby, pretty much like in PHP, you could implement this with only a few lines of code. Instead of having to worry about the hash function, having to worry about the buckets, and all of that, you can just say, dictionary= Hash.net. And then you use kind of like the same idea that PHP had. And so it's to true. And then if you want to check, so check function would be if dictionary "foo" equals equals true, return true. And that's all, OK? So you notice a few differences. There are no semi-colons here, as there were in C. But the general idea is very similar. OK? Also, in Ruby, there are gems, which are kind of the Ruby libraries. And Rails handles them in a very nice way for you. So if you want to put in some library that does emails, or that does text messaging, or that does integration with Facebook, or any kind of thing like that for your app, it's very, very easy. Odds are you can find something like that on the internet. And they just do something like put which gem you want to use in the gem file. And then Rails installs everything. You don't have to worry about any of that, so that's really cool. Also, there's plenty, plenty of help online. So you can find lots of things. If you have an error, you can just Google it, and it's going to be very easy to get help. And it's a lot of fun-- exactly-- because you don't have to worry about the low-level details, implementation of hash tables and having to come up with all of the HTTP headers, and lots of things, and even some more higher level things. You don't have to worry about that in Rails. It does it very, very nicely for you. And we're going to show that more concretely very soon. OK. So a little bit about Ruby again. So it's just like C, as I said. Instead of printf, we say "puts," which is "put string." It puts a string to the console. And in this case, we're just printing "Hello World." We don't need the parentheses, but it's pretty much similar. And then if you want to do something here, like print a bunch of "smalls" and a bunch of "bigs" in a While loop, it's kind of like in C, right? You don't have the params, but it's pretty much the same. The indentation here counts, so x equals 1. And then While x is smaller than 50-- this is an If, this is an Else. It's pretty much like what you saw. And then x+= 1 is just incrementing, kind of like doing the ++ that you can do in C. But it's pretty much what you saw in C. It shouldn't be too complicated. But it is more powerful. So there are a few commands here that are definitely a bit newer. So for example, "puts." You can use this hashtag notation here to just print something-- pretty much like what you would do if the %D or %C or somewhat like that. And you can actually put an If right after the statement. So I only want to do this-- If x is greater than 3. So why would I have to make an entire If block? I don't know. I can just print this only if x equals greater than 3. So this is a one line way of doing this in Ruby. A list in Ruby is something very versatile. So you don't really need to have just one type. You can have a string, and then some numbers, and whatever. And if you want to append something to a list, you can just use this notation right here. And if you want to iterate. Pretty much the 4each in PHP, here, you have a list and you do "List.each do." And this "elem," this is like the name of each element that I'm going to have in my list. And then I can just "puts elem." And "puts" pretty much handles putting it for you, printing it. It doesn't matter if it's a string or an int. It's going to work that out for you. Right? Cool. And just like PHP, Ruby and HTML also integrate very, very nicely. And here, there's some HTML with Ruby in it. So we have a body tag like in HTML. And if we want to check that a user is, for example, logged in, we can just say, beginning of Ruby, if user.logged_in?, end of Ruby. Print this entire thing, which has some Ruby in it, which is just kind of like that syntax for PHP that prints out a variable. Let's print the user.name. So welcome, Stephen, inside of an HTML div. And at the end, we have an "end" and Ruby code, which means this is my If block. OK? So it's just like a seamless integration between Ruby and HTML. There are also lots of resources. But before we move on, does anybody have any questions about Ruby, anything? OK. There are lots of resources online to tryruby.org, Code Academy, ruby-lang.org, where you can try it out on your browser before you actually say, oh, OK, I'm going to use Ruby for my final project. And so definitely give those a try. All of these slides are going to be available online, so you can just download them. And yes? AUDIENCE: [INAUDIBLE] what you just showed was HTML and the code embedded into it to this notion of Model View Controller? GABRIEL GUIMARAES: Yes. We will do that in a second when we show our example, OK? Thanks for the question. So the question was basically if we can show this integration of Ruby in HTML within the Model View Controller framework. So the idea of the Model View Controller framework is it's basically a philosophy, just like Stephen showed here. And it's not something that you have to do, but it's something that makes your life so much simpler. And Ruby on Rails is built around this philosophy of code. So we're going to show an example very soon. So Rails is love. A lot of people are using it, as I said. And it's really fun. You guys should definitely give it a try. MVC makes everything simpler. So the Model View Controller, the separating things and putting one person, per se, or one part of your application to do each of the different jobs that you application has to do. And less time spent on low-level problems. And very popular right now. We have Rails 4.0, which is a new version. And it comes with a lot of cool stuff. Another question. AUDIENCE: Another question. Ruby on Rails versus Ruby on Rails Grails. GABRIEL GUIMARAES: OK. The question was, Ruby on Rails versus Ruby-- AUDIENCE: Grails. Ruby? GABRIEL GUIMARAES: Yeah. So Ruby is the language. AUDIENCE: No. I'm asking you to compare a language and a framework, Ruby on Rails, with another popular language framework-- Grails-- with Ruby on Rails. GABRIEL GUIMARAES: OK. Sorry. The question was, compare Ruby and Ruby on Rails to another framework and another-- AUDIENCE: Ruby. It's OK. If you don't know about it, that's fine. GABRIEL GUIMARAES: Like, what I understand is that-- AUDIENCE: There's another framework called Grails. GABRIEL GUIMARAES: Oh, Grails. I never heard of it. Sorry. I never heard of Groovy on Rails. Sorry. AUDIENCE: It's much better integrated with Java. GABRIEL GUIMARAES: I see. AUDIENCE: I'm just curious about some people I know like-- GABRIEL GUIMARAES: No, I never heard of that one, unfortunately. Grails. AUDIENCE: And some people obviously like Ruby on Rails. GABRIEL GUIMARAES: I've used Ruby on Rails a lot. I've used some Django with Python, as I said. I've used some Laravel. But I hadn't used Groovy on Rails. Sorry. And it's very popular now with Rails 4.0. Like, some of the stuff that Rails does for you, for example, is you have lots of CSS files and lots of JavaScript files. And you can treat them as separate and everything. But then it automatically-- when you send your code to production, it automatically compiles them all into one single file that's minified without any spaces, so that it takes up less space in your application, so that you can really scale things a lot. That's why such big companies like Twitter and GitHub are using Rails, because it does all that for you, which is really cool. One thing that is very, very, very daunting for people, including me, who are trying to work with a framework at the beginning, is that when you start out an application, you're going to see a bunch of files. Like, when you create Rails New, My Application, you're going to see all of these folders-- app, bin, config, db, lib, log, public. Like, lots and lots of stuff. And the first time I saw that, I was like, OK, I have no idea what's going on. I just want to create a website with "Hello, world," and this is giving me, like, 100 billion different pages. I don't know what's going on. So please do not be too daunted by that. The idea is that it actually has half of a house there for you already. It has an entire framework for you already. That's why there are so many files. But the nice thing is that it separates all of them very nicely. Odds are you don't have to worry about most of these folders. The most important one, I would say, is the app folder, where your app actually lives. So the config, you're going to have to configurate some stuff, like your database and things like which kind of database you're using. But other than that, like most of your work is going to be done in app. So in app, you have assets, controllers, helpers, mailers, models, views. So here, you start seeing that controllers, models, and views come into play. Mailers are just if you want to send emails. Helpers if you want to create some functions that you use a lot in the view. So you put them in helpers. And assets is basically all of your images, all of your CSS, all of your JavaScript, and like those kinds of things that get sent to the client. And everything that's in the assets, that I said before, gets minified. It's compiled. And you don't really have to worry about that when it goes to production code. Cool. Now Zack's going to come in, and he's going to do an example of Twitter50. AUDIENCE: Woo-hoo! ZACK CHAUVIN: Awesome. So I had the chance to work with Ruby on Rails this summer. It's an amazing framework. I'm very partial to it. And I'll just show you a little bit of an example of what it could look like. Jump over to Chrome. So this is an example of a very simple Ruby on Rails application-- something like this is something that Ruby really excels that-- just where your models are very well-defined. In this example, you'll see two different models, which are that we have users and we have tweets. So this is Twitter50, Harvard's own Twitter. As you can see, I'm logged in as @zack. And I'm able to make new tweets. So I think-- "This is an"-- sorry? AUDIENCE: [INAUDIBLE]. ZACK CHAUVIN: Oh, OK. Need to stop the server. Excellent. So here we are. As you can see, we have our Twitter application right here. And it's super easy to start the server. We'll just do "rails server." Great. OK. Thanks for that. So now we're running. And we'll say, "This is an awesome seminar." And let's see what happens. So we'll tweet about it. Down at the bottom, you can see now there's more than three tweets. So we have a little bit of pagination going on. And we have that tweet. And I can also search through my tweets-- search for this and the two ones that have the word "this" in them show up. We can also delete tweets by clicking on the little Delete button. And obviously, I can only delete the post that belonged to me. Already, we almost have the functionality of Twitter. Like, when you think about it, Twitter really doesn't do all that much. It has users, it has tweets. There's some more complex functionality. But when you really get down to it, it's quite a simple Ruby on Rails app. And something like this, with a good understanding of Ruby on Rails, you could probably make in an hour or two. And that really comes back to the Ruby mantra, which is convention over configuration. So back in the day, people, anytime they wanted to make this website, would have to start from scratch. OK, I want to make a website. Let's make this file and this file and this file. With Ruby on Rails, there's none of that. You say, I want a new app. And just like Gabe showed us, it creates the whole file structure for us. And we just change the little parts that we need to. We just customize what is unique about our app. Cool. So going back to our presentation preview-- interesting. Where do I present? AUDIENCE: Full screen. Top right. ZACK CHAUVIN: Excellent. Cool. OK. So first of all, the model. Stephen did an awesome job of outlining MVC. And now we're going to relate that back to Ruby on Rails. So the model you can kind of think of as the database. You've been seeing this in CS50 Finance, where the model stores the information about how many stocks you have, or all the transactions that you made. This is an example of a line of how you would go about making a new model in Rails. So I want a user. It's going to have an email, which is a string, and a password, which is also the string. So it's like those-- I want each row in my table of users to look like that. A really awesome part about Rails is that it makes it unnecessary to write any SQL pretty much. How many of you guys loved writing SQL in PSET 7? Exactly. SQL is not very user-friendly. And Rails abstracts all that away with these really easy commands. So for example, if we have a user, a user has many tweets. And each one of those tweets belongs to a user. So if you look here, this is our model for our tweet. And all we have to say is this single line-- I'm a tweet and I belong to a user. And with that single line and a little bit of database configuration, Rails sets up this relationship. Anytime, I can just say, zack.tweets, like, give me all of Zack tweets. No SQL. Super easy. Again, that's convention over configuration coming into play. You can see a little bit of an example of Ruby here. Like Gave said, writing Ruby is sort of like writing English. It's a very high-level language, and it makes it really easy for us to say things like, I want to make sure that this tweet has a body. Its presence is true. And I want to make sure that this tweet, just like normal Twitter, has a max length of 140. It's super-intuitive, a really great language. Next up we have the view. So this involves HTML and CSS. And here's an example of a view. So Ruby on Rails kind of seamlessly integrates both Ruby and HTML in order to generate what we want on the page. So this is an example of our layout. So you can see some tags that you guys are used to, like HTML, body, all that good stuff. And right in here, though, we incorporate some Ruby by saying, if there's a message to display, then display the message in a div. So I won't get too much into that. But this is generally a page that gets rendered on-- and no matter what page you're on, this one gets rendered. So this is what gets included always. Cool. Another example of a view-- this is the one where it chose all the tweets. And some of this stuff might look pretty familiar. So for example, right here, we're looping through each of the tweets, and we're printing them out. So here is where we're printing out the body. And if the tweet's user-- here's a real example of no SQL is involved. I'm just asking, is this tweet's user the current user? Then show a link to delete it. It's super simple. The controller. So this is, again, the interface between the model and the view. It's the one that does the hard work of interacting-- being the middleman. It loads information for the view, which we'll see in a sec. And in order to interact with the model, it calls model methods, which are what you guys are familiar as functions. So for example, this is our tweet's controller. It might look a little daunting right now. But it is actually super intuitive once you start diving in. So for example, in our index, that's where we want to show all the tweets. And so this line basically just asks for all the tweets. And then we initialize both the new tweet-- so like if they want to create a new tweet on that page. And it asks what the current user is. And this is very akin to the render that you saw in PSET 7, where it's just kind of telling the view-- it's kind of, like, passing the variables that you're going to need in the view to the view. And there's a whole bunch of different methods that this tweet's controller can handle. But really, Rails does a great job of kind of dividing them into the different actions that your controller might do. Are there any questions about any of the MVC parts of Rails? Kind of just a breeze by. So you guys can check it out on your own. Awesome. We'll keep going. So installing Rails. Installing Rails might be, like, one of the more daunting parts of the whole Rails process, unfortunately. But obviously, all of us are around to help. And once it's on there, a lot of great resources, as Gabe mentioned, for getting started. Here are the links that you'll need in order to download Rails to get it installed on your machine. Obviously, it's available for both Windows and Mac and for the CS50 appliance. Questions about anything we've said? AUDIENCE: I would be interested in, actually-- so I know that downloading software is the biggest barrier. If there's enough interest to have a downloading mini session or something. ZACK CHAUVIN: Mm-hm. Yeah. That might be really helpful. If anyone's really gung-ho about using this for their project or in the future, then we'd definitely be happy to talk to you about that. Mm-hm. AUDIENCE: A related question to what I asked before. For those of you who have done other frameworks that are still trying to do the same thing, make it easier to build a website or a functionality, I think any sense of why we would be on Rails versus Zend or some of the other frameworks and languages. ZACK CHAUVIN: I'll just say my $0.02 about that. I love Ruby on Rails. I've had the chance to work in both PHP and Ruby on Rails. I much prefer Ruby on Rails because of Ruby. Definitely, that's a big part of it. Like, when you're choosing your framework, you also choose your language. Ruby is super accessible-- I think a much better language than PHP. But that's kind of personal preference. As well, another consideration is the community behind the framework that you're working with. Right now Ruby on Rails is really hot. There's tons of support behind it. You post something on Stack Overflow about a problem you're having in Ruby on Rails, and it's answered. Again, it's open source, which means that it's constantly being changed. There's tons of people that are really dedicated in order to making this a really awesome framework. So that's why I would choose Ruby on Rails. GABRIEL GUIMARAES: Yeah. I would say that the idea behind most frameworks you're going to find out there is very, very similar, right? So the Model View Controller, the fact that our controller's going to look like something like this-- each of the functions is like one of your pages, and it redirects you, and it initializes the variables. That's going to be the same thing for every framework that you see out there. And there's going to be the model. And you can do stuff like, "belongs to." So instead of doing the SQL version, you just, like, do, user.tweets, and you get everything. Everybody has that. Except in Ruby, you do user.tweets, and then some frameworks in PHP, you do user.getalltweets WHERE my PHP is not a problem. Like, it's a big line. It's the same thing, but it's a big line. So that's one of the main reasons of my preferences over Ruby. It's just I do exactly the same thing in other frameworks, it just takes me twice as long lines of code. OK? Any other questions? ZACK CHAUVIN: Something I'll mention quickly-- Gabe talked a little bit about gems. And that's a really great-- I mean, this is kind of common to all frameworks, that there's kind of a gem concept, which is like in my little example, I have login. Like, you can sign in, sign out. Like, that's actually kind of a complex process. It was handled a little bit for you in PSET 7. But I still don't fully know how to implement sign-in, sign-out. And that's because Ruby on Rails has tons of gems that do stuff like that for you. Again, convention over configuration. Everyone's going to be doing this sign-in, sign-out step. So why not just make a package, called Devise in this case, which is a gem. You just include it. And then there is some help online with how to use it. And you don't have to worry about anything like that. Attaching pictures to these things-- a gem for that. Like, anytime you're trying to do anything new, there's a gem for that. And you kind of just piece together these gems and build a really complex application very quickly. Cool. Any other questions? STEPHEN TURBAN: Woo-hoo. I don't think [INAUDIBLE]. GABRIEL GUIMARAES: OK. Thanks so much, guys. STEPHEN TURBAN: Buh-bye. ZACK CHAUVIN: Buh-bye. STEPHEN TURBAN: Woo-hoo. [APPLAUSE] Yay.