Coding 101 67 (Transcript)

Narrator: Net casts you love from people you trust. This is TWIT! Bandwidth for Coding 101 is provided by Cachefly at C-A-C-H-E-F-L-Y.com

Father Robert Ballecer: This episode of Coding 101 is brought to you by Digital Ocean.  Simple and fast cloud hosting built for developers.  Deploy an SSD cloud server in 55 seconds.  Try today for free.  Visit digitalocean.com and once you sign up, be sure to enter the promo code C101 in the billing section for a ten dollar credit.

And by Harry’s.  For guys that want a great shave experience for a fraction of what you’re paying now, go to harrys.com.  Get five dollars off your first purchase by entering the code C101 when you check out.

On this episode of Coding 101 interacting with persistent databases.  Hello, and welcome to Coding 101.  It’s the TWIT show where we let you into the wonderful world of the code warrior / code monkey.  I’m Father Robert Ballecer.

Lou Maresca:  And I’m Lou Maresca.

Fr. Robert:  And for the next 45-50, 60, maybe an hour or so, we’re going to be letting you in to some of the tricks of the trade by speaking to programmers themselves.  Lou, thank you very much for coming back, our super special normal co-host.  I really kind of miss your old title.

Lou:  Me too.

Fr. Robert:  Super special guest co-host kind of slips off the tongue.  Now, it’s my co-host Lou.

Lou:  Loving it here, man.  This is great.

Fr. Robert:  You may notice that Lou is back in studio.  This is magic.  In fact, he keeps coming back every week and he keeps wearing the same clothing.  It’s…

Lou:  It’s kind of a little expensive, I got to buy all these shirts.

Fr. Robert:  I know, right.  No.  Now we will be speaking with Carols Souza again, because he wanted to give us another module.  And this time it’s about how we deal with persistent data sets.  This, this is really were, especially web facing programming becomes useful, right, when you can interact with some sort of existing persistent, so you keep records of it, data set, it means that you can actually do real work.  Useful work.

Lou:  Right, especially large data sets.  Because most data sets are not small.  If you have a lot of data telemetry of different customers, data about items or that kind of thing, it’s usually large.  So understanding how to manipulate and use this is actually very valuable.

Fr. Robert:  Well, let’s talk a little bit about that, before we jump into our banter section.  When we talk about manipulating data sets, some people just think, “Oh, it’s like you open up a file,” right?  You got a database and you pull up records and you push in records, and that’s it.  But it’s actually far more complicated than that.  It’s not just opening a file and pulling up bits and pieces of data, there’s a logic that goes to properly manipulating a data set.

Lou:  Yea, I mean, you really have to understand the data and what you’re actually trying to look for.  So like, when you’re looking for data, like for instance a customer’s data, maybe you’re looking for what they like or what they bought before, you kind of, you’ve got to understand what you’re searching for and what you’re using to search that data for.  And so it’s kind of important for you to understand what the data is before you get going anywhere else.

Fr. Robert:  Right, right.  We’re going to be covering all of that in just a bit, but before we get there, Lou, I love the topic that you’ve chosen for the top of the show.  Because, you know, it’s something that I cover on a lot of my other shows, especially this week on Enterprise Tech, and that is this idea of threat modeling.  And it’s very important now.  Let me give you an example.  Not too long ago, I was substitute hosting for Leo Laporte on Security Now with Steve Gibson, and he brought up this mailbag exploit.  It was an Android module where the programmer had commented, “I made the variable x number of bytes because the value should never be bigger than that.”  And essentially what he did was, in a comment, he just told anyone who wanted to attack the module, oh I just need to make it x number of bytes plus one and now I’m in overflow.

Lou:  Exploit, yea.

Fr. Robert:  And you know, it’s that kind of stuff that I don’t think a lot of programmers actually think about when they’re writing the code.  And you need to now, right?

Lou:  Yea, I mean, it’s one of those things.  It’s not the most lustery, fun thing to do in the world, but it’s actually very important to understand that when you are building a piece of software, how you can determine what the threats might be on that piece of software.

Fr. Robert:  Well, how do we do that?  I mean, there’s a really good example, there’s the Heartbleed Bug that scared the heck out of everyone, and rightfully so, because it was, it was pretty major.  Now if you don’t remember it, we did cover it on Coding 101 and it was, it was a way of hitting a data set over and over again and essentially you would lie to it.  You would tell it that I want you to keep this secure connection open and I’m passing you a thousand bytes, but you actually only pass it one.  And then it’s passing you back 999 that you shouldn’t get.  And if you do that enough times, you could get random spots of memory which will include data that you shouldn’t have access to.  That’s the kind of thing that if someone had actually sat down and done the threat modeling, the threat analysis, they never would have allowed that to happen.  But how do you integrate that into your programming?  I mean, if I’m programming, I’m not naturally thinking, how is someone going to try to crack this?

Lou:  So normally part of the process that’s usually, it’s a separate, it’s a separate step in the process when you’re building a piece of software.  So like for some people they like to do it right in the beginning so they know exactly what they’re building, some people like to do it at the very end and some people like to do it at the end and after they shipped.  So there’s many different ways to do it.  But the one that you’re talking about though, from the Heartbleed perspective, is that’s called a fuzz test.  Which basically throwing a bunch of random inputs and data at some kind of piece of software and seeing how it reacts to that.  And so, what they were saying is, if they’d done more of that up front, they would have potentially found this Heartbleed issue.  So, that’s one of the important things about threat modeling, but there’s multiple steps with threat modeling.  The first step is find the tool.  Because if you don’t have a tool to do it, it’s very difficult.  You could probably go and find a piece of paper and start drawing it out, and be able to understand, but with the tool can do is actually point out threats that you don’t actually see.  So what you do, is you build out your piece of software for how it has many different boundaries, you can use tools like the Microsoft Threat Modeling tool.  There’s also Open Source ones called The Open Web Application Security Project or OWASP.  There’s many different tools that you can use that will allow you to build out this model, and you basically show how your application interacts with data or external services, and you build out boundaries.  And then the tool can actually determine some of the common threats that would come with those boundaries.

Fr. Robert:  Now we’ve talked about this incredibly minimally in Coding 101 when we talked about sanitizing inputs.  Which is basically, make sure that you’re getting in what you thought you were going to get it in.  And we’ve done a few modules that integrated that kind of programming.  But, when we start taking it into automated tools, as you said, they can start throwing attacks that we would never think about.  And yea, there’s the random, I’m going to throw a bunch of characters that you didn’t think you were going to get, or I’m going to lean on one key forever, these are the kinds of things we would see in the real world.  But what are the attacks that you wouldn’t naturally think of that an automated tool might do?

Lou:  So, I mean, an automated tool might determine, like for instance, if you exposed something that you shouldn’t have.  So like for instance, if you exposed some, what they call PII data about the customer.  You know, maybe a social security number or something.  The tool will actually determine that it has some, you know, internal machine heuristics that can determine the data that you’re exposing.  It can also determine, hey, you’re opening a port.  So there might be some other type of threats that come with that.  You’re not using HTTP, HTTPS, you’re using HTTP, so there’s other things you might have to do.  Maybe you have to encrypt the stream versus that kind of thing.  So, there’s lots of things that the tool can determine and give you automatic feedback from that.  But there’s also things that the tool can’t determine.

Fr. Robert:  Yea, that’s, see, that’s the other part, which is, most of these tools are available to everybody.  That’s the whole idea.  Get it out there so that people are programming better.  Ideally, you should be running threat assessment before you start programming, you should be running threat testing as you’re programming, and then run a full sweep when you’re done.  Which doesn’t always happen, as we know, but the problem is the attacker will have access to the same tools.  So, he or she just has to make sure that they do something that’s not detected by the tester.  So what do you do if that’s the case?

Lou:  So there’s always a secondary process, it’s called the manual analysis and test process.  So basically what you do is you come up with whether its fuzz tests or it’s just security based tests like, I enter in, you know, the social security number, is the tool, is it going to tell me, is it going to spit that back out.  Or, for instance, if I maybe, like maybe a middle type attack, like what data am I actually going to get out of this stream, that kind of thing.  So there’s a lot of things you can kind of go through, and it takes a little bit of experience, but the tool will actually help you along the way.  And there’s also a lot of great books out there that talk about, hey, this is a thing that tools can’t detect, but these are things that you kind of need to go test and verify from your software.  So you also have to understand the data you’re using, too, so like if you’re using customer specific data, or if you’re using just item data, that might not need to be as secure as customer specific data.  But, you know, you need to just understand what data you’re having before you can actually model it out and determine what test you need to run.

Fr. Robert:  As long as we’re talking about testing, I want to bring in something that we’re actually going to be speaking about in just a second when we get to Mr. Souza.  He talks about how Rails has a suite of automated tests that don’t necessarily look for threats.  They don’t look for exploits, but they will look for dependencies that you may have broken as you’re testing.  How do you mix that together with threat testing?  Because I would assume that as you’re going along the way, you have to test for both things.  You have to test for things that you broke, and you have to test for things that other people might break.

Lou:  Yes, there is a fine line between the two, because you can get to a point where you broke a dependency, and then you get some kind of a null reference in your code, and then your software breaks.  So there’s, to me that’s a threat, if you think about it, because then if somebody knows how to blow up your application by, you know, extruding that threat.  But, you know, most of the time they’re normally separate.  So they’re, yea, you have to do functional based verification testing and you have to understand how your application works, and then there is also are you, you know, leaving the door open for people to exploit your data, or exploit the customers’ information, that kind of thing.  So there’s kind of, they are two separate things, usually.

Fr. Robert:  It’s funny that we’re talking about this because it reminds me of a conversation I had at Google I/O a while back.  They, so much, so much kudos go to this man.  He was responsible for a massive bug.  And he came up and he talked about it.  And it was interesting because you could feel the hate.  There were a lot of people in that room that were like, “How could you be so stupid?”  And then he started explaining the process.  And he started to explain, “Hey, look, I used this testing tool and this testing tool.  And I used this verification tool.  And the reason why I did what I did is because this verification tool told me that this dependency was vulnerable, and I switched it so it wouldn’t be, and I didn’t realize that that would screw up this other package.”  But, you know, when you start to get these programs that are so complicated down so many levels, there’s really no amount of automation that’s going to fix that last step, right?  I mean, you could run a program in ten different analysis tools, and you’ll get a different read, a different answer for each one as to what you should fix.

Lou:  And there’s tools of all different levels, like you were saying.  There’s tools to analyze your code for syntax, there’s semantic analysis, there’s runtime analysis, there’s functional and automation tests, so you can determine.  So there’s lots of different layers, and if, you know, some things leak out.  That’s why there’s software bugs and there’s threats.  So, I mean, these tools are not going to help you along the way, but that’s where the experience comes in, so you’ve experienced this before, you’re going to have that problem later and you know what to look for, so, you know, that just comes with experience.

Fr. Robert:  Just keep programming.  I think at this point you just have to say, “Yea, I’m going to mess up at some point.  I’m going to mess up big.  I’m going to cause a vulnerability, but that’s part of learning.”

Lou:  That’s right.

Fr. Robert:  Now we do have a special guest here.  We’re going to be bringing in Carlos Souza from Code School.  He’s the man who is bringing us up to speed on Ruby and Ruby for Rails, or yea, Ruby on Rails.  Ruby for Rails?  We’ve been having a fun time with him for the last two weeks.  This time he is going to be dropping us in to the alteration, the management, the maintenance of persistent data sets.  But, before we go there, let’s go ahead and thank the first sponsor of Coding 101.

Fr. Robert:  Let me ask you a question.  Once you’re done with your programming, once you’ve got your killer app, your killer service, your killer whatever it may be, what do you do with it?  Well, in the old, old, old days you were responsible for setting it up.  Maybe it meant that you had to build your own server, or if you came in a little bit later, maybe you leased a server, rented a server, or rented part of a server in a rack, in a colo, where, who knows where.  That was the way we used to do things, but we’re, well, we’re a lot more advanced now.  Now we understand that you don’t need to build up your own servers.  You don’t need to build up your own meadow.  You don’t need to own your own data center or data closet, you can just can container-ize your app, your web service, your whatever it may be, and push it up into the cloud.  And if you’re going to push it up into the cloud, why not push it up into Digital Ocean?  Now what is Digital Ocean?  Digital Ocean is a way to take that service, that web site, that whatever it needs to be living on the internet, and turn it into a droplet.  Their servers allow you to rent time, rent space, rent bandwidth at incredible rates.  Now whether you’re an experienced code warrior, or just getting started, you need flexible, reliable and affordable hosting.  That’s what Digital Ocean give you with droplets, which are virtual private servers that can be customized quickly to host web sites, web apps, production application, personal projects, virtual desktops and almost anything else you can think of with full root access.  We’ve been using Digital Ocean in here for the last couple of months to play with applications that we think we want to deploy either in house or to the internet.  It’s a great way to test our programming, and maybe even open it up to members of the public so they can help by hammering it, to break it, to show us the exploits, so that we can make everything right before we go full public.  That’s exactly what Digital Ocean is for.  For everything, from the testing to full production.  Digital Ocean is built for developers, and it is used by over 400,000 of them, including us.  You can deploy and configure your droplets via a streamlined control panel or a simple API.  And you get to choose your own OS from Ubuntu, to Centos, to Debian and Fedora, or free BSD.  A one-click install allows you to quickly deploy apps like Jango, Docker, Drupal, Lamp, GitLab, MediaWiki, doT.js, WordPress, Ghost, ownCloud, Ruby on Rails and more.  All servers are built on hex core machines with dedicated ECC RAM and RAID SSD storage.  Service can have up to 20 CPUs, 64GB of memory, and 640GB of SSD storage.  They’re highly scalable to meet the demands of a rapidly growing application or business and auto-backups and snapshots let you easily clone, deploy or resize your droplets as you grow.  Now all of this means that you get great up-timing.  In fact, with their regionally distributed servers, you get 99.99% uptime, and you get full feature DNS management and, if you want, dedicated IPs.  They give you web console access with HTML 5, plus SSH, SFTP, and KVMVNC for virtual desktops.  They’ve also got an active community.  So if you’ve got questions about deploying your service the way that you want, you can just jump in there and ask.  Digital Ocean has incredibly affordable and straightforward pricing.  There’s no surprises.  You buy what you need and you get what you paid for.  Servers start at only $5.00/month.  And there’s hourly pricing available starting at less than a penny per hour.  But we’re going to make it so that you can get started today, and deploy an SSD cloud server for free.  That’s right, you’ve got nothing to lose.  Go ahead and get into the world of rapidly deployed apps now.  Visit digitalocean.com and create an account.  Once you confirm your e-mail and account information, go to the billing section and enter the promo code C101 for a free $10 credit.  That’s plenty to get started and explore what Digital Ocean can do.  That’s digitalocean.com, and once you sign up, enter the code C101 in the billing section for a $10 credit.  And we thank Digital Ocean for their support of Coding 101.

Fr. Robert:  Thank you, Lou, I’m Padre on the sky desk, and I have the honor, the privilege, the opportunity to speak with Mr. Carlos Souza from Code School.  Carlos, thank you for coming back and once again being our code warrior.

Carlos Souza:  Thank you for having me here, Padre.

Fr. Robert:  The last two weeks have been fascinating.  You took us over Ruby, and explained why it’s such a good programming language for programmers.  Then you showed us the start of Rails, and explained how you can use that framework to create web applications in practically no time at all.  And you can use the intuitive language of Ruby to make applications that make sense to you.  You also stressed the importance of making sure you follow the convention, making sure you understand what needs to be in the view, what needs to me in the model, what need to be in the controller.   What are you going to show to us today?

Carlos:  Today we’re going to take a look at interacting with a database in Rails, and see how easy that is.

Fr. Robert:  Fantastic, well, that’s the next natural step, because you’ve shown us a little bit about how to put data, input in, and how to take data out, but now we want to be able to interact with an existing data set, because of course, that’s pretty much how the internet works.

Carlos:  Yea, absolutely.  Persistent data set, right, we’re going to save stuff to the database and make it persist across requests and take user input as well.

Fr. Robert:  Alright, guide me through it.  What do I need to do?  What do I need to setup?  What are the things that I need in place before I start programming?

Carlos:  Right.  So, when we created our Rails application, one of the things it did was already set up our database and our database drivers, and all the communication we need to do.  In Rails by default, uses the database called SQLite, which is a simple text file that it uses in your file system to store the binary data of your database.  So it’s pretty much a lightweight database as the name implies.  And because we have all that installed, we can use Rails’ generators to create our models.  And these models are going to be different then the search term model that we created before because these are going to be active record models.  So, let’s actually create them so we can see how they look like, which is better, it’s easier to understand when you look at it. 

Fr. Robert:  Alright, let’s go.

Carlos:  So, we’re going to use a Rails generators here, and generator, you know, is something that Rails pretty much, it’s sort of a plug-in that Rails just uses to create stuff for us.  And we can either write the whole thing, “generator,” or a shortcut “g.”  So we’re going to use a generator for a scaffold.  And what the scaffold is going to do is going to take a couple of arguments, a couple of information that we give it, and it’s going to create the model for it, the views for it, the controllers for it, and the database schema for it.  So it’s going to create the whole stack for the CRUD operations.  Which means, it’s going to give us everything we need to create, read, update and delete records for this one specific thing that we are going to create.

Fr. Robert:  And it automatically sets up all my dependencies.

Carlos:  Yes.

Fr. Robert:  I love that, ok, nice.

Carlos:  So, right now, so our app is a reading list.  We’re going to need to be able to register to create books.  Books that we read, if we want to, you know, keep track of them.  So we’re going to create a scaffold for a book.  So our scaffold is going to be named Book.  And what our Book is going to have, for now, is a title, and a description.  And if we wanted to we could give this types, but since it’s so string, that’s the default type of, that Rails assumes, right.  So this is the command that we’re going to run, “rails generate scaffold Book title description.”  So let’s see the files that it’s going to create for us. 

Fr. Robert:  Whoa.

Carlos:  Right.  Yep, it created a bunch of stuff.  So, one thing, I’m not going to go through the whole thing, but the first thing that we need to see is this file right here, the second line in our output that says “db/migrate” and then the timestamp and then “create books.”  This is the file that will be used by Rails to interact with the database and create the books table for us.  So we don’t have to write any SQL statements if we want to create the schema on the database, right?  So let’s look at this file and see what it looks like.  So it’s just a Ruby file.  It’s just Ruby syntax that Rails converts to SQL.  So let’s go ahead and create our database now.  So we’re going to use the rake command, which is sort of the Ruby version of make.  And we’re going to run this rake task, which is built into Rails.  Which is going to create our tables, our books table in the database.  So you can see, it printed out the message, “books created.”  So now we have, let me fire up the server, so you can see.  So Rails server, same command we ran before, start our rail server here.  And we can access /books and see that our page is there.  We didn’t create this.  Rails created this for us, so because we said it was a book scaffold, it followed all the conventions for creating the CRUD, views, model and controller and actions for that specific scaffold.  So if we click New Book, we’re given a form.

Fr. Robert:  Nice.

Carlos:  Yep, so, Harry Potter, J.K. Rowling.

Fr. Robert:  And this was all automatic.

Carlos:  Yea, and this was all automatic.  Yep, it’s all there for us.  So we have the listing here, and if we want to see the info, we click here, we have info, if we want to edit it.  Go back, if you want to destroy, and look at this, this is really cool.  So if you want to destroy, it automatically gives us the prompt, right?  So that’s another web application best practice, right, every time you’re face with a destructive action, you want to make sure that the user’s sure that they wants to do that, right? 

Fr. Robert:  Can we look at the model for this?  I mean, what did they put in there?

Carlos:  Yea, yea, let’s look at the model.  Let’s go back to here, and are you ready for this?  The model might blow your mind.

Fr. Robert:  Uh oh.

Carlos:  This is it.

Fr. Robert:  No! (Laughing)

Carlos:  There’s nothing in there.

Fr. Robert:  Carlos, how is it doing this?  Where is the black magic coming from?

Carlos:  The black magic is coming from the fact that this class, it’s just a Ruby class, first, right?  There’s a class book.  But it inherits from active record base.  So active record base knows how to read stuff from the database, so it basically uses again convention, looks up the name of the class, which is book, then based on the Rails convention, it pluralizes the name of that class.  So books.  And it looks for a database named books.  I’m sorry, a database table named books.  So once it finds that table, it uses a SQL command to get the names of the columns on that table.  Once it gets the names of the columns on that table, in runtime it creates getters and setters, remember that we saw on a previous episode?

Fr. Robert:  Right.

Carlos:  It creates getters and setters in runtime on the book class, right?  Because it’s able to reopen the class, remember again?  Because we can change classes every now and then in Ruby, either a custom class or existing classes?  So it changes the behavior of this class after it’s been, ever after it’s been created.  So it does all of that in runtime.

Fr. Robert:  Cool Breeze in the chatroom is saying, well, he’s kind of blown away by what he just saw, but he said, “With all this inheritance, commenting must be uber important.”  Because with so much of the code be taken from someplace else, you really need to tell people what you want it to do with it.

Carlos:  Right, but this is, this is a, like what we’ve seen so far, this is typical Rails applications.  So, we don’t really need to comment, you know, the columns or the other stuff.  If you want to know what the columns are, you can look at, for example, this file, schema.rb, which is a Ruby definition of what our database looks like. 

Fr. Robert:  That’s amazing, that is so much of the heavy lifting that’s done automatically, because now all I need to do is, I need to make my interface look the way I want it to, I need to change the business logic so that it does what I actually want it to do, but the heavy lifting of interfacing with a database, and having some sort of input and output, that’s done without me really pushing anything.

Carlos:  Yup.

Fr. Robert:  Ok.

Carlos:  Absolutely.

Fr. Robert:  Well, ok, that’s the end of this episode, thank you very much, Carlos (laughing).

Carlos:  That’s all we need to know about Rails.

Fr. Robert:  That’s it, we’re done!  We just created, it automatically makes your applications, that’s all you need to know.  Ok, as if!  Ok, now, now that we know that Rails is going to give us such a ridiculous advantage, where do I take it from here?

Carlos:  Ok.  I’m going to show you another very cool feature of Rails.  So remember the IRB, which is the interactive Ruby console that we fired up to try out Ruby commands?  So it turns out Rails has a similar thing that will actually boot your application, and will give you a console that you can interact with.  So it’s very useful if you want to test stuff without going through the web interface.  And by stuff, I usually mean models, right, so if you want to create a book model, if you want to search for books, and we use this a lot in code school and in other client applications that I’ve worked with.  Sometimes you need to look stuff up in a production environment, and instead of having an admin interface and going through the web interface, you can log into the server, and fire up a Rails console.  Which is what I’m going to do right now.

Fr. Robert:  Ok.

Carlos:  So, from our terminal, we’re going to type “rails console” or the shortcut, “rails c.”  So that loaded our Rails application and gave us a console.  So now we can use our model Book and call active record methods on it that will interact with the database.  So if we type book.all that’s going to fetch all the books that we have in the database.  So we just deleted that one book, I, so now we don’t have anything.  But, if we want to create a book for an example, we can do book.new.  Assign that to a variable.  So you can see we created an object.  The object is not persistent, so you can see the id’s still nil, right?  Well, let’s go ahead and add a title, right.  And the title of this book is going to be The Gunslinger, right.  And book, I’m going to give it a description, and say a sci-fi novel.  And then I’m going to save this.  So, you can see the SQL statement that calling book.save generated.  So I did book.save.  What Rails did was generate insert into books and then the columns, and then the values, and then it ran all the SQL for us.  And then at the bottom it returned true.  So now if we do book.all, you can see that book is there.

Fr. Robert:  Right, ok.

Carlos:  Right?  And this is the Rails console.  But now let’s go back to our interface, and see if the book is really there.  So, this is the last page that we saw.  I’m going to refresh this.  And you can see that the book is there.  Right?  So, the Rails console is literally one of the two ways, sort of, that we can interact with Rails.  We can either go through the web interface, or we can fire up the console and interact with our Rails application through there, right?  And a couple of other interesting methods that, and again, this is, we get this for free, and our book model is still empty.  All it does is inherit if from active record base.  So we can call methods like book.find and pass the idea of the book, so we can see the ID for this book is 2.  So if we do book.find(2) and again, you can omit the parenths if you like, my personal preference is to always include it.  So book.find will generate a select command with the ID, or, if you had other books.  So let’s go ahead and create another book.  So now instead of doing new, I’m going to do create.  So title, Harry Potter, description, a wizard.  So, I’m not doing new, I’m doing straight up create.  I run this command, it will automatically generate the insert statement, and also, another thing you can notice here, it ran our SQL statement within a transaction.  So it began a transaction here at the top, ran our insert statements, and committed the transaction down at the bottom.  If you’ve worked with other database systems, you know how important transactions can be.

Fr. Robert:  Oh yea, right.

Carlos:  Right?  They guarantee the integrity of your data.  So if you’re running, say, ten different statements and one of them error out, if your inside of a transaction it’s going to roll back, and leave your database in the same state that is was before those operations ran.  So this is one of those things that Rails gives you for free. 

Fr. Robert:  Ok.

Carlos:  Right?  Now, if we list all the books that we have, we have our book with ID 2 and our book with ID 3.  Say we want to see which is our first book.  What we do, we call book.first.  So it’s going to generate a query as you can see here, it generates a SQL statement and uses stuff like sorting ascending, and then limits the records to one.  And it returned a single record, the first book that we created.

Fr. Robert:  And the book.first comes from one of the inherited classes?

Carlos:  Yes, exactly.  Again, this is our model.  Still empty.  If we go book.last, you can see it generated the SQL, but instead of using ascending, ASC it’s using descending, DESC.

Fr. Robert:  Gosh, that’s fantastic.

Carlos:  The last record in the database, which in this case is Harry Potter.

Fr. Robert:  You’ve just made anyone who’s ever had to slave over playing with SQL very, very happy.

Carlos:  Yes, yes.  Again, it doesn’t do everything that you need, but 80% of what most web applications need, Rails gives you out of the box.

Fr. Robert:  Right.  Now, ok, here’s a question that we always pose, when we start getting about halfway through any module.  And that is, how do I validate inputs?  How do I make sure that what’s coming, especially what’s coming into my database, is what I want to be coming into my database?  What are the particular tricks in Ruby and Rails that I can use to make sure that my inputs are sanitized?

Carlos:  That’s a great question.  That is the logical next step, right?  Now that we’ve created a way for user, for users to interact in our application and insert stuff into our database, we need to make sure that the stuff that we allow them to insert is valid data, according to our business rules.  So, suppose that we wanted to create a new book, right, so now we can simply call create empty.  And as you’ll see, it’s going to create another record in the database, right?  We don’t want to do that, right?  And so let’s add a validation to make sure that we have at least the title of the book, right?  So let’s go back to our model and actually start writing logic in there.

Fr. Robert:  Ok.

Carlos:  So, if we wanted to validate for the title, and we wanted to make sure that a title would always be present.  So, we want to validate for the presence of the title property in our model which eventually is the title attribute in the database.  So we go into our model, and we write validates_presense_of :title.  That’s all we need to do.

Fr. Robert:  That just made me very happy.

Carlos:  If we go back to our console, and I’m going to reload because we changed the code, now if we do book.create, notice it rolled back the transaction, because it errored out, right, because now we have a validation.  So let’s take another look at what this is.  So now I’m going to create a new book, and I’m going to ask if this book record is valid.  Nope, it’s not valid.  So if we want to know what the errors are we can call errors.  And it’s going to give us an errors object.  And as you can see here at the bottom, it’s saying title can’t be blank.  There’s a better, another method we can call to get a better, a better message description.  Now it says, title can’t be blank, right?  Now let me show you what that looks like from the web.  So, just to recap, this is all we did.  This is all the code that we changed since we ran the scaffold.  Now, I’m going to go back to my web view, try to create a new book.  I’m not going to fill out anything.  So this is supposed to be a button, I don’t know why it’s, oh because.  Right, the size was super big.  So I’m not going to add anything and try to create a book.  Boom.  Validation’s there with the styles.  So it give us a big, red color saying something went wrong, right?  And it’s telling us exactly what’s happening.  It’s saying that 1 error prohibited this action from happening.  And it’s giving a description of that error, saying the title can’t be blank.  And it’s pointing us to the element in the form that has an error attached to it, which is the title.

Fr. Robert:  What was the name of this class again?  This class that you’re using to validate?

Carlos:  The class that I’m using to validate?

Fr. Robert:  If you go back to the, the code, there we go.  Oh, validates presence of.  Ok, so does that only check for blank, for null entries, or does that have anything else in there?

Carlos:  It just checks for blanks, presence.

Fr. Robert:  Ok, alright.

Carlos:  There’s other validations.  Rails.validations. Right, active record validations, it has a bunch of validates that you can use.  You can check for, format, length, numericality, presence, absence, uniqueness, you can add your custom validations, endless possibilities.  This is the most, one of the most simplest ones, and usually the first one that you start off with, right, when you want to make sure that blank data is not inserted into your database.  Now, just to note, this is at the application level.  This is at the Rails level, right?  If you want to fire up a SQL, a console, and generate an insert statement with null data, you’re still going to name it insert null data in your database, right?  So if you really want to be paranoid about it, or you know, maybe just as a good practice, good database practice, you might also want to create a constraint for your database.  Maybe a null constraint or something like that, right?  But think of, think of it this way.  Rails is a perfect tool to get you started and also in the long run, but it’s great at validating ideas, right?  So a lot of this stuff that you might do within the first couple of weeks or couple of months in your Rails app, especially if this is a start-up application, might need to change right after you do it, right, because it’s all about customer validation.  It’s all about pushing features in the most sane way, but in the most, in the fastest way to the market.  So you can test your assumptions and validate your ideas, right?  So, if you push stuff and you realize that’s going to stay for the long run, for example, if you wanted to validate a field like that, we would be able to push this to production, and you know, in less than a minute, right?  And if we realize that this is something that would really stay there, we could refactor it, and one of the ways that we could refactor it could be to dive down into the database level and add database constraints like I mentioned.  Because all of this that we’re doing is at the Rails application level.

Fr. Robert:  I’m looking at the validation helpers here on the Rails guide, and that’s pretty much everything I’d want to check for.  I could think of a few custom situations, but, yea, absence, presence, length, inclusion, numericality, those are the big ones.  And you’re right, if I needed to get an application out, this would give me that 80% of protection right off the bat.  That’s… ok, very happy.

Carlos:  Absolutely.

Fr. Robert:  Nice.  Ok, so now we have access to the database, we have a way to sanitize our inputs, what else do they need to know at this level?  Now that they are really interacting with a static data set, is there any super-secret sauce that you think they should have before they head into the homework?

Carlos:  One last thing that I wanted to mention, is show how Rails makes it easy for you to start testing your application.

Fr. Robert:  Yes, please.

Carlos:  The main reason that drove me to Rails.  That’s how I discovered Rails.  At the time I was programming in a different language, and I found out about this thing called unit testing.  And I wanted to see who out there was doing it.  And at the time, Rails was the only framework that offered you unit testing out of the box, right?  So what does unit testing look like?  So when we created our applications, our Rails application, Rails created this test folder for us.  And a bunch of sub-folders under it.  So, there’s sub-folders for controllers, fixtures, helpers, integration, mailers and models.  What we want to look at here is the unit tests, so test for models.  So we’re going to go into our test/models/, and you can see again, Rails already created for us a book test file.  When this happened was when we created the book scaffold.  So the scaffold created the models, the model, the views, the controller and also the test file for it.  So let’s jump into this file right here, and it gives us, again, just like it did with browse, it gives us a couple of comments, a couple of documentations that we can, we can look at and see how to start writing our tests.  So I’m just going remove this, and start writing test “invalid without title” do.  And then I’m going to create a new book and I’m going to be very explicit about the title being nil.  Then I’m going to call this insertion method called refute.  And I’m going to refute that the book is valid.  And then I’m going to go ahead and set a title to it.  And then I am going to assert that the book is valid.  So basically, I’m saying that in this line, valid has to return false.  And in this line, valid has to return true.  So, to run this test, we again use our rake task, test:models.  So when we run this, it’s going to run our tests, and say 1 run, 2 assertions, which was the refute and our insert methods, and 0 failures, right?  Let’s go ahead and make this color now.  Let’s add this, minitest/pride.  I just want the output to be colored so we can see.  So I’ll run this guy again, and now I can see that it’s a fabulous run.  So, yea, that’s what it did.  So where this helps us is that, think when our application grows, and we start having dozens of models with very complex business logic.  Every time we make a change in one piece of our code, it’s extremely important that we have a way, a fast and quick way, to insure that we didn’t break anything else in our application.  The easiest way to do that is with automated tests.  So, suppose that we were changing our book model, and for some reason, we, let’s say we misspelled this, right?  Let’s say I typed the wrong key, and then, and you know, this is what title is now.  So, I mean, we’re not running our whole application, and, you know, the work flow and testing it in the lab to figure out that this breaks.  So maybe all we need to do is rake test:models, and boom, it broke.  So as soon as we see this line, we know that we did something wrong with our application.  And it’s saying, hey, this is an undefined method for the book.  And you’re like, whoa, this is undefined, this looks like it was supposed to be called title.  So we go ahead, and fix this, run our test again, and now we know that we’re good, and we’re confident to push this application to production knowing that we didn’t break anything else.

Fr. Robert:  So for typical Rails programmers, you’re going to be testing all the time, right?  I mean basically, every time you make a change, you want to test it.

Carlos:  Yes, and I would say this is not just for Rails programmers.  I would say for pretty much every other type of programming out there, pretty every language, every framework, today has some sort of testing strategy around it. 

Fr. Robert:  Except Rails is automatic and it’s included, which is kind of nice.  What is in the test?  What kinds of situations is it throwing at your code?

Carlos:  I’m sorry, I’m not sure I understand.

Fr. Robert:  So, when you run the test, and it’s looking through, and looking for exceptions, looking for errors, what exactly is it looking for?  What’s it testing against?

Carlos:  So it’s just testing against what we wrote, right?  It’s not, it doesn’t, it doesn’t, so Rails does, it doesn’t like automatically create tests for you, it just gives you a structure that you can follow and a testing framework and methods that you can use to be able to write tests fast.  In other frameworks I would have to setup my whole testing strategy.  But Rails does this all for us, because it wants us to write tests.  It understands how important it is to write tests.  So it makes us easy for us to do that.  So what Rails is doing, what it’s testing for here, is literally what we tell it to test to, right?  So in this case it’s testing to make sure that valid returns false when the title is nil, but the valid returns true when we set something to title, right?

Fr. Robert:  Right.  Fantastic.  Carlos, again, thank you so very much.  We’ve reached the end of our time for this particular segment.  Now, in the next segment, which is the last one of our Ruby / Rails module, I think we have to take it to production, right?  Because everything that we’ve done so far has been sort of in house.  We want to show people how they’re actually going to take their application and make it live.

Carlos:  Absolutely.  The last step is ship this to production and profit.

Fr. Robert:  (laughing) well, profit, sometimes yes, hopefully.  But of course, we want to make sure that they’re doing their homework, so what are you going to send them away with today?

Carlos:  Nice.  So to make sure that you understand everything we went through here, I want to recommend that you at home try to build a scaffold for a genre.  So books have genres. So try to create a scaffold in CRUD for creating genres.  And the only attribute really that we need is a name.  But, we need to make sure that this name is present.

Fr. Robert:  Ok, and actually, he gave you all those steps, so if you have trouble, just re-watch.  Of course we’re going to make sure that you get the code that you saw, all the assets will be available to you.  We’re also going to make sure that you get linked up to Carlos’ GitHub, which has not just this, but it has everything.  Everything you can imagine for Ruby and Rails is in his GitHub, you got to check it out.  Carlos, we, of course, you’re from code school, and code school, we’ve talked about, is a great place to go if you are interested in doing any sort of web development, web applications, you got to drop by, because, well, it’s a great repository of knowledge and last time you showed us, what is it, Rails for Zombies?  Which is a gamification of, no, was it Ruby or Rails for Zombies, I can’t remember?

Carlos:  It’s Rails for Zombies.

Fr. Robert:  Yea, it’s a fantastic way to get some basic knowledge, and to have fun.  Could you tell them a little bit about where they find you, where they find your offerings, and where they find your programming?

Carlos:  Yea, absolutely.  I can mention my GitHub page.  GitHub.com/caike has a bunch of projects that I work on, and a bunch of contributions that I make to the open source community.  And also there is my Twitter, which is the same handle as my GitHub which is /caike, that’s where I post stuff mostly related to software development, cool links and I want to mention again, Rails for Zombies.  If you want to try out Rails, try out a couple of the things that we, actually a couple of things that we did on this episode.  So you can see here the lesson that I have up is create a new zombie.  So if you do zombie.create, it’s going to create a new zombie, and yes, congratulations.  So, this is all in a browser.  So if you don’t want to invest the time in installing Rails, installing Ruby, learning how to use a text editor or an IDE, just go to railsforzombies.org, everything is in the browser, watch a couple of videos, take a couple of challenges, and then you get to decide whether or not Rails is for you.

Fr. Robert:  There you have it folks, you have no excuse.  You don’t even have to install anything on your computer.  If you’re not doing Rails, well, it’s on you.  Carlos Souza from Code School, once again we thank you for being our code warrior, for being our Ruby and our Rails guru, our expert.  We’ll see you next time, and now back to you, Padre and Lou, on the code desk.

Fr. Robert:  Before we continue on, I want to take a moment to thank the 2^nd sponsor of this episode of Coding 101.  And it’s going to start with a question.  And that question is, do you enjoy shaving?  When I started shaving, of course, there was the decision between electric, which is anathema, or some sort of blade.  I went with the blade, but I went with the cheapest blade I could find.  Basically just anything off the shelf, along with the shaving gel, shaving cream, and some sort of aftershave.  Now, I’ve done my shaving dutifully over the years, but it was more of a chore than anything else.  Our sponsor today is to help you move it from being a chore to being an experience.  And of course, it’s Harry’s.  Now Harry’s is a different kind of company, because they understand that shaving should be a luxury.  And everything in their kit tells you that.  From their finely crafted blades to their wonderful handle to the gel to the cream, essentially Harry’s is supposed to be a party for your face.  I’ve been using Harry’s now for a couple of months and let me tell you, it’s different when you actually enjoy taking care of your hygiene.  Now, Harry’s is a different kind of company.  They understand that you want to get a good product at a good price.  They’re not going to be these Fort Knox type of blades that get locked behind a supermarket counter, then you have to go get some pimply-faced attendant to open up for you.  They make their own blades and their own factory.  So they can give you high quality steel at a lot price.  Now, Harry’s engineers them for sharpness and for performance, and in each kit you’re going to get a razor with a handle that looks and feels great, three razor blades and foaming shave gel.  The starter Truman Set is an amazing deal.  You get all of this for just $15.  That’s $15 to start your way into shaving nirvana.  Now, Harry’s gives me that clean, close and comfortable shave, it can give it to you too.  I love the look and the feel of the set, and I got to tell you, I love the price, and having my blades delivered to me each and every single time.  I like Harry’s, I know you’re going to love them.  Go to harrys.com and get $5 off your first purchase with the code C101.  That’s Harry’s, H-A-R-R-Y-S.com, and enter the code C101 at checkout.  And we thank Harry’s for their support of Coding 101.

Fr. Robert:  Lou, I love this idea of this scaffold.  Now we got a little bit of it last week when he talked about the build, right, the framework with build, all the dependencies and built the library.  But now I actually have a tool that will build up the dependencies I need to take in data, store data, manipulate data, delete data as necessary.

Lou:  Yea, I think that’s kind of the key to this whole Ruby on Rails like marriage.  Is that it gives you the ability to generate all this stuff, what they call “the scaffolding.”  So that this way you could be more productive and you can get where you need to go faster.

Fr. Robert:  Yea, and he keeps calling it the CRUD, it’s all the CRUD, right?  This is really where it becomes useful.  Because, as you said, especially web facing applications are only useful when they allow us to manipulate data, well he’s finally giving us the last pieces that we need to be able to do that.

Lou:  The CRUD, the create, read, update and deletes.

Fr. Robert:  There you go.  Now there is a piece there, and this is why I’m so glad you chose that story for the top of the show, of the automated tests.  And, you know, I was a little confused.  I was talking to him like, so are these automated tests looking for exploits, no, no, no that’s not what it does.  It’s just automated tests so that every time you make a change, it will run through your code base and say, “You do realize you referred to it here, and you just broke it because you changed the name, or you changed the assignment.”  That’s, that’s when it really starts to get crazy, especially if you’re working on a team, right?

Lou:  Right.

Fr. Robert:  What kind of verification tools do you use as you’re working on these gargantuan projects?

Lou:  So, I mean, a lot of the times the compilation of you using an application, or you using a language that actually compiles, a lot of the times the libraries that you bring in, if you removed a dependency of it, the compiler will tell you.  But there’s other things, where some things that runtime will pull things dynamically, data dynamically, you can’t catch those. And that’s where some of the, like you said, automation tests can come in.

Fr. Robert:  Right.  I do want to pull in one question from the chatroom here.  Mytallis42.

Lou:  Oh no.

Fr. Robert:  Yea, yes he is.  He wants to know what is the biggest bug that you’ve actually released into the wild?

Lou:  I would say, you know, everyone always has this buffer overflow story, I think I have mine where it’s, you know, you didn’t really realize that the software that you, it’s an installed piece of software, and people may have installed the 64bit, I mean, the 32bit versus the 64bit.  And on Windows you only get what they call 2GB of virtual memory to use in your process phase.  And we’ve talked about it before on other Coding episodes, and what I didn’t realize was, hey, what happens after you get up to the 2GB?  So we start the page, and your software gets really slow, and then, what then happens?  And so at some point you get this overflow in your RAM, you run out of memory.  And so I, you know, I’ve shipped applications that have had that before.  A long time ago, but you know, you learn by your mistakes.

Fr. Robert:  Alright.  And also, again, those are the kinds of mistakes where it’s really hard to test for.  Because essentially what you’re saying is, “I’m going to push my machine until it’s unresponsive.”

Lou:  That’s right.

Fr. Robert:  And weird things happen when your machine starts becoming unresponsive.  And you can’t always replicate it.  So, yea, again, so, so much respect for the people who can do threat modeling, who can do penetration testing, and the people who can do verification of data flow.

Lou:  Yea, it’s a tough process. 

Fr. Robert:  It’s a tough, tough, process.  Well, Lou, next week we’ve got the last episode coming from our code warrior, Mr. Carlos Souza.  He’s going to be wrapping up Rails in a nice, little, tight bow, and he’s going to give us a couple of homework assignments to make sure that our audience can go out there and play.  I do, I do want to, I spend a lot of time on this site.  And Zach, if you could bring this up, he’s talked about this several times, railsforzombies.org.  This thing is so much fun.  If you ever want to take a look at Ruby or Ruby on Rails, this is the place to go.  Because it’s the gamification of Rails.  It’s, you know, it takes you through the lessons, and you know,  yea, it’s kind of campy, it’s kind of dorky, but I’m very campy and I’m very, very dorky and I like earning badges.  And it will take you through all the different things that Carlos has taken us through in his lessons.  So if you want to know how to use the Rails command, to set up the dependencies, if you want to know how to use the scaffolding, if you want to know how to do front operations, this is a really good place to start.  And it’s free.  It’s free. 

Lou:  It took a lot of time building it, too, I was very impressed.

Fr. Robert:  It looks good, it doesn’t have any major vulnerabilities, although maybe I shouldn’t… I could help him with that, with a couple of special boxes.  But, no, we’re going to get that all next time.  This time we want to thank you for watching this episode of Coding 101.  Now don’t forget, we know that this is a lot of information, but you can always find what we covered, the assets for the program, the code at our show page which is where, Lou?

Lou:  twit.tv?

Fr. Robert:  twit.tv.

Lou:  It’s hard, right?

Fr. Robert:  It’s really hard.  Just go to twit.tv/coding101 it all goes to the same place.  You’re going to be able to find not just all of our episodes, but if you want to download a back episode, maybe you want to get a module, the pearl module that we did, or PHP, just go to twit.tv/code, there you will also find this little drop-down menu, so that you can get every episode of Coding 101 automatically to your device of choice, your iPhone, your iPad, your Android tablet, your Mac, your PC, desktop, laptop.  I kind of like that, it’s got a nice, it’s got a nice cadence to it.  But no matter what version you want, you can get it, just go to twit.tv/code.  Also don’t forget that you can find us on the Twitters.  We are always on the Twitters.  He is twitter.com/LouMM.

Lou: LouMM

Fr. Robert:  Yea, LouMM, same name that you got in the chatroom.  And if you follow Lou, you’ll find out what he’s doing.  Like, for example, he was at the ten year anniversary for TWIT.  That’s where he got his very cool wristband.  It’s fun to see what actual people who do actual work.

Lou:  What we do during the day.

Fr. Robert:  I don’t really work for a living.  I mean, I goof around.  But you work, so that’s good.  You can find me at twitter.com/padresj, that’s @padresj.  And if you follow either of us, you can always ask us questions about what happened on the show.  You can suggest guests for future shows, or topics for future shows.  It’s really a good way to interact.  Another good way is our Google+ group.

Lou:  Love that group.

Fr. Robert:  Yea, it’s a very, very good group.  Just go to Google+, look for Coding 101.  Filled with novices, filled with intermediate programmers, with experts, and you get to ask questions.  There are no dumb questions, there are only dumb webpages.  I keep changing that, but…

Lou:  That’s true, though.

Fr. Robert:  It is kind of true.  Now, if you are going to stick around for Coding 101, don’t forget that we do our episodes live, mostly, every Monday, 2:30 PM Pacific time, drop in at live.twit.tv and you can see what’s going on before the show, after the show, during the show, everything that we cut out.  And as long as you’re watching live, go ahead and jump into our chatroom at irc.twit.tv.  You get to ask us questions.  Lou and I have a little box right down here, that little view.

Lou:  Where they can embarrass us, too.

Fr. Robert:  Yes, you can embarrass us.  Or you can ask us questions about what we’re actually doing.  You could tell us that we’re full of it.  That’s fine.  You’ll get kicked out of the chatroom, but you could do that.  I just had to throw that in there.  And finally, thank you to everyone that makes the show possible.  Of course to Lisa and to Leo and to our fantastic, our absolutely wonderful team, especially since he stayed here late to help us with these recordings.  That’s right, it’s Eskimo Zach.  Zach, can you tell the folks where they can find you?

Zach Smith:  Yes, you can find me at Twitter, thank you Padre for being so sweet.  It’s @eskimozach, you can see it right there.  E-S-K-I-M-O-Z-A-C-H.

Fr. Robert:  We’ve got a goal, folks.  We want to get Eskimo Zach more Twitter followers than Jeff Needles.  And he’ll promise you right now, he will not tweet and endless stream of Meerkat for you.

Zach:  I promise.

Fr. Robert:  He promises.  Until next time, I’m Father Robert Ballencer.

Lou:  I’m Lou Maresco.

Fr. Robert:  This has been Coding 101.

Lou:  End of the line!