OK well let's go ahead and just get started then. Anyone that comes in late can follow along and catch up that's going to be the nice thing about today's webinars we're not necessarily building everything and just kind of quickly reveal when we go over what you can do with the Rails console.

So before we get into the console let me just briefly kind of introduce the app that I'm doing today. So what I've done is I decided for today's app is to kind of just build an events application. I built zero front end for this so I'm not going to show you on the browser. But what I've done is I've gone ahead and will look at the models first. I've gone ahead and I've created an events model. A user model, and then an RSVP model. And this will all make sense in a little bit. But in the end what this would be is just something like you would see on MeetUp where we're creating an event or users creating an event and then other users including the user who created it has the ability to RSVP.

So for those that are on campus they've all participated in the "App in a Day". The app in a day is when the instructors at Bottega come up with an app for all the current students attending the full time class to build. For this the last couple of "App in day"'s, they've had us build an events app.

I chose that because it's really easy to kind of go through all the data within an event app you see the events you see the users. The really the neat thing that I've built in this was a rails association which is going to load the different models, events and users to communicate with RSVP so a user can RSVP for that. So that's a really neat feature that I have a lot of fun building out and I'll actually be teaching my lesson probably in the next week or so just all about the rails associations and how you can build cool relationships with them.

I guess one more thing I will show you is I've already gone ahead and done, is I created this great seed's file. I've got five different users that will be looking at, as well as 50 different events. We'll create some more inside the console and whatnot but that's how you'll see that we already have existing data and that's why I pulled all that data into the application.

If you did pull my app off of GitHub today, all you have to do when you're bringing it into your text editor. Then inside the terminal, make sure that you run rails db:create and then rails db:setup, and that would get you to see its listing of data. So that way if you're coding along with the video you can also have all this data and everything ready for you, right up front.

So the first thing to do when you're accessing the rails console is super simple. You'll just type in rails c. (Then there's also rails c --sandbox). The sandbox is a typical sandbox in development world that's letting you manipulate or create data and so forth without actually affecting the application. For this, because it's something we're just using with the console for, it's not going to matter either way. I just wanted you guys to know and be aware of the sandbox because that way if you are trying to create additional users for just tests inside the console, you're not actually affecting your application in development mode or once you push it live.

So we'll go ahead and jump right into the Rails console.

A lot of this is going to be pretty familiar with anyone who's gone through the first application in devCamp. But I want to kind of expand on everything more so everyone can have a general idea of what's what's really happening inside the console and where it's really beneficial. So what we'll go ahead and do, is we'll just start with looking at what I created. Let's call User.all. When I call the User.all, it's going to give us a list of all the different users. We'll have user James, we'll have user Vern, we'll have user Ben, Shane, and Jordan.

Then we'll call Event.all, this is a long list of events of course. But these these are all the events that were created from within seed's file.

You also have RSVP.all and it should be blank right now... you know, there was one that I created before. I thought it was blank but because I had actually ran a test earlier there is one RSVP. But we'll get into how this functions and just a little bit.

So anyone who's familiar with SQL or databases it's just a lot of calling data, calling tables, and asking for it to return information. So that's really all Rails is doing when you're setting up that controller, where you're saying @blog = Blog.all. Really what you're doing is you're just telling Rails to identify this variable at @blogs the instance variable to call that database and call something just like we're seeing here.

In the rails console you can also do the same thing. You would do @event = Event.all. This is something which is going to be very familiar when you're creating the view pages or you're working with a controller.

There's also a really neat thing that you can do inside of Rails, I've talked about this in other videos or webinars that we've done. But then it's also something that you built out in several of the rails applications and that's the custom scopes. So the custom scopes is really neat. We can call for specific information. For example if I want to look for a specific user, whose e-mail is let's say Vern. You can use this User.where and then pass in the table column that you're looking for and the exact information. So in parentheses we'll do User.where(email: "vern@example.com"). Now we can see right here we have the user, that has vern@example.com.

We can also do that same sort of call to look at Event.where(event_name: "Graduation"). If you're having some sort of reoccurring event and you want to have that available then you can use this Event.where and create that as a call inside your application.

So a really neat thing is when you are setting up custom scopes, for example in the devCamp portfolio application, a little bit towards the middle. Jordan will actually walk you through creating a specific scope with blogs that have the topic of Angular. What you can do to get to know if this scope is going to work or not is you can actually come inside of the rails console and you can test the calls from there.

In a more detailed app that I have it's calling for quite a bit of information. So my call is actually it was something like this Account.where (it's not going to work in this application) but I had to come in here and test over and over and over again until I found the right scope to give me the information. Well then once I did that I could take this call and pass it into my Rails application and then just so you're familiar if you are creating something like that. Typically what we'll do is pass it into the model for that specific scope.

Event.where(event_name: "Live Webinar") Now what we can do because we know this returned the information we needed, we can actually come here, copy this information, and then bring it into our application. Here in the app/models/event.rb, I can now do something like this.

def self.webinar
  where(event_name: "Live Webinar")
end

Because I'm calling "self", I don't need to include Event any anymore and I can just call where a event name equals live webinar. We save that and the neat thing is now with that custom scope inside of here. Let's close out the console and log back in to it so it refreshes this scope. Now if I go Event.webinar, you'll see that it's created that exact same call because I've created that method and made it accessible.

It's really neat and that's just the beginning of how flexible it is. If we have time, maybe what I'll do is I'll bring in my application where the console is just phenomenal for all my calls and queries and whatnot. That way you'll really see the strength that this console really can provide for you when you're trying to build out specific features of your app. So besides just making calls the Rails console is also super robust because you can build, create, delete and edit things inside of here.

Let's say for example that you wanted to take Event.first.. What I'll actually do is I'm going to give it a variable of "e" first (e = Event.first). This is just something that the rails console allows you to do so now when I make a call I'll be able to use the variable "e" without having to call Event.first or Event.find_id over and over again. so we'll call e = Event.first here and set the variable. So now I can use e.update!.

If you use the explanation mark it will actually notify you if there's any errors. So when I'm use inside the console and creating, updating, or destroying things. I'll always just throw this in here. If you don't use it and there something wrong, it won't give you the error and you might think it's working but it won't be as easy to catch. So good practice and it's not going to hurt just to add that extra exclamation mark. But what we can do now.

We can call this Event.first ("e") and then we can call this .update! method in here. So let's say that we want to call this e.update!(event_name: "Rails Console Webinar"). All we have to do is pass this information. Close it with parentheses. And now when we call "e" again you'll see that it updated that name. You could do the same thing with any other column inside of the event.

We could say e.update again and now we could run something like location. And we would just call this e.update!(location: "100 South State Street, Salt Lake City, UT 80000"). Now I don't know what that zip code is out there but now you can see that it went through that first event. We've now changed the name, we've now changed the location. Then of course you can also delete things. So I want to look for an Event.where(event_name: "Ping Pong") So we're going to get 10 other ones and what I'm doing here is I just wanna grab an I.D. I'll just randomly grab this 28.

I'm just going to set a variable but p = Event.find(28). Now we've set that and then what we can also do what I mentioned before and destroy it. p.destroy. Now it's destroyed. So it's really flexible because now if we were to call this again. Event.find(28) is no longer available. So we know that it successfully deleted that.

It's really neat just because you can do a lot of other management within the database tables within the console as well. Let's call let's call one more. Let's call e2 = Event.find(12). We know its "App in a Day", let's say that we want to go e2.update!(event_name: "Hello World"). Now the nice thing is we can call E2 again and it's going to bring up that "Hello World" event. But now what we can also do because I've been using everything when I declare a variable. I've been using Event.find() and find it by ID.

But now we could also go Event.where(event_name: "Hello world"). So now what this is going to do is... it's another call. But if we wanted to, we could also try running something like this. Now you'll look for that specific event and we can update it. Event.where(event_name: "Hello World").update(start_date: "01-05-2018")

So we have our event to I.D. 12. So let's look at Event.where(id: 12). And then let's also call the Event.find(12). So what you can see here is it's giving it to us in a different format. So when I use this method it's printing out active record relation first when I just called the find 12. It's passing in just a straight hash of the event with ID 12.

So what where that comes in useful is in larger applications or even in specific events. You'll know what kind of information you can call. So I've had applications before where. I'm looking for something very specific and I want to know where the event "Live Webinar" is. But what I'll have to do because it's parsing it differently than it is with a .find is they'll have to come into the console kind of manipulate the data until I know that it's printing and working the way I want it to. So that's a really neat thing about the console as well is you can trial and error and until you get that very specific call that you're trying to create. Again if we have time I'll kind of show you a few more examples with the other app I built.

Those are really the basics of kind of what you can do with the console. So again you can,

• Make a call or specific kind of search through your database.
• You can, update, destroy and also create.

Let's go ahead and exit out of this just so we can start with a fresh console screen from the top. I also want to say before I was creating a lot of variables. I would do E1, E2 and those were only for that session of being active in the rails console. So because I left and came back in. If I were to call E2, it won't recognize it. Whereas if create a call e2 = Event.first. Now E2 will be available but if I exit it out and then go back in. E2 will not be defined again. So that's just something they keep in mind. It's actually super nice because as you go in and out of the terminal to test it you don't have to constantly be coming up with the new variable.

We'll go ahead and exit it one more time and we'll go ahead and do some new create methods. So I'm going to call a user or u = User.create!(email: "parker@example.com", password: "asdfasdf", password_confirmation: "asdfasdf"). Now what this is going to do is it's created a new user for us and you can also call the variable you and it will give us this new user. But if we call User.all we'll see all the previous ones including "Parker" right here. So that's really neat.

Let's say now that we want to create an event. So we'll do Event.create!(event_name: "Day at the Beach"). Now because I don't have parameters it's not requiring all of this. I can actually go ahead and attempt to run it without passing in my start time the description and so forth. But when I actually hit enter what this is going to do it's going to fail because a user must exist. So there's a couple of ways that you can do this.

We can do something like this. Event.create!(event_name: "Day at the Beach", user_id: u.id). In an actual application you might be able to use something like current_user.id. But in this case current users are not going to be defined methods so we'll just use "u". What we could then do is we could take this event dot create user ID and you can pass this in automatically just like that. Let's look at a controller where. What happens is you could take this information and you could pass this in as part of the create method But what happens is this now becomes accessible to hacking so there's actually a lot better way to do it. So I'll show you that next.

So we have the variable "u" ("current_user). So in and rails this would be u.events.create!(event_name: "RubyCon"). It will allow us to create an event that's identified this user so you can see this user right here. So by playing around with the console we are able to kind of learn an additional feature to make sure that the events had that relationship set up correctly. So in the Portfolio application you're actually doing this in a channel for creating comments. So you're calling current_user.comments.create.

So that's one instance that most of you have gotten to that point in the program that you've already done. So you can now see here (And this is what I didn't want to reveal earlier), is this create method. I actually came in earlier and said, "Okay, @event = current_user.events.create". Instead of what it is by default where it's the @event = event.new(event_params)

That's just a really neat way that you can build out that flexibility and then still keep the apps secure. So again you can get to conclusions like that and trying stuff out by using the console. So another really neat thing that I want to show with the console now. Is also what I did with the relationships on the RSVP.

We will exit out of this, and this is this is pretty common for me I like to have my console all at the top. So when I get through a lot of console talk unless I've created variables that I very specifically want that I don't want to re-type. I'll exit of the console, come back into it, all the time just so you have a clean page to look at. That's just a preference and it's definitely not anything that you have to do one way or another.

So we'll come into the Rails console again and let's call u1 = User.find(1), u2 = User.find(2), u3 = User.find(3), u4 = User.find(4), u5 = User.find(5), User.last

Just 6 users in a different application you might not necessarily follow the same workflow but now we have a variable for each one of our users. And let's go ahead and I'm just going to call some random ones so we'll say e1 = Event.find(7). Let's just start there so inside my application like I mentioned, I want to give users the ability to RSVP or register for an event. That can be done through several ways. The absolute best way though is by setting up that association or that relationship inside of Rails. So now what we can do is Rsvp.create!(user_id: u1.id, event_id: e1.id). Okay so now what it's done is it's allowed us to create an RSVP for event 7 which was the "Live Webinar". User 1 is now RSVP'd for that.

Just so you know where I'm getting this u1.id, its just because we created that variable and then called our ID it's making it accessible. So you could do, for example, u1.email, and it's going to print my email. So just if anyone was confused where I was getting that; that's where I was. This association requires ID that's why I passing ID. So I just ran this create this RSVP create method. Can anyone tell me what's wrong with that? Or I guess, what's the better way to tell accomplish what we just did?

All it takes is what I did before when we were creating that event. We're just going to say u1.rsvps.create!(event_id: e1.id). So how you would typically run this is by creating a button inside your application on the view page. Then it will automatically be calling in. This can be flipped so you could be calling in the event. So let's see and let's not call me again let's call our user number two so you can see again how I received got that same information. But by passing it in this way. It just made it a little bit more secure.

So now let's go back and create that same event. But now we can go ahead and say, "OK who is user 2?" I think this is Vern. So lets say u2.rsvps. So now what would be able to do is you would be able to give the user a custom view of just the events he subscribed to by calling in a custom scope. So you could call something like this. And this might not be the best place to call it but. You could do something like this

So now what will happen is if we have a page that's my RSVP. And then we call this method. We could actually have it go through and parse it just like you would your events start all or so forth but it's only going to show the events that they've created or that they RSVP to. Then you can create an event. You can also delete it. So if we say lets call this u2.rsvps.last. In this case it's allowing multiple RSVP's to the same event for the same user. You could of course for this app, as you build that out, make that not a rule.

I forgot to set this up with a variable so r = u2.rsvps.last. So now when we call "r", it'll give us this duplicate RSVP and then just like we did with events with the users. You can now call in a dot destroy... and that works. Now when you call ur.rsvps. He'll just have that one RSVP again. And then of course let's say we call e2 = Event.last. We can now switch this so we could say e2.rsvps.create!(user_id: u2.id). I'll use the same one. So now this. You could do the reverse of what we just did so we can now call e2.rsvps.

Then let's say I'm curious now this is not something I planned for but this is the benefits of the console. So we can call in the RSVP's. So now instead of calling RSVP's, lets just look for the users. So it gave us just those 2 users. Now you can see right here the event that we created up here. Users are, James and Vern and so forth. So it makes it really, really flexible you can you have to learn different things and whatnot and know how to display your different options or data tables.

So really thats the Rails console and that was just him minor view in it but it's really neat how well you can build that out.

James: Does anyone have any questions?

Q: Yeah I actually had a question. So I know the colored text is something in your text editor.

James: Right.

Q: But, what it does that stuff mean? Cause thats not something that you're typing in, and that's not the item that you're calling that says SQL code, isn't it?

James: Yes this is all as SQL code. I don't know as SQL well, it's something that I want to pick up. But this right here is pretty much what you could call this sort of command inside of SQL and it would print out that information. So that is where Rails is kind of simplifying the search in the calls and whatnot for you.

Q: Okay so rails is kind of generating minuscule code for us?

James: Correct. That's my understanding. Okay what I'll do is I'll get I'll double check that out because don't want to say, "Oh that's absolutely it." And then actually be wrong. But that's always been my understanding of it.

So while we have just a few more minutes. This is another app that I've built. And lets it's been a while since I've been in this app so I might be pretty bad at different calls. So let's see. So we'll open up my console. So this is a CRM application that I built so it's just a customer relationship management system and it's not fully built out but I've built it so it's very lucrative in what we're doing. So we have a user for example let's just call the u = User.first. And let's look at u.accounts.

So now this user has created all these different accounts. But what I wanted to do from there is u.accounts.first that works perfect so that you pull the first account for my user. Which is myself in this case. But so what I want it to do now is to make sure that a user could create an account and then create contacts within that account that would only be familiar with that account. It is turned into this call that was very long and very ugly. Let's see if I can remember where I put it because you'll kind of see what I did.

OK. So it's so it's this one. So what I had to do is, I've built the system so it has one active account at a time a user can't have multiple active accounts. Then I created this call that stopped active. And that's just using an enum right here.

So I could call, for example down here, I could call u.accounts.active. And it's going to give me that active account for that user. But what I wanted to then be able to do is have that contact method for create. You should be able to look for all that information, the active accounts so forth.The user that's inside it and then create a contact for that. So how I got through that information was just failure after failure after failure. So it would be something like OK. I want to find my active account Account.active. So now I have the different active accounts but that's going to be all the different accounts for each user.

So it was just a really neat way that as I build everything out, I was able to find that exact scope that I was looking for and then create this search inside my application to make it accessible when we're creating a user. Let's go ahead and do something else a, couple of things, we'll call current_user = u. So now we'll have the same current user. Because this is an account model. And I'm using a "self". All I have to do is write here. I have to call account and then I can paste that information here and you can see that in the end it spits out my business Kroto.

I will not lie. Just creating this custom scope took me a couple hours but I was only able to find it in because I was using and accessing this console. I mean that's a 60 to 100 foot overview of my application. We're learning the console can be really really helpful for you but I show you it because I want you to understand how helpful this console can be for you when I am very first started with rails I absolutely hated the console and I wanted nothing to do with it. But as I continue to use it there's not a day that I build the new web application or that I'm doing something within a Rails app that I'm not using the rails console because of the power it has. But that's a class for today.

James: Anyone have any final questions?

Q: Yeah I've got another question, so I can see the benefit of messing around on the console and seeing what works and trying to get the information you need. I would be afraid to mess something up and not know how to fix it. I guess that's what sandbox would be for. But it looks like there's somethings that you were not doing in sandbox mode but it didn't mess anything up. How do I know what things I should do in sandbox mode when things are safe to try out just in the console.

James: So right now I was just in the rails console in my in this CRM app, and all I was doing was making certain calls and seeing what the output was. However now what I did as you were asking I jumped into this sandbox because I really don't know how my app is set up right now. I don't want to mess up any of the records I don't want to mess up any of the active accounts or users or whatnot because I have it built out very specifically as I continue to test development.

Because I came in Rails console what I can now do is. Call something like u = User.first. Now let's destroy me right? So we can destroy. And now we knew that works so you can see that not only did this destroy it but it deleted all my notes. And why did it break? I mean I'd have to kind of dive into this more but you could see that it actually ended up breaking it. So what's likely happening just off the top of my head is I'm likely not calling something that should be dependent.

So for example my accounts or my settings. This is like the RSVP in that last app probably needed to be deleted too. Okay so anyway that's a way. I got back out of the sandbox and went into Rails. See we can even go back into the sandbox. If I call User.first I'm still in there. Does that make sense? Because I was destroying a record inside the database itself. I use the sandbox when I was just trying to make a call or whatnot. I was using the Rails console because it wasn't gonna affect it one way or another.

Q: Okay. Yeah that makes sense because if you're going to call it and you're going to get the data you want or you'll say I don't know what that means.

James:Exactly and then the first application that we've been in most of the day since that was one just for today. I just stayed on the Rails console cause it wasn't going to really ruin my application or anything. All right. Great question. Thanks so much everyone for participating today and for joining me. I definitely hope that if nothing else you'll learn to love console a little more. It's definitely one of my favorite things about Rails. We'll still be on for next Tuesday. I think we'll see. I've got a double check I'll actually be out of town. But we do have someone else teaching so we'll definitely keep everyone updated for that but thanks again and you guys have a great evening!