Hey, guys, this session is being recorded, so we'll start today with a discussion around generalized concepts about application development as it applies to using in the context of a cloud, and we'll begin that discussion, so we'll focus in that direction. Couple of things I think we mentioned in the last time we discussed is there are these three things that typically an application does. Those three things are, they're generally called MVC, if you will. There is a concept of a model, a view, and a controller. Model is where you store the data. This is the model, data model, that aspect. View is what people see, and controller is where the logic sits. This is generally the approach towards creating an application, so M for model, V for what you see in view, and C for controller. That's the classic, very well-established approach towards writing applications. What does it translate to in practical terms? Let's understand this. Let's say if I have a bunch of cats and a bunch of dogs, I need to be able to create an application that shows me at any given moment how many cats and how many dogs do I have. That's the application. I have some cats, some dogs, and this is my iPhone. I see that I need to show I have the number of cats and number of dogs as zero and zero to begin with. That's my view, so this is my classic view. This is what I see, and then this is the only thing that I see, actually. There's no other action. Now I would like to see that I go to the shelter and adopt a dog. If I do that action, I need to somehow communicate this action of I did something. On the back end, there is this data about cats, how many cats I have, and how many dogs I have will need to be kept in a database somewhere. According to that data, this view will generate. That will show on the phone as to how many dogs, how many cats I have. Now comes the part of the action or the control. When I actually visit a shelter and I get a dog, I need to somehow modify this data. When I modify the data in the database, database is basically a place to store data. Where applications can then read and write and modify and update, and then, accordingly, change the view. So when I change the view, I should see one. Now this is the number of dogs and cats that I have at a given moment in my home. This is the view in my home, by the way, so that's the idea. So now my son comes along and he says, I want to take the dog out for walking, so the dog goes out for walking, and this time, the number of dogs will become zero. But this is just the view part. We have to actually change the number of dogs in the home to zero at that moment, because the dog was taken away for a walk. And actually, what happens is the dogs take you for a walk, but that's a different thing. The idea is these guys, the number needs to change. This number needs to get updated in the database. And accordingly, this logic that you have here, the control logic, will need to change that number back to zero if the dog goes out for a walk. Comes back, the number needs to become one again. And these kind of changes need to happen in the database. Database and the actual model is where the data is stored. Number is the piece of logic that will control the change of data, zero to begin with, get a dog, let the dog go on a walk, dog comes back, all the things need to be modified and updated in the model. There is a separate piece of code that is responsible for showing what is in the database. That piece of code is called the view code. All this thing does is shows what you have in the database. So there are three separate conceptually distinctly different elements of writing an application. That is what this thing is, the MVC example, model view controller. This is just one of ways of writing applications, there are others, but more or less, they kind of sort of fall in this line. So in effect, what you will typically have is when you write an application, it is going to be in a folder. And in that folder, you will have subfolders or directories where you will create code corresponding to the model, code corresponding to the view, code corresponding to the controller. And you will have separate files in there and separate folders and like that. Files and folders that are responsible for managing the data model. The set of files and folders that you will have responsible for managing what the user sees in the view and a set of files that will actually control what that data model actually is going to be. So this guy, controller, actually controls the data. View is basically a reflection of what the data is. And this is how you separate. This is just one way of writing applications, but it's a considerably good way to think about how do you separate writing pieces of code. So a code that fits in here, you don't want to have modification of managing data itself sitting in here or modify data here because that is how you separate concerns. The idea is separation of concerns. So you separate clear concerns separately in independent folders in your application and write in a fashion so it is easy to understand for other people because when you write code, you want to write in a fashion that others can understand. Otherwise what's the point? So if I say something and you don't understand, what's the point of me speaking? That is the kind of way of thinking underneath in this idea of separation of concerns is that we write applications, we write code in a fashion so that others can understand, make sense out of it, and manage it beautifully in terms of as you collaborate. So as people write applications, as they develop something, they will keep changing these files and folders. That's how application development works. These things will keep dynamically changing. And now we have 10 people in the team, for example, 10 in a team. And so in that team, we have 10 people, all of them will have the same folder structure with MVC and like that. And so we have 10 copies of this thing. Everybody is changing here and here and here and here. Now it's a nightmare. What is the final source of truth? Who is right? Who is wrong? Now that has to be understood, that has to be very carefully and systematically controlled because if this thing is given to the customer, and that's great, but what about this change that this developer did? Like I said, we have 10 people in the team, like call them A, B, C, D, like that. So if a person called F creates some beautiful modification to the application, that will never reach the customer, then what is the point of his work? His work is wasted. If he or she writes something interesting, we need to have the changes that the change that this person made into the code needs to get propagated to other people's machines. And then understood that this is actually a good thing so that everybody should actually take it from this person who wrote that change. Because if it turns out that it is not so good, not such a good thing, we should not take it and reject it. So that acceptance or rejection has to be systematized in terms of propagating changes from you as your developer, as you send across things to other people in your team, is collectively people decide what is good, what is not good. And that is how, as a team, you will decide what does the customer want. And then you give it to that customer. That's the common idea. To enable this setup, people have been using a variety of tools to enable that. One such tool that is immensely popular is called Git. You must have heard of this. I'm pretty darn sure. If you know of other tools that are sort of like Git, please just name them. There are others like Subversion. Microsoft uses a tool called Perforce, which has an internally different name. But the internal name, I think, is called Source Depot. That's the name internally Microsoft uses. But actually, it is a derivative of this software called Perforce. There is another software called Mercurial, HG Mercurial. And like that, there are many. These tools, some of them open source, some are not. Like this one is not. But this one is, and this one is, are similar to this, except this is the winner, winner as in, as in, hold on, as in this. So this is the source software that I'm talking about. It is called Git. It is available for Windows, Mac, and Linux, and every other platform. This is the foundation of this application is used to create what is known as GitHub. GitHub is the Facebook for developers, if you will. This is where people share code. And I suggest that you please open an account here that will be helpful as we go along. It's a free account. And you get to share your code with other people. This is how people collaborate on the internet using Git software. And this happens to be one such place where people share their code privately or publicly. Another one is Bitbucket. This is basically another solution that uses Git to store, collaborate, and modify, update, and maintain, manage, and distribute applications to the customer. There are more, like GitLab is another one that I think Boeing is using internally. This is open source. GitLab is open source available for download. You can play with it locally and all that good stuff. And let me adjust a couple of things here. I think I'll get a bunch of notifications I don't want. I'm disabling them right now. Disable this, disable this, and OK, I think I disabled that. So GitLab is another application deployment that uses Git under the hood and helps people collaborate. So these three things, like I mentioned, GitLab, Bitbucket, and GitHub are services that use this software, the Git software. It is also open source. Git is open source and available as a source code on GitHub. Git was created by this guy. You probably know him. And where is Linus? This guy. He created Git in five days, and he used this Git software to manage Linux kernel. He writes Linux, by the way. He's the creator of Linux, as you probably know it. You know this gentleman. The name Linux comes from his first name. This is where it comes from. The Linus is his first name, and his product is Linux. And so he created Git in five days. Git is an immensely complex piece of software. However, we will not go into the complete nuts and bolts, but we will stay focused on what will it be useful for us, for you and me. How will we make use of it? There is a write-up on Git somewhere on this website that I think you should have read, module 14. There are some concepts described. And it is a cryptic reading, if you are, it is mostly reading. This is a cryptic reading to understand. But I will describe this with hands-on exercises for us to really comprehend what is going on. And I will also leave you with a video later on for you to watch that will help you Git for four years old. That's the video. And so this video, I think you should watch later on. I'll paste a link in Snapchat. And here it is. So you should watch that video right here. And later on, not right now. But let's understand how will this Git software help us in ensuring that our team members, whatever changes they make, are propagated in a disciplined fashion to the customer. That's the primary idea. All of us will collaborate, write something, and ship it to the customer, give it to the customer without stomping on each other's foot, without disturbing other people's work, giving them independence at the same time, identifying what are the good pieces of our collective work, and keeping them, identifying what are not so good pieces of our work, and removing them. Because people make mistakes, people make good things all the time. We have to identify the good ones and move forward with that and ignore the rest. That's the kind of collaborative tool this thing is. A quick question I have for all of you. How many of you have used Git already? Just a quick yes or no. If there is any user, just trying to understand the level of depth I should begin with from. So apparently nobody has used Git, which is okay. Just in your exercises. Yeah, we've got GitLab. Right. I know you have. The question is, have you used Git on a project? I personally haven't, but all my guys do every day. Okay. Good to know. Good to know. So we will understand how Git can be used in a very, very simple example. Our goal for this customer that we have is to give them a folder containing 26 files. These files will be labeled something like a.txt, b.txt. That's the collection we want to create of these 26 files. And we will have all of you together, and we will create that folder containing these 26 files with these names. And then give it to this customer. That's the idea. And we have to do it collectively. It's a trivial exercise, by the way, but we want to do it like a project. We'll do this on GitHub. So we'll do this on the Git website, which is basically this website. That is where I want to do it. And I want to be able to divide the work among ourselves. So we have, you know, we have like seven people right now, plus me. And so we have eight people. We'll divide this work among ourselves and assign that, you know, let's begin. So the first person on the list will say, create files from A to B, like that. And so we'll divide that work. And I'll begin doing that. So I'll begin here, and then we will go along and assign for the total of eight people that we have in this session, and are they eight? Yes. And so ultimately finishing up with z.txt, and that's the last file we need to create. And then we consolidate all the work that you will do and ship it to the customer. That's our idea. And in the process, we will make mistakes, we'll accidentally do something different. And let's begin doing that. So what I intend to do is actually create a Git repository. A Git repository creation is done in the terminal. So basically, you begin something like here, and you create a folder. Let's say a folder gets created like mkdir, and this is the alphabet folder. And in that folder, I am going inside. And here, I am initializing a Git repository, creating something for the first time. This is a one-time operation. Somebody has to do it. Typically, the team leader will do it. So initialize. And then we have to create something in that folder. Right now, if I initialize, you will see something very, very different. When I say list something, I will find that there is nothing in that folder. When I say list everything including hidden files, ls-la, including hidden files, you will find that it has something in there. And that something happens to be this folder called.git. That is where Git manages itself. So let's go open the same folder in Atom Editor. You will find that in the Atom Editor, we have this folder called alphabets, and there is a hidden folder called.git. It has a bunch of things in there. And where did they come from? This actually came from the Git software that actually put that thing inside the.git folder. Let's go side by side and make sure that we are clean. So if I now remove this.git folder, meaning basically go right-click here and delete, you will find that my Git repository is gone. And of course, it's an empty folder right now with nothing in it, like this nothing. And you can see that in the right side as well. Alphabets folder contains nothing. So I initialized my Git repository, and then I deleted it on the terminal. So it's basically everything about that repository is stored in that folder called.git. That's what it manages. So now let us see if I can create a file there. I will create a new file in here as simply as going to this location and say right-click new file, and I'll call it a.txt. That's one of the first things I did. So I created a file called a.txt that shows up in the folder right there, and I save it and I close it. It's an empty file. I'll see that I have it listed in my folder, a.txt shows up. So I began working on the project. Now I want to put this project and protect it from destruction, make sure that I enable it for collaboration, for which I need to use Git software, for which I need to again initialize Git repository because I deleted it right here. You saw I delete the.git folder, the repository goes away. This repository was created in the previous step, but I deleted it. So I had to do that step again. This is just an illustration of where Git is storing the intelligence about the repository itself. Now we'll create another Git repository in the same folder. So Git, init, and dot means right here. So when I say dot, it means this folder. When I create that, you will see that a.git folder opens up on the right side. You will see that it creates like that. And so you will see that this thing automatically comes up with the content. Now in terms of protection, what Git does is this concept that I'm describing. I have a folder and in that folder, I have a file called a.txt. I initialized Git repository into this location. So Git, init, initialize in that folder. Dot means this location and that creates another subfolder called.git. Anything that begins with a dot is hidden by definition. So you cannot see it when you type ls-l, you don't see it. When you type ls-la, you do because this a means all and it shows you including that is hidden. So the dot thing is hidden, it is not shown when you say a, it does show. In that folder is where Git will manage itself. And what I want to be able to do is have a method where this creation of mine is kept track of. I want to keep track of what is going on. So what I need to be able to do is commit, like make sure that I commit my changes and preserve them. And that commit is a two-step process. In Git software, when you create a file, which is what I just did, create a file, you have to put that in a stage and verify that and then you can commit the change. When you commit the change, it is locked and loaded and kept safe away from you. Even if you happen to delete this file, you can always recover it. And let's go do that. So we had to first stage the file by adding to the stage. And then once everything we have is in the stage, we will then commit that change that we made. The change we made is this file that I created. So back in here, this is the new creation I have. It is called a.txt. I need to stage that change. So I will clear my screen and say, Git, hold on. I'll say, Git, add this item called a.txt to the stage. So I added that item to the stage. Now I can see that my Git status shows I have a new file. It is called a.txt. Now that is an indication that this change is to be committed, not yet committed, to be committed. I need to commit this. It is on the stage. I can unstage it by saying, Git, RM, and remove this file from the stage. I can absolutely remove it from the stage if I want. And that will take it away from the stage as untracked file, a file that is not tracked. So say, Git, RM, and this removed the file from the stage. The file still exists, by the way. The file is still there. The file is not gone. It is just removed from the stage. So I had to add it back. Right now, if you check the Git status, you will see that there is this file. And this representation is different from this representation. Git says it is an untracked file. I know somebody put this file. I don't know what to do with it. Do you want us to manage it? If so, put it on the stage. And if it is staged, in that case, it needs to be further committed before Git starts to manage it. Right now, the file is untracked. And you can add that file if you like. But right now, it is not managed. So we need to just like I have removed that file, we need to put it back on the stage. What I just did in the picture here is I added it to the stage, then I removed it from the stage. So then I need to add it again. And then I can take this step of committing. I will do that. I will Git add a.txt. Now you will see that my status shows that there is a new file that needs to be committed. It is on stage. You can unstage it if you like. But that's not the point. We want to go to the next step of actually committing. So Git, commit. And this time, when I say commit, it will ask me to indicate a message to my team members. What am I doing? What did I do in this change? I made some change. I created a file called a.txt. I need to let my team members know what did I change. And that commit needs to accompany a short message to my team members. And I can add that message to my team members like this. I'd say Git commit. And here it says, write something, please enter the commit message for your changes. Whatever you change, you need to describe those changes here in English language. So we'll describe that. We'll say, I am adding a new file called a.txt. And that is my notification message to my team members. So I did that. I will exit that file and save it and come out. When I do that, I will see that I have my Git status updated. You will see that it shows me that I am on the master branch, which is the main line and nothing to commit. Work tree is clean. My file is still in place. I can see it here. I can now understand what did I do with my Git repository. I can check my Git log. When I see that log, I see that there is this author, which is me with a date and time stamp and a message. I am adding a new file called this. And it is a history of what I have done in this folder. Now this file is protected by the Git commit. What does it mean? I can delete this file like this. And apparently, I have lost that file. If you see the listing, it shows nothing. If you see the listing with all the files, it shows you that you have a Git repository there. But your file is gone, gone. I mean, ouch. But not really. Because you can always revert to a previously taken commit. You can go back to a commit. The idea is, in Git repositories, you have an initial position. And this is what I would call a state, or rather, I would say it's a... If you know mathematics, we are talking about a directed graph. You may have heard of this concept of a directed graph. And a directed graph basically is a transition of states, state initial to a new state. This state includes a.txt. It's a new state I have committed. And I transition from here to here when I commit. And now I am at that stage in a directed graph. I can keep adding another file like b.txt and go to another state. And like that. I can keep making changes and jump my directed graph in this diagram as it indicates. If you think about a toy that kids play called Tinker toys, that is a good way to remember as to what I am talking about. So you may have seen this kind of a game here. So this kind of a thing that kids play with, you can pretty much see that Git is sort of like this in a fashion. In fact, that video that I have pasted in the Slack chat actually uses Tinker toys to describe Git. That's why it is Git for four years old. And our idea is we are creating these transitions from here to here. And then we'll go to here and go here. We can come back also if you like. And we can come back to any state that we want. And we can traverse through the graph according to our desire while still protecting everything along the way. And we'll do that quickly. So we will go back to where that white board is here. Yes. So what I have up until now is initial state added in a file, a new state called contains a.txt. That's a new state. And this was the initial state which contained nothing. This state, these commit states are indicated by a hash, a long hash. This hash is basically what you see, this number. This number is a unique, globally unique number indicates my current state. So this number F8297 is the commit hash corresponding to this commit that I made. And you can have a hash for every commit that you will make. And you can basically use these hashes to go back in time, go forward if you are already behind. You can traverse this graph accordingly. We'll see how we traverse that graph now. I want to be able to go and check out what this thing has. So there is this hash. I will copy that hash. And I'll say git checkout and this hash. When I run that, you will find my a.txt comes back to life. Here we go. Hold on. Hold on. It's in the data state, ls. No, I had to reset. I had to reset. I deleted that file. So I had to reset back to the state I was in. I was already at that state. So I had to reset git, which is git reset, and that brings my file back. This a.txt comes back. That has to be in a clean state before you move forward and backward in a git chain of commits. Now what we see here is this a.txt created. And our log shows exactly the way you have only one entry after the initial entry. I will now create one more file. It's called b.txt. Oh, not here. In this window, create the file b.txt. And now I have this file. Now this file is not in the git repository. So if I see git status, I will see that I have an untracked file, b.txt. And this needs to be tracked. It needs to be put on a stage first before I commit. It's a two-step process. So I need to put this on a stage. So what I'm doing is I have a new file called b.txt. I can create a commit like this, just like I have with a complete hash for that commit, by first putting this new change I have created afterwards to stage it. And when I stage, then I can commit and create this new hash by running something like this, git add b.txt. And then I will check my git status again. You will see that it tells me something different from the previous time. It says untracked files, b.txt. Now it says new file, b.txt. I need to commit it. I can commit. I can say that git commit. It's the second step of commit. And I'll say, OK, I want to commit. Now how to describe what am I doing with my team members will understand. So I'll say I added b.txt. This is my description. I will save and come out of it. Now I will check my log, git log. Here you will find that I have two entries now. One is this hash, 83732, and another one, the one before that, where I added a.txt. And now I added b.txt. So now in our git repository, we have these two hashes. We can go backward and forward as we like. In here, we have 8373. So this was hash number 8373. And this was hash number f829. So this was f829. This is the initial state, which had nothing. So two hashes created. And this contains a. This contains a and b, both. Now if I want to see what I have in my file structure, I have the git folder,.git folder. And I have a and I have b. I can very, very easily traverse my directed graph, go backward in time, by checking out this thing. If I check out this thing, what do you see? What will you see? You will see only a. So if I say git checkout and that hash, which is f829, that hash, you will see that my folder changes to just a.txt. Now if I go back to this hash, I can say git checkout and that hash, which is the later hash, the second hash. I will see that I have a and b, both. You can see it on the right side. And this is how you manipulate and manage a folder containing files on your machine without even sharing with anybody yet. So the idea behind using git software, which is distinctly different from all other software that you may have heard of or used, is that this is a distributed version control. It distributed means you can have people in all over the world without connected with each other and still collaborate in a fashion that is distributed. There is no central locking system that locks everybody down. Because in other software, for example, SVN or other part force, there has to be a central authority. And these team members we have, Alice and Bob and other people, they will have to check out from the central repository, make their changes, and then send it back to the central repository before this guy can take. This is a lock that I want to avoid. Because if I am waiting for them to finish what they are doing, then I cannot proceed forward with my changes and then bring them back. That is a locking situation. We want to avoid those scenarios to expedite our work. And this kind of a centralized repository hurts. It is bad. That's where Git comes into play, it is distributed, meaning all of us, Alice and Bob and everybody in the team, can have their own independent repositories local to their laptop. They can push and pull from a central location such as GitLab or GitHub or Bitbucket or other places or some other location. It doesn't have to be central, by the way. It can be any location. And this pushes and pulls of changes can happen independently of other people without a lock because it is distributed. We will talk and show you how collisions occur and how people avoid those collisions. Collisions will occur when you have a situation like this, which is not centralized. People will make conflicting changes and you will run into problems. How do you avoid them? We'll talk about that as well. But for right now, in our example, what we have done is simple two commits. So we began with nothing. We added one file called a.txt. This is one commit hash. We added another file called b.txt. And this is another commit hash. And so these two commits are available in our log. This is our initial point. Now what I want to be able to do is put that all in a shared location so that you can also access, for which I need to use a service outside like GitLab, GitHub, Bitbucket, or something like that and send or rather push whatever I have over there to have that thing in the cloud somewhere, for example, in GitHub. So I'll go to GitHub and in there create a placeholder and we'll call it the, let's see if alphabet name is available. Probably not. Alphabet is available. Alphabet is not. So we'll just use the alphabet name and make it public and create that location for us to push. Then we will create and push an existing repository from the command line. That's what I want to do. I have my command line, which has a repository. I want to push it from my computer over to this location. So I will just take that line, bring it here, and attach a remote. And I'll describe this. I'll do it a couple of times for you to clearly understand what's going on. So I'm attaching a remote and I'm pushing. That's all it takes. So it will get pushed. And it says, are you sure? And I say, yes. And so it goes and connects and pushes and everything is taken care of. Now back in here, you will see that my alphabet location contains a new file called a.txt. This is because my current situation, where is that? I'm adding a new file, alphabet, one commit, a.txt. And this is the file I created. And so you can see that I have added the file. Now I should also go back here and make sure that I check my git status again. And it is a detached head. It is on 8373. If you remember our picture, we are on 8373 in a detached head. What does that mean? I will elaborate that. And I'll also elaborate the other things that I have done, which I think I went a little quickly on that. So what I want to be able to do is do it again for you to clearly understand. This is the initial point. This was first commit. This was second commit. And I traverse like this. I went here. And then I said, I want to check out this by the hash number. Then I checked out this by hash number. And there is also another reference that git maintains. That reference is called head. And that reference continues to be on top here, unless you move the head. So when I check out something, which is a different number, the head moves to that location or to that location. But the master, which is the top of the commit tree, stays on top. It doesn't change. The head might change. The master stays on top, which is the latest version of changes that you have made. It will still stay on top. For you to be able to push this entire structure over to another location, like GitHub, for example, you need to check out the master and avoid these kind of interim checkouts that I have done right now. And so I need to check out this again in order for me to push the whole tree out to GitHub. That is what I will do. So a head is like a play head on a turntable. When you take your head and move it along to a different location, that is what you're doing essentially. When you check out something, check out this song, check out that song on a turntable, you move the head. That is exactly what happens when you check out a particular hash. It is like moving a head on a turntable. Think like that. I need to move my head back to the master, for which I need to check out master and then push again. So here I will check out, sorry, the Git checkout, master. And now, let us see, warning, you're leaving one commit behind, not connected to your branches. You want to keep changes, switch to my master, okay, I think it is clean. Let's get Git status again. And we are on master. We need to push one more time. And when this push happens, I think this may have confused you. I want to do this again. So I'll do it again one more time. I will basically destroy whatever I have here on GitHub, so delete and delete, so cleaned up. I will also clean up my Alphabet folder. Here we have Git status showing that I am on that, I think it is best done completely fresh. I will basically go back a step, remove my folder called Alphabets and begin from really ground zero. But this time it will be very quick, so you can see the whole picture all at one shot. So beginning from nothing again, so cleaned up everything, create a folder called Alphabet. Now open it up in the Atom Editor. You can see that I have opened it up on the right side here, not this folder, but CDAlphabet and then AtomAlphabet, which is opening up on the right side. I'll put it on the side and I have nothing in that folder. You can see that I have nothing. I can create a file called A.txt. I'll create this file called A.txt, shows up on the right side. I will now put this on the stage and then commit. So git add and then git commit. This commit step will involve me adding a message to my team members. I want to use a shortcut for that like this. This is a shortcut to not have to open the editor, but just pass the message to my team members right through the command line and commit. I could not commit because I skipped one step called initialize. You can see that I don't have a git repository yet, so it is complaining that I forgot to initialize the git repository. So I will do that, git init right here. You can see a.git folder opens up on the right side. Now I can say git add and then git commit. Now I have a commit hash. It is ba62, this hash. I can see that I can add one more file. I can add that file to my stage and commit that file. And with the commit message, and so now I have my log showing two commits. This is one hash with a.txt, this is another hash now added with b.txt. Now I was talking about tinker toys and I described that concept to you a little bit. I would like to open a little software locally right here to show you those tinker toys visually. That thing is called source tree and it is opening up. You can see those tinker toys right here. Let me just zoom on it a little bit. And here is the first hash with the little tinker toy right there, the dot here and the dot here. You can see that I added a.txt is one message that I include here and the file shows added a.txt. I go up a little bit, it shows I added b.txt. So two files added in a two node graph, one and two, two commit hashes in that graph. Now let us see how do we make a remote connection with GitHub. So back here, there is a message here on Slack chat, what does it say? Yes, Shiv is mentioning that there is a facility in others to check out without locking. Which software are you referring to, Shiv? Like TFS or probably. TFS does allow, yes, Microsoft has a product called TFS which does allow that, yes indeed. And so what we are talking about is creating a placeholder for this Git repository to go and sit in GitHub. So we'll create a new one and call it Alphabet and make it public and create that location. And in that location, what we will have is a method of pushing an existing repository from the command line. And so this is the instruction to follow, but before we follow that instruction, what I want to be able to do is show you that our Git repository, Git has no remote connection whatsoever. Sorry, this was little v. Yeah, Git has no remote connection. So Git remote, show me all the remote connections, there are none. Now I'm going to add a remote connection to GitHub like this. It says Git remote add origin to this location. So when I add that origin, you will have a remote connection for pushing as well as fetching. This is the push location, this is the fetch location. What I have essentially enabled is a method for me to push and pull whatever I have in my Git repository to and from GitHub by enabling a remote connection with GitHub. So this is a remote connection we have between our Git repository and the one at GitHub. That's a remote established by this line, Git remote add origin and the link. So you're not using any security to restrict access to that alphabet of Git? It is secure by default. You will find that this protocol uses SSH and security is implied in my machine. That's why it shows like that. In your machine, it will look slightly different. It looks something like this. So I'm clicking this button, HTTPS. That's what you will see when you click here and your remote will be slightly different. It will look like this and it will ask you for a login and a password. For me, I have enabled SSH control to my GitHub account, so I don't have to type in password. That's the difference. You can notice that this HTTPS is what will pop up when you attempt. When I am attempting, I automatically get this default, SSH default, and I have my private key shared with GitHub, so I don't have to type my password. It's a convenience that I have included for myself. You can also do that. All it takes is to provide a public key to GitHub. That's it. So you don't have to type passwords. So that is the security aspect. You need to understand that this protocol up access is SSH-based, whereas this one is HTTPS-based, so your remote is going to ask you for a login password. Now that remote is established, so now I can push my changes. I have my Git log showing these two commits. I can simply push my changes using this command, git push minus u origin master, and it pushes both my changes over to GitHub. I can go to GitHub and find out what did I do, and it will show me exactly what I did. It shows me that I have added two commits. One, I'm adding a.txt, and then I added b.txt, and my current folder structure contains two files, a and b. You can basically take this same folder in this link that I'm going to paste here, and you can clone it. What you can do now is continue along with the exercise of creating the alphabet folder containing 26 files. I have begun with a.txt and b.txt and two commits, and put that in a GitHub location, and I gave you a link. What you can do is clone, basically create a replica from here. You will have a local folder called Alphabets, alphabet, a single, not plural. In there, you will find these two files, a and b. You will also find a hidden folder called.git, and you can continue working on your own. In fact, I suggest that you please clone. Now, how do you clone? You basically go to this GitHub location I gave you. You have that clone button, so click on the clone button. It will give you a link. Give that link, copy, and open your virtual machine, and start it and clone it, git clone link. That's the command. We clone it in this machine. You can see that the changes that I have pushed to GitHub will come down to the VM. It is as soon as it starts, and I will be able to make further changes from the VM and push them over to another GitHub account, or maybe my own account, depending on how I choose to connect. This machine is a completely independent scenario, so it is almost like you are playing with the same repository that I've given access to all of you in making it public. You can basically say git clone and then paste that link that you have from GitHub, which is here. You clone that link, use HTTPS, and when you do that, you paste that link and enter. It will ask you for a password. It will not ask you for a password because it is public. It is public. The repository itself is public, so no password required for receiving, for cloning. When you want to make a change, it will ask you for a password. For right now, you have cloned it locally like I have, and I can make changes to it independently of what other people are doing. I can list out my folder, sorry, not in this folder, in the alphabet folder, list out my files. I have those two files that I saw before. I can check my git log, and it shows the same changes that I added a.txt and I added b.txt. The same thing shows up here. I can then go and add git add c.txt, sorry, the file doesn't exist, so I need to create that file first, and then git add c.txt, and then git commit with the message I added. The git log updates, I have three commits now. The first two are by Nilesh. The second one is by Cloud Genius. The machine user is Cloud Genius here. This is the third entry that I added. They are local to my virtual machine. They don't go outside yet until I push them. I can push. If I attempt to push, it will fail because I don't have my login permission set. If I see my git remote connections, I see that they go to this dacloudgeniusalphabet.git. That's where it goes to. If I attempt to push, git push back to that location, it will say, okay, give me a username please. That's a challenge. Imagine, which is a fact, you don't know my username and password, so you will not be able to push anything to my account. How do people collaborate without sharing passwords? That's the next question. I will demonstrate that piece to you as if I am you, practically. I will do that. What I'll do is I'll break this, come out of it, and remove the alphabets folder. Back to GitHub. What I will do instead of cloning is I will fork it. This concept is something that I want you to understand. Cloning is basically an exact replica. Forking is to create a place where you have this graph that we are creating as we go along, create A and B and C and like that. You decide you want to go and fork and go on your own way. This is like a fork of a tree, basically like a pinch fork, if you will, and then you start working independently from this point onwards. I will work in this direction, you will work independently in this direction, and at some point you will want to make a change and you will push your changes to your own fork of the original repository, this is the original repository. You basically will create an independent fork on GitHub and work with that, and that gives you complete permissions to read and write and modify and do whatever you feel like. When you're done with making your changes, I am working here and you are working with a fork here. I continue working like this. At some point you decide that I need to make sure that my changes here go back to the origin. You can send in a request. Will you please pull my changes? That is a request. I need to decide whether I accept or reject. I need to make that decision whether I accept your request to pull your changes or not. That is how we will work. What I will suggest is without worrying about the virtual machine, don't worry about this quite yet, you can actually make these changes right in the browser. I'm going to shut down the VM. You can go to GitHub and fork it and make the changes right in the browser. You can create a new file like that. Create a file a.txt, b.txt in your fork. Please do that. Don't have to wait for the VM, don't need the command line. You can purely do that just in the browser, just like this site shows you. You can basically fork and start making changes. Create c.txt, c-d-e-f, and I would like you to create conflict, meaning at least two of you should create c.txt. That's what I want because that will create conflict in scenario. I want that to happen because then we can then discuss how to avoid conflicts and how to work through that because in real life this will happen. People will work separately. They will create changes and they will create collision or what I would call conflicts. You want to avoid conflicts and how do we do that? I'm going to demonstrate that. I would like you to actually fork this link that I gave you that, where is that? Slack chat should have it. Please fork and then make a change like create a new file, for example, and call it c.txt and then commit. There's a commit button at the bottom, commit new file. That should be available to you. Then once you have that change made, I want you to request a pull, which is called pull request. You will see that. As soon as you make a change, it'll ask you, do you want to make a pull request? Please do that. That's what it boils down to. It says a request to pull your changes. You want to actually send me that request to pull your changes and when I see that request popping up, it will show up here for me, pull request. I can then decide whether I take that request or not, depending on a team meeting that all of us will have and understand what changes you are making and accept or reject those specific changes in the commonly agreed upon location, which can be this. The team leader will typically decide that you will take this change, not that change, and understand what needs to be put together. If anybody who's doing this on GitHub, please click, fork, make a change, send a pull request. Anybody? I need to create an account. Okay, that account should be like a two-second operation on just go through your email, sign up, and once you have that email, paste your login name in Slack chat so I can add you to a team here. We'll do the next exercise. The next exercise will be to work and have a membership to a team project. We will be able to do that subsequently. That's our next step, but let's see if we can establish an account and fork this one and make a change, create a new file, send a pull request. That's the idea that we are working with. I'll give you a couple of minutes to finish that. It should be quick. One thing some of you will run into a problem is that GitHub wants to authenticate your email. They'll send you an email message in your inbox. You want to click through that to come back for you to be able to log in successfully. That might happen. I'll give you a couple of minutes to do that. Two commits, pull request yet. Okay, there we go. I think Shiv has forked it. I see that two of you have forked it, Shiv and David. You have forked. I think you are proceeding with a created CDOT TXT. You should now be able to request a pull request on that. It should be really simple. At the bottom, there should be a button to send a pull request. That's where I will receive that request here. It's fairly trivial. You should be able to find it. There should be a button to say create pull request or something like that. I don't see one. Okay. You may want to share your screen if you like. Okay, David added one more file called m.txt. That's nice. Right when you see the file at the bottom should be a green colored item that says generate a pull request. I am seeing your screen right now, David. What you should be able to do is go show us GitHub instead of this screen. I'm seeing your Slack chat and not seeing your GitHub yet. How's that? Not yet. Seeing a blank screen. It's hiding behind. This is what GitHub, I think, is. Hiding behind. I've got it on the screen that is green. Let's see. I don't see it yet. Okay. You have to minimize your Slack chat for us to see your Chrome browser or whatever browser you're using. That should do it. How's this? Not yet. You're still on Slack. You have to minimize your Slack chat. I did. It's not refreshing. Let's go disable. Okay. Now, I see your face. Now, I see. I don't see your screen again. Don't see your desktop yet. This guy. Yeah. You started screen sharing and I can see your GitHub. You can, yes, so right in here somewhere, click on the word alphabet and the one changed file. You see one changed file in blue color. Up here. No, down. A little bit down. A little bit down. One changed file. Correct. Can you go back to your alphabet, the word alphabet, the big alphabet word there and let us see. Yeah. You have a pull request button right below the green item. Pull request. Okay. Sorry. Yeah. Here you can create a pull request and send one. You can request, hey, will you please take my changes? That's how you describe to the team and the team will review your changes in a team meeting classically and you create the pull request and you send it over. That's pretty much it. You apparently have created a pull request. You can see it on my screen that I am looking at your pull request. Here we go. I received this request from David Demons. It says, please take C.TXT. That's the message. I see that David has sent us two files. One is C. One is M. We will review this in the team meeting. We'll find out that this file looks interesting. It's a good change. M.TXT. And so I would like to take that and I would like to actually review those changes and maybe make it approve or maybe request for the changes, things of that nature. We can do that collectively. In a team meeting, we can say that, you know what, we might take your change M.TXT, but we may decide to not take your change C.TXT because C is not capitalized. You can go nitpicking like that, but that's how people do, right? So we understand that this is lowercase. It should be uppercase. So we can make a note back to you saying, you know what, this should be actually capital C. We can fix it for you and change. And so we can modify that, make it capitalized. And now I will review those changes and approve them. And so we can do it that way and say, review changes, approve them, submit for review. So we have that and then once we have these things, I renamed that file from lowercase C to uppercase C. That's the change in your pull request that I made. So since I want to capitalize all these file alphabet letters, I did that. And now we'll share it with the whole team and show it to everybody. All of us agree that this is a good change. We got C, we got M, and we renamed C to capital C. And now that's a change that I want to be able to take. So we discuss in the team and say, you know what, let us take that change because it looks good because it looks exactly what the customer wants. So we will merge and confirm. And so when I confirm, my original product will have A, B, C, and M. All of these guys are now available. And now you can see that I can go back to my machine here and say, git pull. And when I pull, you will see that in my folder, I have A, B, C, and M all showing up. I was able to receive those changes thanks to David. I can also see my log. My log shows me that it begins with Neelesh adding A.txt in B, A, 6, 2, D. Then Neelesh adds B.txt in this change, A, 83, F. Then David Thiemans adds 3C.txt in this change. And David adds, in this change, adds M.txt. In another change, Neelesh changes from lowercase C to uppercase C and then merges pull request from David. And now we have this 7A53 as the top-level entry with four files showing like this. You can also see the same thing visually if you go to open that visual software that I showed you. Here is how it looks like. And you can see these Tinker Toys again. Let me see if I can make it a little big, I think. Do you see these things like the blue colored and the magenta colored dots here that I'm clicking on? Yeah, I see them. That is an illustration of the graph that I talked about early on. You can see in here that this illustration is actually the description where the blue dots indicate changes by Neelesh, one, two. And then the last one here, whereas these are in a different branch, they are a fork away from me. And David forks that and goes on a different track, makes changes. And then we merge them all together back here. And that's the idea behind collaboration. So we have a message, mine says there isn't anything to compare. Tyler, can you show me your screen, please? You have a message, Tyler. So please share your screen and see if we can see what you are. Let me also go and see if we have a full request pending. No, so there's no full request here. So Tyler is projecting his screen, I guess, or maybe not yet. But Tyler, please project your screen so we can see what you're dealing with. And that will help us understand what we should be doing forward in terms of helping you. So back in our Git discussion, I'm going to go back to the whiteboard again, here at the whiteboard. We actually did exactly what I draw here. So we have this change I was making here, and David went on the side, he forked it, and he created C, created lowercase C, by the way, and then m.txt. And then I said, you know what, this lowercase C should be uppercase C. And then I bring that full request and I accepted it after that little change. And so here is Tyler showing us his screen. We are looking at Tyler has to fork, please, which you have forked. So Tyler needs to go on the alphabet folder in the middle of the screen and then click the fork button at the upper right corner. And then it creates a fork on your account. You need to create a new file, that one, create a new file, call it something, new file, whatever you want. And then you save it, and at the bottom there is a commit message. So you commit the file. And when you commit, it will ask you to create a pull request. You can do that. If you say new pull request, and there you should be able to create that pull request and send it over to me. And Tyler is creating a pull request right now that I should be able to see as soon as he hits the green button. I should see a pull request pop up right here. And there is a request from Tyler. The question I have for you, are you able to see these two screens side by side with my screen as well as Tyler's, or is it something that only I see? No, just your screen. Huh, interesting. I see both, which is kind of strange. You should be able to see that. Yeah, I don't know. I have two monitors, so I see both screens as well. Okay, okay, okay. I see the problem is with two monitors. So I have multiple, and that's the reason why I see all of it. I see all your faces as well as screens. And if all of you start projecting screens, I should be able to see all your screens as well. But yeah, you need multiple monitors for that, or maybe little windows. So we have this. That was my issue. I didn't create the file first. I was trying to make a pull request without any files. Okay. Yeah, you had to have something to request before you create a request. So now you have created this pull request, and we will collectively review in the team. We'll look at the file you have sent. It looks like a good file with a capitalized T and all that good stuff. So I think I review the change, and I approve it, and I like it. And then we'll go to a team meeting and review that pull request, looks okay. And I think when all of us agree, we just merge the pull request and confirm. And that happens. We should be able to go back to our alphabet folder, and now we have one more file with created by Tyler. So we can now go back to our computer and pull pretty much like here. So when we pull it, our Tinker Toys graph diagram should show updated with another fork like that. The blue is mine. The purple is Tyler, and the yellow is David. So see the forking happening and merging, forking and merging. That's how teams collaborate. And you can very, very systematically adjust every single file account for any change people are doing across your team and make sure that you are tracking every single thing. At this moment, you can decide to go back to any commit hash and see and inspect and deal with whatever changes they may have made. For example, if I decide to go to this commit called 4FBC, that number. So we can go there and you will see that this file called c.txt becomes lowercase. You will see that happening. If you go to that point in time of 4FBC, let's go check it out. So check out 4FBC. And now here, lowercase c. That happens because that's what David had at that time. You can see that my head, the play head on the turntable, you know what a turntable is, I am assuming. At least some of you do. And so a turntable has a play head that moves and changes to a song you want to play. And you can see that in the current diagram illustration, my head is not on the top. It is on 4FBC as shown by my mouse pointer. Here is my head. I can move my play head according to my desire. And that is what is going to indicate in the folder structure. The state of the folder where my head is, is what shows. I can change my head to something like what Tyler did, t.txt. So we can go there to A411. And so here we go, check out A411. And now we have t.txt because Tyler was working with my original fork, which had A and B. He added T. So any changes by David are missing because that's how the graph is. My head is the purple head here. It is not on top, one step below. It indicates changes by Tyler, this t.txt that includes changes by me, which are the purple line, includes B and A. So A, B, and T. And the head shows what you have, A, B, and T. You can change the head visually by basically double clicking and it changes the head. This software is also free. I should give you a link. You should be able to install it. It is available for, I think, Windows and Mac. And there is also another application called GitHub for Desktop, which is also good. And that GitHub for Desktop is from GitHub. They are not open source, but they are free. So these guys are, I like the visual representation of the graph here to illustrate the point is that we can traverse through the graph very easily by clicking on any of these hashes and go to that point in time as to what was David doing at this point in time. Let's go check it out. Click, click. And it says, are you going to detach the head? And I said, fine. And here we go. David was working with A, B, lowercase C, and M. We can change our head to capitalize C and click OK, and it becomes capitalized. Excuse me. So the underlying idea is you can use this visual tool if you like, or you can just use the checkout commands like this. They all work the same way. The idea essentially is to be able to traverse on the directed graph to go back in time, go forward in time, and protect history of what our team has done collectively to produce the final outcome. The final outcome is what the customer wants. If you want to give it to the customer, the final outcome will eventually arrive if all of us keep building and getting to a point where we finish this exercise. But that is just a dummy exercise. I'm not really interested in all of us creating A, B, C, D all the way through Z. That's not the point. The point is to illustrate this concept of how Git is used in real life to be able to collaborate across team. You can use the command line, use this tool, the software tool you have, or use GitHub like websites. GitLab and Bitbucket, they all operate conceptually the same way. They look and feel different, but essentially the same thing. They do basically under the hood run these things, these commands, and you can traverse on your Git log as you see all these things. You can basically traverse the tree as you feel like and make changes of your software. Oh, Dave has typed this called from Dave in there. That was not according to design. But yeah, the files need to be empty. So here David says C.txt from David. That's a change. I want to delete that. And then here M, I want to delete to keep it empty. So all the files should be empty. Now we have made changes to the folder structure. And so what I need to be able to also do is now check how visually it shows. There is a question, Rob Shiva, I will answer that, give me a second. Here you can see that I made little changes to the folder here. So our current state of the folder is different from the master. You see the uncommitted changes pop up. These uncommitted changes indicate deletion of the line C.txt from David and deletion of the line from Dave in the M.txt and deletion of empty spaces from T.txt. So these changes, I need to accept them. So I will stage them by click, click, and click. This is basically the Git add command happening. When I'm adding it on the stage, the files move from the unstaged area to the staged area. So it moves the stage from here down to the stage. You can unstage them. So it brings them back down, unstaged. You can stage them all. It goes up again. And then you can toggle around like this, but that's just having fun. The idea is to be able to stage first and then commit. You can visually commit like this. And here I'll say I am cleaning up the files. And then I can basically indicate that commit message here and commit. Now this cleans up the file. Now my files are clean. They do not contain anything. They're empty. Exactly how I want. Now you can see that my master is one ahead of the remote. This remote that I have here contains from Dave. This c.txt contains from David. So this folder, the last commit I have here on the github.com is a98 delta, whereas in our folder, it is not a98 delta, but 5039. So I need to push. This push is already indicating that it is one behind, so we should push it. So I push and it goes to github visually this time. And you can go back to github here and refresh to see that you are now the latest commit, 5039. That shows up and your visual indications are indicative of the fact that I have added one more tinker toy in the directed graph that takes me forward. You can also see the same thing here in this command git log shows you cleaning up the files, 5039, the same thing. So a variety of ways to see the same thing, terminal, this application software, and the github website. All of them basically do the same thing. Now there's a question here, which is, is git efficient in resolving conflicts and merging? No, not at all. Shows old and new side by side like TFS does. You are asking about shows, so the showing part is actually a visual piece, which is the software, which is not git. It is source tree. This shows you what changed here. You can see the changes. As you can see, plus shows green as added, minus shows deletions. So the red color shows deletions. You can see these visually also, but this is a visual representation. That is not git software. Git software is this, the command line called git. That is what will show you changes between commits, between working tree, et cetera. You can see git diff, and then see the changes across as you play with. If you make a change here, for example, I go m.txt and write something silly and save. You can see that git diff will show me that change. It will show me that m.txt had nothing, but now m.txt has this silly item. You can see it visually by git diff command, and it shows you beautifully. This is git. That software that you saw, source tree, is not git. It is source tree. It also shows you visually the changes I made. I added some ASD ASD here. Visually, you can see that. You can discard that and find it cleans up. It's also visual again. You can see that my git diff cleans up. The changes are gone. The file is clean. m.txt doesn't contain any ASD ASD anymore. We are able to clean that up just like that. These tools like source tree and GitHub and visual team foundation, whatever that Visual Studio is, they're all visual representations. Under the hood, they all function like same. By the way, TFS is almost as good as git. However, let me tell you something, which is Visual Studio git support. Visual Studio supports git like a first-class citizen. You can see that here. Git is now included with Visual Studio, I think, for the last year or so. It is a part of Visual Studio application itself because Microsoft adopted git completely. In fact, they are changing away from that software that you used to use before called Perforce, which is also known as Source Depot. They are changing away from it to using git inside Microsoft. That is happening, which is a major dramatic change. They're using git and also pushing team services. Some people who have a license to Microsoft software, they use this if they want to, but they don't have to. You can use git with Visual Studio and it works. It is fully supported across multiple companies, multiple product types, and it is open source, which is why most people get to use git. That is why we are focusing on discussing using git in this exercise we just did. Let's move to the next step. The other idea that I want to be able to discuss now that we have at least some good decent understanding of how do we use this version control system to now moving on to actually using a set of steps to construct an application that I want to be able to deploy on some platform as a service. There are many solutions available out there, many, many. It's mind-boggling. You can go to Amazon and find a solution. You can go to Microsoft and find a bunch of solutions. Amazon has, let's see, login. They have a thing called Beanstalk. That is a classic platform solution, and I'll describe what that thing means. I think I logged out or what? Log me in again. Come on, log me in please, AWS, please log me in, account, management console, sign in, and get me a token, and let me in. Here I am in Amazon. You can see here that I have access to what they call Beanstalk thing here. In the Elastic Beanstalk, let's go see what that does. It's a very simple solution. In this Elastic Beanstalk, I seem to have, let me begin with a different region. Here, I think this is better. Here Elastic Beanstalk, what they do is they give you a platform. What does that mean? That you don't have to do any work. That's what it means. You don't have to work about do anything other than writing your application. You write your app, and you just put that in a Git repository and throw it at Amazon. Here, take my app. That's all it takes. You have to select which type of application do you want to run here, and that selection happens like this. I want to run a Go application, which is Go language, Node.js JavaScript language, Java language, Ruby language, Tomcat, which is a Java-based container, a PHP language, Python language, or.NET, C Sharp-based, Microsoft Windows-based solution, or some other pre-configured solutions here, like that. You can choose that I want to run a Ruby app, click, and then you click the blue button. That's it. I mean, there's nothing else to do apart from it will do everything else needed under the hood to make your application run. Now, here, it tells you that it will create an elastic Beanstalk. They have named it the word Beanstalk for a specific reason. This I think is you know what a Beanstalk is. This is what it grows elastically. That's the idea. It grows and shrinks and things like that, so you know what a Beanstalk from a children's storybook is, that's the idea behind Beanstalk is it is elastic, it grows and shrinks, and they will manage the entire platform for you. All you need to do is these three things. Select a platform, which is one of these guys, and then upload your application, and then that's it. Done. So, you can select your platform among any of these languages, so it basically boils down to using the language of your choice, which means, where's my whiteboard, whiteboard, there it is. So, which means, you know, this platform needs to support the software that you intend to throw at it. You have this piece of application, right? You want to throw it over on top of this platform it needs to run, for which you have to understand what does this application require for it to run. It might require, say, PHP, and if this platform doesn't support PHP, you cannot make it run. It has to support that language. If you write this language in Ruby applications, you need to have underlying things needed to make it work correctly, and if the platform doesn't support that, you cannot just take this application and throw. It may not work. That's the idea behind here, hold on, behind here, selecting a platform. So, it boils down to choosing the right platform. And so, let's take a look at a couple of examples. Here is one. This application is what is, I think, runs half the world's internet websites called WordPress, almost about quite a large number of websites run using this software. If you try to download that software, you can get it from here. You will also see that it requires certain things. What does it require? It requires these things, PHP version 7 or greater, MySQL software, and HTTP support. It requires those things. So, to run WordPress, the developer is telling you, you need to have these things in place. So, now, let's go here and find out if I want to run PHP application. Am I getting PHP 7? Yes, I am. And am I getting MySQL version 5.6 in here? Let us see. They should tell us. They should tell us that they are going to give you a MySQL database, but I'm sure they do. They don't describe it here, but that's a problem. They should say that I actually provide you with a database solution. They don't seem to indicate that. And requires HTTP support, which I think Amazon does, but again, they're not calling it out. So, the idea would be to look at a given application and understand its requirements, and then check with the platform provider, do you support those requirements? Another one, if I want to create my own Twitter.com, my own Twitter, like this, I need to understand what does it take to run a Twitter application. 10 years ago, Twitter used to run using this software. And this is a framework to allow us to run Ruby applications. What does that mean? Going back to the whiteboard again, it means if you want to run your own Twitter, I mean, you create something that looks like function like Twitter and allows people to tweet and other things and follow and all those concepts. You have to write some code in this language, and then you make it easy on yourself to cut down on the work that you have to do to write this application. You will use some ready-made tooling. So, ready-made tooling. Ready-made piece of code written for you that you just use. That is what this Ruby on Rails is, and we will use that as a dependency. So, we will actually use something that is ready-made for us. It is called Ruby on Rails, and it is written in Ruby language, but it simplifies the work of the developer that writes this application, for example. And we will, by the way, write an application ourselves pretty soon using Ruby language and using Ruby on Rails. And we'll create one, and you can see that it is trivially easy. The reason it is easy is because of this guy. His name is David, and he created Ruby on Rails, which is this software. And what he has done is written most of the code for us already and provided to us in open source as a platform, which is this platform, Ruby on Rails platform. You can read more about it, but we'll just get to use it. It's available here on GitHub. That is this software. It has 3,000 contributors, 306 releases, 61,111 commits, lots of commits. It has been an immensely popular application with 13,923 forks, so it's an impressive number already. And that is what we will use. This guy has created that for us, and we will make use of this person's software. He has done the grand work for us. All we need to do is to use and follow his methods of doing things, and that's the logic behind this concept of Rails. It is like guardrails. As long as you fit in the model, you will run like a train or like a fast-moving vehicle if you fit those rails. If you write your application in line with what DHH suggests is the method, the Ruby way of doing things, the Ruby on Rails way of doing things, if you fit that idea, you will be able to finish writing your application at a short notice really, really quickly. And that's the kind of amount of grand work that he has done already, and it is now open source already. And that's one of the things that developers tend to like is to get quick results out available to the market is to reuse and stand on the shoulder of giants like this guy, DHH, for example, and reuse their work to build something quickly. As long as you fit in the principles or the guardrails that he has defined, it will work smoothly. No problem. If you deviate from that, it's a different story. If you fit that model, it will work. That's the idea. And so if you want to write a Ruby on Rails application that will use Ruby on Rails, you need certain things. What do you need? First thing, you need Ruby on Rails. You need Ruby language. You need some operating system that will run Ruby. And then like Ruby on Rails, there are other additional pieces of software that you might use to construct your application quickly and efficiently. Those additional pieces of Ruby software are known as gems. They're packaged up and ready to use. These gems are stored in a list. The file is called gemfile. You may have seen one of that in an example before. It has a list of things that are needed. These are individual gems. They are available in the open source. You can make a reference to these things, to these gems that I'm talking about. And these gems are stored in a place called rubygems.org. And all you need to do is to list them out in a gemfile and use it. Ruby on Rails is also a gem. So you just list Ruby on Rails in the gemfile and you're done. Bunch of other gems we'll use. And they will all be listed in the gemfile. And you can get them from this location. And by the way, there is a tooling that helps you accumulate these gems and use them already. This is the Ruby way of doing things. Very, very similar is other languages. For example, there is Java language. And so you want to write a Java application. A simple way to use that is to use a ready-made framework. And there is a Spring framework that basically operates pretty much like this. You use the Spring framework to easily and quickly create your Java applications and this framework is open source. You will also call out other things that you have as dependencies to help you construct your Java application quickly and efficiently. Same thing applies to another language, say Python. You want to create a Python application, you will use underlying framework which helps you build your Python application quickly and efficiently. That framework is called, there are many, but here's one of them, it's called Django. Not the movie, but the Django framework. This movie, sorry, this framework is written in Python. And then you have to have other things that go along with it. And those things are called dependencies. And these dependencies are listed down in a simple plain text file called requirements.txt. You basically list out whatever you need in terms of these dependencies in that file and then install it, pip install requirements.txt. And it will install all these things from you, from a location called PyPy. Let me just get the spelling right. I think it is PyPy. This is the location where you can get Python package index, a bunch of packages available. You can just list them out in this file and use them along with the Django framework to create your Python app for you very quickly. And so goes the story with.NET. You want to write a C Sharp application. You use Microsoft's.NET framework and a bunch of other C Sharp packages. You put them together in a list in Visual Studio and you write your C Sharp application that uses the.NET framework underneath that Microsoft provides. By the way, this is also open source these days. It is Microsoft's product and yes, it is open source now. You can find it on GitHub. And you will write a C Sharp application pretty much like that. And so the theme is very similar across all these languages. You have Ruby, Java, Python, go bring your language. The same method applies. You have a framework under the hood that you want to use to simplify your life. You have some other dependencies that you will list out in a file and you will grab them from some location on the internet. All of this is open source. You write your program, your software that you want to create that leverages all this beautiful work other people have done already so you don't have to reinvent the wheel. That's the common idea. You write your code, but you don't do all the grant work these days. You will rely on and stand on the shoulders of giants that have gone before you instead of reinventing the wheel. That's the idea. So we will do that exercise now to actually write our own application using this Ruby on Rails framework, using Ruby language. And we will go somewhere to a platform and say, you know what, Ruby, please. And they will give us a Ruby language, appropriate dependency that you might want and whether you want the underlying infrastructure to be load balancing and auto scaling or not. This is the not, it will not scale, single instance will not scale. If you say auto scaling and load balancing, it will automatically scale for you. And they will basically do all the infrastructure work but give you a place to run your application which you decide to be in Ruby language that is one decent platform as a service. But these, these are not the people who originated that. These guys, Heroku, actually originated this idea long, long while ago. And they created the, one of the first platforms as a service. It's a very well established solution. We intend to use this to create an account here should take quick and don't have to give a credit card, just create an account that should do it. And we will, we will begin with an exercise. Let's see where that exercise is. So here we go. And you should be able to find it in this listing somewhere. Yeah, module 15. That's where it begins. It begins here, create a Heroku account. That's where it begins. You can do these exercises in the virtual machine already. Which is this one. So you start it up and you should be able to proceed in that direction very easily. And so begin from this point onwards in the Slack chat here. And we should be, it is trivially simple as you will find, just a matter of understanding where things are and following along that guided rails, which is a guard rail basically. And you follow that direction that they provide you and you will have an application running in pretty short order, very, very quickly. So we should be able to do that. I'll put this on this side here, put that browser on the other half like here and proceed. The first thing, click and see if you have Heroku tool belt. I think I have installed Heroku tool belt already, already. So you should be able to skip this step, any install Heroku tool belt. You probably don't need to do it because it's already there, I suspect. Heroku. Not found. Okay. That means it is not there. Yeah, it's not there. So we'll install it. This is the way to install it. Click copy and paste. It will install Heroku tool belt for us. And it says we need to get Pluto password, so the password is log genius. And so it is installing the tool belt, which will allow us to configure our machine to interact with the Heroku solution. This is the solution that I'm talking about. And we can log in here, just like that, log in. So create an account here if you don't have one and log in. I don't have to give them a credit card number. Not necessary. As a trade off, what they will do is to make sure to, let me see, where do I go here? So the point I'm trying to say is that we are going to use this service from this company. They will give it to you for free for development purposes. They will give you a machine where you can, actually, they give you a platform where you can throw your application. And this platform will run for 18 hours and then sleep for six hours and then wake up again after. So they give you a six hour break if you are giving it free. You have to pay money for it to run continuously. That's how they have designed. But for our purposes, we have no problem. We just maybe spend a couple of hours or maybe more. But we're okay. I mean, generally, okay, free is good for learning. So use that. As we develop and learn something, we should be able to use this platform comfortably without having to spend money. That's the idea. So we have installed that toolkit and it is there running right now. So I think something is wrong with Heroku right now. What is this? The view is not good. I don't see what I expect to see on the Heroku website. What is going on? Mobile zoom settings. Okay. Yeah. So here. Yeah. Now I see what I wanted to see. Okay. So back in our discussion, open an account with Heroku, install tool belt, and when you have an account, you should be able to log on to Heroku website using the tool belt. How do you do that? You have this tool belt installed on the virtual machine. You should be able to say Heroku and it will tell you that it is installing the command line interface. And it says, okay, give me your login name, please. So it is expecting you to provide your email address that you use to sign up with Heroku. So I'm going to give them my email address right now. And my email address is this one. So I'll type my email address and type my password. And it will allow me to log in onto the website using my tooling here, the Heroku tool belt. This shows some errors. Yeah, I can ignore those errors. I have no reason to worry about. But what I did is pretty much logged on to this website called Heroku Auth Login. You can type it like that. And go like this. It will ask you for your email and your password and you will be logged in or the password is not valid. Okay. I need to type it again. So email address and the password, let me grab the password, copy the password, copy and then paste it. Yes, I logged in. Login is successful. Next step, what I want to be able to do is once that application Heroku tool belt is installed, what we want to be able to do is establish SSH connectivity between our machine and the Heroku service. This is something that will help us understand and without having to type these passwords all the time. That's one thing that I want to make sure that we do is that we have to add our keys to Heroku. So we have a key pair already here somewhere here in our SSH folder. That's where these keys sit. We want to send the public key out to this key needs to go to Heroku. We can take this, copy it manually and give it and paste it on the Heroku website. We can do it that way or we can go use this command. So when you use this command, we'll just run it, keys add, it will take our key. It says if we find a key in your machine, it finds a key, found a public key in this location. Would you like to upload it? And I'll say, yeah, please send the public key. So it goes. So now I'm connected with my Heroku site. The reason we are doing these Heroku things before we even begin building our application is the thing that I want you to understand is that we want to create a new project in a fashion that actually is ready for our customers at every single moment in time. The customers would like to receive some application from us. We are beginning our product development. We want to be able to produce something that works here on the initial machine in a fashion that the customer will actually receive. The customer will see it live on a production machine or a production service. In our example, we intend to use Heroku. So we are basically beginning from that end in mind. Our end game is we want to run our application here. So we are basically beginning everything with that end goal in mind. Our end goal is to run our app on the Heroku platform when it goes live. And that is the reason why we are beginning with that step is to do everything that we want to be able to do is even include the initial testing that happens beginning on Heroku directly. Don't want to run it anywhere else. And even if we do, it needs to run on Heroku every single time as we go along building so that we don't miss a step in the end goal as we go building our things as we approach our customer. Our idea would be to do every single step along the way that meets our live production scenario in the end goal in mind. That's the reason why we begin with Heroku. You can actually write an app without even touching Heroku, but that's not the idea. The idea would be to stay focused on what that end game is and build exactly to that game in mind, nothing else. So with now having done the public key that we have given to Heroku, we should be able to proceed to the next one. In that step, what we will do is beginning creating an application. Now this application we need to write is a trivially simple application, so it's not rocket science. We are going to use Ruby language. So we have a Ruby installed already here. I think Ruby language should be here. So we have Ruby version 2.3.3 already installed. Next up, we need to get Rails installed. We can get Rails like this. You'll go and grab that Rails gem. So you'll say, get me this version of gem. So we'll go and grab that version of gem, and it will go to Ruby gems and install the Ruby gem called Ruby on Rails. And it finished. It installed the Rails version 4.2.7.1 just like I said. Now we have to rehash our gems so that our Ruby and Rails command will work. If you type the Rails command, it may not work, it did work. But I think it's a good practice to rehash the gems. So that's where this command comes into play, to rehash our Ruby, sorry, not this command, clean, R, B, E, and V, rehash the gems that we have installed so it gets a fresh listing of all the gems and makes them ready to run. Now what many people in the program do is do this exercise multiple times. And that is why we have this step here called delete any stale folder named MyApp. And that is not necessary when you're doing it the first time, but people do it repeatedly over and over again. And so I always suggest that you remove the folder that you may have in the previous attempt. And that's why this step is unnecessary. But I just did it. But I have it written down here primarily for helping people who are repeating the exercise to get the concept right. And now we want to make sure that our machine here, this one, is exactly the way that Heroku is designed to run application. We want to run our application right here in this location. And we want to make it identical for all practical purposes to what Heroku is using at the end game. So let's talk about this end game, and I know Heroku uses a database called PostgreSQL. In our machine, we should basically mimic what they have so that when we go live, we should be able to produce our development work exactly in line with the end game. And that is the reason why we are installing this database that Heroku uses. So these commands will actually install that database called PostgreSQL in a couple of steps. So here is one. And the next one would be that one. That should do it very quickly. It should not take long. And then the next command is to actually install the database. And here it goes, installs it, and we are done. Now we want to create PostgreSQL role and a database. This is going to basically create a username to use the database itself. That step helps us in making sure that our application will be able to interact with the database. So what does that mean? When you have an application, let's say this app that you write, the application needs to go to the database and say number of cats equals zero, number of dogs equals, it was zero, but now it is one. You need to make that change in the database. And this is what will be stored in the database. And so you need to have a user password for the database updates to occur. And this username password is on the database itself. We are using the PostgreSQL database, for example. And so we want to be able to make those changes in number of dogs in the home right now from zero to one. And then when the dog goes out on walking, it becomes one to zero, like that. We want to be able to modify our database, for which we need a username and password and a data structure to store the data here. That thing is what we need to create. That is what we are doing here in this example, in this step, is to create a PostgreSQL role and database. So here, this command will do that. We switched over to a user called Postgres. And at that time, we can see that the command changes from user to Postgres. Now that we are logged in as the Postgres user, we should be able to create a new role for the user user. Our username is user. As you can see, the username for this user is actually user. So we want to create a new role for that user. We can basically go like this, create user interactive, and hit. It says name of the role to add. And our name of the role will be user. We will say user is the name of the role. Shall this be a super user? We will say, yes. I want this to be a super user so that the user can actually create databases, create roles, create tables, and update and modify data structure for cats and dogs, for example. Number of cats, number of dogs, create this table, create the database, create a user, password, all those things. We just gave a super user permission to our user called user. That's what we just did. Next up, we want to create a new database to store our detail about our cats and dogs. That's what we will do in this step. We are basically creating the idea here is to create a database by this command. We are essentially creating a database in our Postgres database. Now we have created a role called the user like this and a database called my app development. After having done that, we can come out of this Postgres user completely by exiting. So we exit. We are now back to the user user. Now we have to install a gem to manage Postgres database using Ruby language. This gem is called pggem. This gem is available on the Ruby language website, Ruby Gems website. This website called Ruby Gems contains all the gems that community has created including Ruby on Rails, which by the way is 85 million downloads. You have the other gem that we are talking about called pggem, which is another gem. This pggem is 31 million downloads. It is the driver for driving Postgres database using Ruby language. That's the gem I want. In order for me to install that gem called pg, I need to have a library included. This pqdev library is needed for the gem installation to succeed. For this step, I need to install that pqdev library, which will happen like this. Now I can install my pggem. These are basically collecting a bunch of dependencies that I need for my application to run and I'm making my development environment identical to what Heroku does. They follow these steps to install pg. We will follow those same steps to install pg on our machine. We have successfully installed the pggem. Now we'll create a new application. You will find it amusing if you have never created an application, is how trivially simple it is. So far until now, what we have done is basically created a method for installing Ruby on Rails using a gem that we have on our gem command. We use the gem command to install Ruby on Rails, so Rails got installed. We also installed the PostgreSQL SQL database on our machine. This is the database software, I should say. So we have that installed. We installed libpqdev, so the library was called libpqdev. This library is needed for the pggem to be ready. This gem helps Ruby language connect with this database software. So we have this gem also installed. And now we are basically trying to mimic how Heroku runs on their cloud. We will run the same exact set of things we need on our machine, just like Heroku has. So basically matching exactly what they have. This reduces friction. As you create something here, it will just identically work on Heroku. You don't have to modify something here and then make it work there and, hey, why doesn't it not work there and why work? It works here, not there. We are trying to cut that down by basically mimicking our endgame. So having these dependencies in place, we are now in a position to start creating our application and it is ridiculously simple. It goes like this. Create a new application and we will do exactly that in our terminal. And we'll say Rails new application called MyApp that uses database called Postgres SQL. You can use any other database if you like, but we are going to use exactly what Heroku does. They use Postgres. We use Postgres, like this. And this will create a new folder called MyApp. This folder will get created and it will have a bunch of things in there. You will see what it contains. So we will create it. Off we go. And it creates a bunch of files and folders in that ready-made application is given to us basically thanks to DHH, this guy. And so this gentleman has created the application for us just now because we ran that command and it installed a bunch of dependencies also for us. Let us see what that folder contains. This folder called MyApp was created on January 28th at this time, which is right now. And we will open that folder in our Atom Editor. We should go into that folder also, MyApp, and then open that folder in Atom Editor. You will see a bunch of things already there. Bunch of things. Here. Lots of things. There is a gem file. It has requirements for gem and PG and SAS and this and that, a bunch of dependencies called out and all of it already installed because that's what the application does for us is to prepare our machine to make it run like a Ruby on Rails application. And that's the code that this guy has written for us. So we are using it practically by one line, creating a new application. You will see that this person has created an application according to the MVC principles. This folder might look daunting, but don't worry. It is not. You have to stay focused on the application folder, which is right here. In there, you will find a folder called model, a folder called views, and a folder called controller, the MVC, the same things, like model, view, and controller. Same things pop up again. The model will store details about our data. View will store details about how it looks like. And controller will keep information about how it functions like, MVC. That's it. These are the three things we need to focus on. Everything that is needed to make the application run is written for us already by this guy. He wrote it for us. We don't have to worry about it. We can, of course, read it, but don't have to worry about it. But here, it is a good idea to stop this service. It may be running on your machine, so just make sure to stop it. It might conflict. I think it is not running, but I'm just running to spring stop to stop it. It is not running. Good. You can move on. Next step is to understand MVC, but I think we do already understand, so we can skip this segment. MVC is basically describing what MVC is, separation of concerns. Next one is to basically create a logic, and this logic, we are not using the cats and dogs logic. We are using an even simpler method, and to just open a page that says, welcome, the time right now is whatever the time is. That's the logic going to be. That's our idea. That's the outcome. The entirety of our application is that simple. It opens a page and shows the time right now is whatever the time is. That's the application that our controller will run. We had to write that piece, and it's just one line of code. We had to create the underlying infrastructure needed to generate a controller. Of course, this gentleman will do it for us like this command, rails generate controller welcome. It is the welcome controller. I want to run that command here to generate a new controller, which will create a new controller file in the controllers folder, by the way. You can watch it as I run it. You will see a new controller pops up like that. Here we go. We have created an application controller called welcome controller, and this popped up right here. We also have seen that it has created a view for us called welcome that will pop up in the views folder called welcome. This is the welcome folder. We also see that it has done a bunch of test units, helpers, and assets. We don't have to focus too much of our energy in that direction. We just stay focused on our view and controller, but it has done the things needed to make it easy for us to test some helper functions, some create some assets, some JavaScript office script, some SAS is created, CSS is created for us. They have done the work for us. We should focus on controller and view to get us going forward to show what the time is right now. That's the application. We'll proceed forward and then understand that it has created a welcome controller for us and a view for us. We will like to create a view in the view folder here. We have the welcome folder like that one. It is in the apps, views, welcome in that folder. We need to create a new file called this name. That's an empty file we need to create to begin with and put that inside the welcome folder right here. We can do it through this command or we can do it in the atom editor either way. I want to use the atom editor. I will actually create an empty file and save it in the location applications, views and welcome and name it index.html and erb. Erb is a Ruby template and we'll see what it means just a moment. This is a Ruby template. We are going to save it in that folder. Here is our empty view. It will show nothing. You want it to show something so we'll add this code in there. This code shows the time right now is time.now. Hello Cloud Genius. The time at this moment is time.now. That's it. That's the only piece of code that we are really writing. This is it, one line, time.now. It's a Ruby function to get the local time at the machine at the browser and show the time at that machine at that moment. That's it. It is going to show you a view that says, Hello Cloud Genius. The time is whatever it is. You save that file. This is the view you create. Now we have to also have a method or a logic to show the view. That piece is the next step and then we are done basically creating the application. The application should function at that moment. We have to enable a route to the welcome action. What does that mean? If you open this site, let's say Cloud Genius site, the route to the opening action is the index page, which shows you the front page. There has to be a route to open something like this opens the front page. This is what we need to define a route. When a site opens that you open with a welcome page. That is what we are really doing right now. In this action, what we are doing is creating a route to the welcome action. There is a welcome action already here called welcome controller. We also have to modify a route to that controller by going to the configuration folder and looking at a file called routes file here. In that file, you will see a reference to line number six that says comment. This hashtag means comment. It is commented, but the code is written already there for us. It says when you open a new site, you want it to go straight to the welcome controller and render the index view. You want to uncomment this line by removing the hashtag. That's it. That's the change in configuration you have to make to make sure that the application now uses the welcome route, which is the welcome controller and you want to save it and close the route file. That's what is described here. Remove the hashtag. It will look like this and you proceed to the next step. You're basically defining a route to go to the welcome controller. This is what should open. Now we have our application done. Our application should, when it opens the home page, should actually automatically open up our view that we have defined for welcome, which says, hello cloud genius. The time right now is whatever the time is. Now we are ready to run the application just like Heroku does. We can run the app by saying rails, start a server. The rails server and it starts the rails server and it is running. It says that you can visit that site at this location. We can open it up in a browser and go to that location, local host and port number 3000 and click and you should see that hello cloud genius. The time right now is whatever the time is. This runs. It runs on our laptop, but does it run on the on the Heroku platform yet? No, not yet. So we want to make it run there. This is running here right now in that rail server. So I want to break it, click and break, control C. Now that I have application running here, it runs locally. I want to make sure that I send it up to Heroku. How do I send? Git. And push. So what I want to be able to do just like before, we have our piece of code. If you want to put that in a Git commit, you have to initialize, then add and commit to make a commit hash and then add a remote and then push just like we did before. We initialized our Git repository. We added, we committed, then we added a GitHub remote and we pushed and then it was visible on the GitHub website. We are doing pretty much the same thing except that we will initialize, we will add, we will commit, we will add a remote. The remote will be not GitHub, but Heroku remote. And we will push. When we push, we will see it, we will see the code run. And here in GitHub, we see the code. Here we see it running. That's the difference. In GitHub, you will actually read the code. You will see the code itself, whereas if you push to Heroku, when you do, you will see the code running and you will see the outcome of the code executed. That's the difference in the two approaches. Conceptually, it is very similar. You can add a remote to GitHub and push to see the code. You can add a remote to Heroku and push to see it run. That's the difference. To add a remote to Heroku is what we will do next. Here in our current application, do we have it in a Git repository? I don't think so. Let's go check. Git status. There is no repository. So we have to create one. We'll do that. But before we do, there are a couple of things that we have to include in our gem file which are currently missing. And those things are to prepare your application for Heroku. So Heroku specifies in the documentation, they say that you have to have this gem and your Ruby version needs to be in the gem file. This specifically, this gem needs to be there. Right now, if you look at it, it's not there apparently. I'm going to open the atom editor, go look at my gem file. And I see that my gem file is right here. I will search for it and see if I have this Rails 12-factor gem in there. I probably don't see it. No, it's not there. So I need to include that. This 12-factor gem is basically making sure that you are following the 12-factor application model, this model 13 that you saw, this manifesto. We'll talk about that manifesto also in just a minute, is what this 12-factor gem does. So we have to include that gem, edit that gem file, and add this line. And also, our Ruby version has changed. It is 233 now, whereas this number says 231. So I think I should update that. I think my Ruby version in the machine here is 233. So the Indic instructions are 231. We should update that. So I'll update that quickly and also include those versions of 12-factor gem and Ruby versions both in that file. So I'll make it 233 and update the website and then copy those two references at the very end of the gem file. So this is the gem file at the very end at the bottom. We will go and include those two lines, which is one of them is about 12-factor gem. And the other one is a reference to the Ruby version that we are using here because we want Ruby version 233 to be used by Heroku as well. We are telling Heroku, please use the version of Ruby I want, not the one that you think I want. And so that is what this is going to do as we specify that, calling it out clearly. Dear Heroku, please use my Ruby version 233. Close. Save and close. So I close my gem file. Next I want to update. This update is needed because I included a new gem in there. So I will bundle update. And this will basically get the 12-factor gem included. And you can see that the 12-factor gem just got installed. Next we want to start using Git. So we will put all of this in a Git repository or there is one more, there's one more change. It says, make your app run for any user. Right now this application runs for the user-user. It is tied to our computer. Our user is running as a user-user. The username is user. This it runs as this user, but we want it to be agnostic. It should run in any other machine, any other computer, including Heroku. And so we want to disassociate ourselves from the user-user. We can do that by modifying a database configuration here, this file, or to make a change in that file. So I'll go to config database, config, and database. And in here, I will look for this line called username my app at the bottom somewhere. You will find it here, username my app. And so it says specifically remove that line from this file. And this line, username called my app, is tied to the name of the application, the folder itself. We don't want to use that name either, so it has to be agnostic. I want to remove this line, 84, delete. It basically tells that this database, my app development, should be run under a role of my app. Since you don't have that role in your database, we are removing it. Why remove that line? You described, I just told you why. With that line removed, we should have our database YAML file look like this. Let's go compare notes. What do we have versus what we should have? Looks different. A little bit. Let's compare notes. At the very top, we have most of these are comments. Their hashtags are comments, so we can remove them. And we have a first line that says default, which is matching, Postgres, Unicode matching, Pool 5 matching, development default, database, my app development, that's matching. These are comments, so we can get rid of them. And there are more comments. We can get rid of them as well. And so all these comments are gone. I made a mistake, so I'll come back, made a mistake, and did not delete properly. I'm deleting that one to align with what we have here. And there are more comments, so I'll delete them as well. And now you can see that our database YAML matches what we have on the website. Basically, we are removing all the comments and removing that one line that was here in between the two, in 18 and 19, we removed that, and we are able to save that file now. So database YAML updates, and we proceed to the next step, which is Git. So we're going to put all of this, all of this folder, complete entirety of this folder inside a Git repository. We know it is not in Git right now, Git status shows we don't have a repository. So we will create one, Git initialize, we will add everything into the stage, we will make a commit, and then check the status. Now we have a Git repository and everything added into the stage as well as committed. So now we have a reference, we have a Git log with a hashtag. This commit hash is EF60, whatever that number is. This commit is available for us to use, we can pass this to Heroku. And before we do that, I want to make sure that we are able to connect with a proper remote. So if you check the Git remotes right now, you will have nothing because we don't have a remote set yet. We want to make a place to run our app in Heroku here, somewhere here. We want to run it on this side, so it needs to have a place to run our application. We will create that place by running this command called Heroku create. And since we have logged in already using Heroku command line, we should be able to just run, oops, oops, oops, cancel, clear, Heroku create. This command will actually create a place for our app to go and live on Heroku and also create a remote connection with Git. So you will see at the end of this command, right now, this Git remotes show you nothing, but when you say Heroku create, it creates a placeholder for your application to go sit in Heroku and enables a remote connection. So I created that and now I have a remote connection. You see that there is this placeholder called boiling beyond 82969.herokuapp.com is a place for my website and the remote got a connection to that is also very, very similarly worded with a.git at the end. So here is a remote for fetching and the same for pushing is now connected to my Git repository. I can now push and when I push, you will see that my site goes live. Everything is this one command. So now click and push and it goes live. That's it. That's all it takes. So we don't have to even visit that Heroku website in here to see what is going on, although you can, but you don't need to. You can see that the command detects it is running Ruby application. It requires Ruby on Rails. So it uses 233 version of Ruby. So scroll back up 233 version of Ruby and that's how you specified it. So it is basically installing all the gems in Heroku for you according to your gem file that you pushed. So it is installing these gems right now, as you can see them, and it will exactly match the gems that you have here with what Heroku will have there. And at the end, you will have your application up and running on that location which is indicated in the remote. What was that? Boiling something? Boiling beyond whatever that number is. That is the location where you should be able to see your application running as soon as the Heroku build completes. Heroku is building your application right now, putting all the gems in place, installing your application and it says that it has verified the deploy and it is done. That means your push succeeded. That means you should be able to see the website in this location. Let's go click and here we are. It shows. It runs. Exactly how it ran here. It says, hello Cloud Genie, the time right now is whatever the time is. Now if I want to make a change and update my application, it is trivially, trivially simple. Here is how it works. I will now make this screen full and make a little change to my application. Why is it so slow? Come on, let's skip, let's skip. This application that I have, I want to make a change to it. I'll say, you know what, my application view in the welcome screen should be something that hello world instead of hello Cloud Genie, I make a change, very simple change. Save it. I just saved. Now you will see that my Git repository shows you that I changed some things, modified. This is the file I modified. You can see that my Git diff will show you the differences. It used to be in the red line, hello Cloud Genie, now it says hello world. That's the change I just made. I can see the change running here, Rails Server locally. I can see that it shows me hello world, but my Heroku is still at hello Cloud Genie. If I open up localhost and see, I see hello world. But when I go to Heroku, the Siri pops up every time I speak something. I don't want to talk to you Siri, so shut off. So this, where is that? Chrome browser. Yeah. So this site is, was it Chrome browser? Yes. So it says hello Cloud Genie on the Heroku site, whereas here it says hello world because I have updated my application. Now it is super easy to push my changes to the platform. All I need to do is, can you tell what I need to do in this application that I modified? I have hello world as opposed to hello Cloud Genie. What does it need to happen for my app to show the updates here and push it to the world outside? What do I need to do in here? In my git diff, I have modified something. What do I need to do to make this change go? It is actually pretty darn simple. It doesn't require too much work. Any guesses? Push from git? Yeah. Sorry? Push from git? Yes. So commit this change and push. That's all it takes. So I need to go git add, git commit, I edited to say hello world instead. Now I have made a change in git repository. So the git log shows two changes. One is the first one and this edited to the world. Now I can push, git push, Heroku master. You will see that the whole git repository gets pushed, but this time only changes flow and it rebuilds. So it is basically doing the same thing using all the existing gems that was already installed in the previous run, recompiles the assets and says deploy complete. When the deploy completes, we should be able to visit the website and it will show you what you have. Hello world as opposed to hello cloud genius. So it is doing that piece, launching and succeeded. Back here, refresh and we see hello world like that. It's loading. It is slow. It is free. So it is slow, but it's okay. It works. So you should see hello world. Now you think about what we just did is changing is pretty darn simple. Once you have the chain established, your team can keep working and developing your application and they will all be using multiple forks of it. You will eventually get together and have a team meeting, consolidate your changes. This needs to go to the customer. So all you need to do is now push and you go live. That's it. That's it. I mean, pretty similar to what we saw before. In our terminal, we were working with the alphabet and we had this tree open where we had people work together to construct these hashes, make changes, create and collaborate something interesting and you have the final Git folder in your Git control ready. And what you need to now do is push and you're done. All the complexity needed to manage your underlying infrastructure, your machine, your scaling, your deployments, your setups, all of this is taken care of. That's what platforms do, platform as a service. They simplify and hide all the complexity needed under the hood. There's a lot more things that need to happen here. They just hide it. They let you focus on your app development. So you and your team members focus on the app, focus on the application and not worry about the underlying infrastructure at all because you are dealing with a platform as a service and not about these things, not about anything else actually. As long as you're willing to pay them money, you're okay. So it's a trade off. Do you want to give them money or do you want to do it yourself here? It's really up to us. Well, what do you want to do? If you know what you're doing here, you can actually save up quite a bit of money by not using a platform. If you are a large organization, you may decide that you would rather spend your energy in running your own platform, thereby saving your developers with a lot of work. Yes, you can. And that's what we will do at the next opportunity, we will create our own platform to understand what it takes to build a platform and then go that direction. But the bottom line that the thing to think about is it's a trade off whether you pay them money. I think Heroku charges $33 for Dino, Dino is like a machine for you. And you will scale it out pretty much like that. So if you go look at Heroku pricing, it must have changed by now, by the way. But just go to look at their pricing again, Heroku pricing, Heroku pricing is you get a free Dino that sleeps after 30 minute inactivity and it dies after I think 18 hours, sleeps six hours every so often. So that's the free version, but ignore the free part. You pay $7 per Dino per month and you get a hobby platform for trying it out. If you're going production, you go $25 to $500 per Dino. The Dino sizes are big and small, you can choose, pick and choose. And then you can actually understand your pricing. You want to run 10 Dinos, you will be spending about $250 per month. You want to have bigger Dinos, you can just run big ones for $500 a month. You want high performance Dinos, Dinos are basically their work for machines. And they let you scale horizontally like we discussed before. And you don't have to worry about that scaling. As soon as the workload hits your site, customers come in, you see that your machine need to scale, they will scale for you. That's as simple as that. And all you need to worry about is to write your application. That's the top level value proposition. If you go to Heroku, you will find this picture, which is I think beautifully done. So all of this infrastructure detail that you see in these blocks, black and white blocks, you just hide all of them by moving away from it. And all you do is deploy, manage and scale. And that's it. You're developing your application and you do a git push, git push, and again, git push. And it goes live. You don't have to worry about these things. If you pay them money, you don't have to worry. But you get to choose whether you want to pay them money. If you don't, you deal with this complexity yourself. And that's the trade-off. Now having understood the trade-off part, either you manage your own infrastructure. That's one approach. The second approach large companies can afford to take, even small ones, depending on how many customers you have internally, is if you have an infrastructure, you can create your own platform and you get to manage this yourself. So the management headaches are still with you. You don't have to pay, but then you manage this and you manage this, both. And then you're allowing other team members in your company, other developers in your company to just do a git push to your platform as opposed to git push to Heroku. The command we tried was, what was that back in our virtual machine here? The command was git push Heroku master, pretty much like this. So if you have your own platform, you will say git push my platform as a service master. That's it. That's what your other team members in your company will do if you decide to run your own platform as a service. Now that comes with a lot of work, not trivial. But then you don't have to pay like $33 or whatever dollars per dino that these guys charge you. You don't have to pay them money because you know how to run a platform, you run it internally and you use open source. That means there's no other liability in terms of expenditure. Of course, you decide to use your own platform or open source platform or a commercial platform. All of these choices are available. But bottom line is it helps your developers in running their applications on demand with ease. That's the bottom line. I would like you to run this exercise yourself up to at least this point. There are more steps to go forward, but at least up to this point, deploy to Heroku and see it run. You should do these things. There are more steps along the way. But I think this should not take long for you to get a feel of building your app, running it live like this. The benefit of getting to run in a platform, as you understand, is that you get to focus just on your application and all you do from a running perspective is get push. Any questions on this? I guess you guys don't ask questions in live sessions, but that's okay. You don't have to. But I just want to make sure to give you the opportunity to ask questions. And what we intend to do next. It's nice that you went through the steps so we could see them all working. Yep. Yep. So you should be able to run those steps yourself. And what we will do is before we hit on to the platform as a service deployment, let me check a couple of things here. So how many days we have already in this session? That's what I want to count. So I think we have done five, right? One, two, how many? This is number five. Today we finished six, right? Oh my gosh, you're right. Maybe I didn't have it. I have two day four or so. Yeah, today we finished six. So we have two more days. I think we should be okay. We should be able to cover the platform as a service deployment ourselves. But before that, we had to run with this thing called Docker. We don't understand Docker a little bit before we are able to run our own platform. Nailesh, this is Kara, are you going to be able to show Chef or Puppet or? Yes, we will do that. That's the second segment, DevOps segment. That's where we start, Chef. Okay, great. Thank you. There is, by the way, one more thing I want to point out is that all of you should read a book that is available in the public library. The book is called The Goal. You should read that. It's a textbook. It's a very small book. This book is what I am suggesting that you please get from the library. It is available in here. What did I just type? I think I typed it correct. Yes. So that's the book. You should be able to get it on Amazon and a bunch of other places, including the public library. KCLS should have it. This library should have it. Your local library should also have it. And find it on Amazon. You should be able to find the Goal book. Let me give you a goal reference. This is the book I'm talking about. By the way, it is available for one cent. Cannot beat that price. One cent. Paperback. 399 shipping. Please get that book. Read it. It's a very short one. It's a good one. It's a textbook. And I think all of you know that this is not just me recommending, but Jeff Bezos recommending it. You know that, right? Did I say that? I may not have. I know you talked about it. Okay. Please get that book here. Link again in Slack chat. And there is a book summary. You should read that on the website and prepare ahead. That will help you understand. That will basically help me skip some of the things, if you read the book already, I can skip ahead. That's my idea. And so I don't have to skip, but I can. And please allow me to skip ahead if you read the book. And so that's one thing I wanted to mention. The other thing was regarding Chef and Ansible and other things, we'll start that in the DevOps segment, which starts on, what day we start on? Straight from today, I think. I think 4th. It's February 4th. Yeah. 4th of that. Last day. Last day of this class. February 2nd. Correct. So we start that Chef discussion right here. That Chef will be quite a bit deep. And so some of you will enjoy it. Some of you will hate it. I'm sorry for that. Now, there was something, at least, that I saw on the website that talked about some kind of group dinner, February 18th. That was last year. We can do that again. Absolutely. In fact, that's good that you point out. There is. We should do that group dinner. Why not? Absolutely. And I will give you a picture of some of your colleagues that have attended that. We should also get together. Why not? Absolutely. In fact, I was going to mention this. Now that you have mentioned, I suggest here is the group dinner that I mentioned. February 14th happened last year. We'll do it this year again. Why not? So here is a group. You probably know some of these guys in the picture. Oh, yeah. There's Rebecca and Helen. Yeah. Yep. So they are your team members. And so you recognize them. We'll have a group meeting. And I'm so sorry for Shiva. I'm not able to, you know, maybe I'll come to see you or you come here, but we'll figure it out. And so the idea would be us getting together. And I'm sorry, we'll make you feel alone, at least for this time. But I'll compensate for that in some other fashion. So sorry about that, Shiva, again. But yes, I want to get together. Absolutely. Please pick a date. Please pick a time. When you, this was in Din Tai Fung. You can choose your place if you like. You should absolutely do that. No doubt about it. Thank you for bringing it up. So you pick your date. Pick your time. Please pick a date which is not a class date. So don't pick Tuesdays. Don't pick Thursdays. But any other evening is good. So I just have a question. I know probably I know that's the right question to ask. But if you kind of want to leverage a cloud processor, as well as save money here, can you have something like a user infrastructure, but you can deploy your own libraries, set up all the environments and then keep scaling up. In that way, will you be able to save some dollars? Yes. You mean you as an individual or you as a company? As a company. Yeah, as a company. I think for a company of your scale, you're a big company. So you should be able to experiment with both options, like all big companies do, and find out what actually translates to saving money. In the challenge that happens is that if you use a platform as a service, it is very easy to start using it, and it's cost effective as you grow. But when you become big, that's when it hurts. Right now, it's a couple hundred dollars, no big deal. But when it grows in terms of your entire application suite is running on some third party platform as a service, you will pay them arm and a leg and everything and that will start to hurt. And at that time, it is appropriate to switch away from a platform to run either your own platform or just forget the platform, run it directly on an infrastructure with your own tooling like Chef or Puppet or Terraform or a bunch of other things, we'll talk about that later. Right. The idea would be, as you are small, as you start, it is a practical thing to run on a ready-made platform. So you cut down on your work, you don't have to write infrastructure code, which is hard. But that is not hard for us. You and I will learn how to deal with infrastructure quite a bit. We don't have to worry about it. But as a small startup or a new group in a big company, you start with a ready-made application platform, take it up, throw it on the platform, see it run, gives you instant gratification, immediate satisfaction. Yeah, it works. Thank you. It worked. That's the benefit that platforms provide, platforms as a service provide. You want to use that. Why not use it? As you build and grow, plan the other strategy, which is at some point, I know I want to get away from this Heroku business because it will cost me a boatload of money that I can ahead of time plan and save in the future, which means I have to put my eggs in at least two baskets, which is one of them is Heroku direction or some other platform direction. The other one is run my own thing, run my own gig, run my own infrastructure, manage my own entire from ground up so I can save money. If I spend effort on a side project and eventually grow it into a mainstream project, at that time I can say goodbye to these platforms who basically take a lot of money at that time when you become big. And so you will transition away and you will play both these games at the same time, just like many companies do. Boeing is doing the same thing. They have a platform solution in-house, they have a commercial platform, they use public cloud, they use private cloud, they're basically playing around identifying what makes sense long term. So they will play with every single thing that they have at their disposal. You're doing it already. Same thing in your company, basically mix and match, but make sure to stand again the benefit of readymade platforms to begin with and plan to switch away as you grow bigger. Okay. Thank you. Yes. Sweet. So pick a date please and let us, you know, in Slack chat a date like Monday would be awesome. A date, something like 3rd of February, 3rd of February would be good, 5th of February would be good. Take your pick. What date works for you guys? Just tell me. You want to wait until after the class is over? Fine. Yeah, why not? Just chat in Slack chat and propose a date. I'm proposing something like February 3rd. I'm just going elaborate with my proposal. So February 3rd at your place. So you pick your type of food. I'm proposing Chinese. Yeah, how about next class we'll bring some dates in because I have to look at both my calendars. Makes sense. I'll leave it for you guys to decide. So yes, but thank you for bringing it up Kara and it'll be nice to get together and sorry Shiv again. And I look forward to seeing you guys face to face as well. I have met some of you, not all of you. I would like to meet each and every one of you and I will do that. And I will eventually find a way to meet Shiv in Baltimore at some point. Yeah, I rarely travel, but when I do, I will go and see him now. So next session, we will have it on what day today is today, 28th. So next session is 31st of January, which is a Tuesday at four o'clock Pacific time is the next session. We will see you guys on Slack chat. In the meanwhile, please run this Heroku exercise, get to get it functional. If you run into problems, chat with me, call me and read that book. This is a book by that he also make sure that you read this gold book. It is a textbook, by the way, it is boring. Just to caution you, it can be boring in the way he describes the language. It is like a, like a novel written like a novel. It doesn't sound like a textbook, but some people find it distracting. It is a short book and it's a recommended reading. And therefore, by the way, it is actually a good book. The concepts are good. The way he describes it kind of, you know, different, I don't like it myself that much, but just saying that the essence of the book is very good. That's what I want you to take. It is a top seller that are top, you know, good reviews. People have recommended it. Not just me, big guys have, and you can see that right here, Jeff Bezos recommending. So that's the reason why we have it, by the way, the concepts of that book are actually applicable to the principles of DevOps. It is not a technology book, not at all, but you should read that because it, the concepts of DevOps derives from those that book originally. And we will talk more about that next time at appropriate time for right now. I will see you guys on 31st of January at 4 PM right here on Zoom, this conference. So see you. Thank you. What about the Phoenix project? Is that also a good read? The Phoenix project is a derivative of this goal book. Okay. It basically is the technology examples used in Phoenix project as opposed to manufacturing examples in the goal book, the same concept. Okay. I have references to both and a little summary on the website already for both the books. You should, you know, if you, if you have time, read both. Yeah. And please post the recording also as this is pretty detailed. I will, I will stop recording right now and prepare a file and post it on the website. All right. Thank you. See you soon. Bye.