Hello everybody. Hey, good evening. How are you doing? Good, how are you? Good, good, good to see you. Did you watch that video that I gave you a link for, the simple four-year-old video, I mean the one for Git for four-year-old? Oh no, I read the page. If you know Git, it is not necessary to watch the video. I think you know Git, I suspect. Yeah, we do use Git. Bitbucket basically, but it is just a wrapper around GitHub. It's a wrapper around Git software. Cool, cool, cool. Let me just check. Hey guys. How are you guys doing? We have David, Mukesh, Ram and Mark. How are you guys doing? Good to see you guys. Good to see you all. Nobody tactically types on the keyboard. Isn't that fun? Isn't that fun? I think we should start. We have a couple more people who will join momentarily. Let's see if they're online on Skype. Dennis is coming online and we have Diego and Marjorie is also coming online. Let's begin. A quick question for all of you. Did you get a chance to watch that video that I suggested that you please take a look? Which is this one, which is a very interesting way of looking at Git. The reason we want to understand Git is primarily to manage whatever work our teams are doing. You probably recall this that I said a while ago. Git is a tool to manage the state of your work, whatever that work is, whether it is code writing, spec writing, document writing, documentation writing, or general process overflow writing, marketing plans. You can actually store all these things inside a structured and collaborative repository, which is basically a folder. Think of it as a folder. In that folder, you are basically putting your content and your version controlling your changes. That's the primary use case. There are many other use cases of Git, but our focus is making sure that we are able to communicate, collaborate effectively. That's the design point of what we want to be able to do. What I'm going to do is adjust my screen a little bit and make sure that you can see it. I'm going to talk about Git from a conceptual perspective and then we'll do some exercises. This concept of Git. Git is an open source application. It was written by this guy. You know him. He is Linus. You know him as this gentleman who created Linux software, the operating system, as well as he created this software called Git. This is open source. It is free. Now, these days, even Microsoft has incorporated, what's the name of that? Visual Studio. VisualStudio.com will support Git. Also, it is basically a first-class citizen in Visual Studio tooling, as you can see here. It is right there alongside other tools, specifically Conduct. That is Microsoft's toolset, which is the primary development tool that Microsoft developers would use. People who are using Microsoft technologies will use. Having this toolkit integrated into the main development tooling, even with Microsoft, is just beautiful. That basically sets the bar. By the way, there are many other such version control systems. Git happens to be just one of them. Internally at Microsoft, they use something which is derived out of this thing called Perforce. Microsoft internal people call it Product Studio. No, not Product Studio. I'm forgetting what the internal name is. Basically, it is a derivative of Perforce. There is a thing called Mercurial, which is also open source. Mercurial. There is another thing called CVS, SVN. There are many other variations to this concept. Even older Microsoft technologies such as source code control system, there are variations of this product set back in 1980s that I have seen from Microsoft. These toolkits all exist. Many of them are still used worldwide in a variety of projects. However, the leader is right this guy. This product set, which is basically the product available in this website here called Git SCM, is the leader of all these tools that we can see about watch and control. Its primary purpose is distributed watch and control. Distributed watch and control is a design that is very different from almost all of the other guys, although these guys are also evolving into distributed systems. Although the older ones, these guys, older technologies, that relied on some kind of a central location for controlling your source, controlling your state, controlling whatever concept that you will put in that central repository. Everybody will then just make copies of whatever they want to work on. Then when they are done, they will push it back to the central location, all of them. These are team members working, collaborating together to basically put that back in that central location. That was the model of usage in older days. Some of the older tools still use that model of centralized source state control, centralized source code control. However, the software like Git makes it distributed. The idea behind this concept is that there is no central location where you actually store stuff. You can have a beginning location where you can store, but it doesn't make it a central location by definition. You can maybe begin working in a folder, maybe this location that you have, some folder, some location. In that folder location, you will create subfolders and further subfolders and files. You will put whatever you want in those locations, and that constitutes a tree. This tree is basically the project that your team members will be working on. This project can contain development code, test code, of course. But then you can also include things like whatever you basically can put in a folder. Images, documents, PowerPoint presentations, plans, designs. Basically, all types of people that work on a project can actually and actually should actually collaborate in a very systematic fashion by putting all their plans of marketing and sales. Some companies actually do it this way, where they are able to synchronize all of them work together in form of a central share. I should not say call it central, but a location where they begin from. They begin from a common location, and then all of these guys will then create their replica. Essentially, you begin with some location, initial location. That is the folder that you start working with. Team members will basically create clone. These clones are full-fledged repositories on themselves. This is where you begin. You initialize it, and this is a one-time operation. That's how you begin initializing, and then it becomes a repository, and then you clone it. This clone process, actually clone is an action. When you clone that repository, this becomes another repository. Same thing here. When you clone that repository again in another location, this becomes the same repository is available in now three places. There is no central concept. There is no one place that will be considered central, although you can think like that, that this particular location becomes a central location. You can think from a usage perspective, that's the model you want. You can think yourself that, I want to clone it one more time and call that one as the central one. Then everybody will just push their changes, push the change that they might have over to that location so that we know that this is the location that we want to continue to work towards. What I'm drawing essentially is what I would call, in computer science or in graph theory, known as a directed graph. You may have heard of this word. This directed graph basically is a mathematical concept. In simple terms, it basically means that you can traverse from this location to that location or to any other location through the systematic ways of traversing from one location to another, if you like. These arrows you can take go forward, come back. Each one of these are states of the folder or the repository that we are working towards, like in this case, multiple people working on the repository, that folder that I talked about here, some location where you start putting your content, that becomes your project folder. But the beauty is there is no central location. You can keep working independently of each other, and you can traverse from point A to point B, back to A, if you like, go to C, go to D, and this traversal is through this concept of a directed graph. So that's enough of discussion around it. Let's translate this into some kind of actual action. How does that work out? How do we put this to use? I'm going to take a simple example. I'll say for our team, let's see how many people we have here, six people. In six people, what I want to do is let us decide on a project. The project essentially is to write, very, very trivial, write down and create 26 files. The files that we would like to have is basically the file called A, the file called B, like that, all the way through the file called Z. These are the 26 files that I would like to create as a project. The files themselves are empty. The files are empty. It's just these names. So these are file names. And that's the initial step that I want to begin with. So we want to create such a thing, but we want to do it distributed fashion. So we want to collaborate at the same time and create this folder structure that will contain 26 files empty, but with these names called out. That's the name I would like to have, file A, file B, file C. I got 26 files and no extension. That's the way I would like to be. You can put extensions if you like, but no file extension. So no file extension needed. Just the file name is A, B, C, like that. And we keep going and we will construct this. And we will divide the work among us. So what we'll do is we have six people. So let us divide that work. So this is five of you, and I'll just begin creating the empty folder. And so that's the distinction I would like you to make is I'm dividing that work as a team leader. What I'm doing is assigning that group, this group, a task that I will begin creating an empty folder. This will be the folder that I would like to work. And I would like us to divide this creation of A through Z like this. And let us assign that task to our team members here and have this construct and then integrate in terms of a common folder that will contain all these six files, A, B, C, D, E, F, G, H, eight files here and other files you will construct like that. And you will then integrate them. So we will have a repository to begin with. I will create with nothing in it. So that will be the empty repository. And I will give you a link to that so that you can clone it locally. And maybe fork it. Forking is another concept I will talk about. And then we will then create these files as described here on the sheet of paper. And then we will merge all these changes in central location. That's the idea. So let us begin. And it does not require any computer, any terminal as such. You can just do in this location called GitHub, which I'm assuming that all of you have an account by now. So I'm going to create a new empty repository and give you access to it. So I'm going to create that right now. And all of it is going to be done in the browser, as you can see, that I will begin doing. And maybe I will walk you through a couple of steps and you will find it intuitively very simple to understand. All we are doing essentially is creating these files like A through H, for example, I through M. And these different individual files will be constructed by each one of us. And so we have, let's put these names on the sheet. So we can have, who's the alpha order? So David, Dennis, Mark, Mukesh and Ram. So this is David, Dennis. I'm going to have to catch up too. I see. No worries. So Mark, Mukesh and Ram. So we will begin with this alpha order, alphabetical order. And what we will do is in that location, that folder, I will begin constructing. It is actually really simple. You will laugh at it probably because it is not rocket science. And nothing, no rocket science involved. As simple as creating a new repository, giving it a name. I will give it that name that I seem to like right now, which is this name for the folder repository. And I will make that repository public. So anybody can easily access it. That's the idea. So basically creating a name of the repository. This is the folder name, by the way. Marking it public. And we'll say create. That's it. I did my work. And when I did that, I need to let you guys know that I have created this. So I will just send this link to you. And what you can do is fork it. Basically, forking is a way of creating a replica on a separate branch structure. So what I will do is paste that link in Slack chat right here. And so I think I accidentally typed unnecessary messages there. So I just wanted to give you the link, which is not this part. So I cleaned that up. And I edited that. So that link should open up in a browser. And it will take you to this page. And in that page, what you need to be able to do is, by the way, when you go to that page, you should not see what I see. You should see something different. Let's go open that link in a different new browser window, which is anonymous. So this browser window that I am going to open is incognito browser. And I am going to open that same link incognito. And this takes me to this empty repository that I just created. And this is a folder called Gagan. And in that folder, you have this choice of watching it, star, assigning a marker for it, for you to observe it, favorite it. It's like a like button in Facebook, for example. So star is like like button. Watch is to watch for changes that happen here. And then this concept of fork. And I would like you to actually fork it. So click on that link that I gave you in Slack chat and fork. As simple as that. So click that link here at the bottom. And come on down in this location, which will take you to that incognito browser, not this browser, but it will look like this to you. Here you should log in and fork. When you fork, it will ask you to log in and you should have an account. If not, create one. It is free. And then you log in here and then you begin proceeding on the next step. The next step is you will see this. Yes. I am logged in and I am on the page, but the forking is disabled. Forking disabled. Let me see. Let me see. This is a public repository. Anybody should be able to fork it. So I'll just quickly look at your screen. Can you please share your screen? So here you are logged in. You should click on the word garden, the word garden. It is disabled. Careful. It is empty. Let me put some initial stuff. So I'm going to, in that repository, I will just initiate something right now. I understood the problem. I will now take the screen control back and show you my screen as to what I'm doing. And what I'm going to do is just begin seed it. I'm going to seed something in there. So just seeding something to begin working in that key, in the folder. What I will do is create something. So right now I am going to add teams and collaborators code. I think I should take a step back and walk you through a couple of things such as cloning on the command line. I think that's what I intend to do. So this is a slight change in what I just said before is what I intend to do is bring it down locally. So I will create a local, I think I should clarify, what is going on in the example that I think I did not describe to you correctly. I'm correcting my description now. What needs to happen is you need to have a folder first. And then you initialize Git. And then you send it over to GitHub. And then whatever I said will work. And that part I did not do. That is my mistake. And so I will need to create a folder, initialize it with some initial content, and then send it to GitHub. And then give you that link. So I will do this step, which was missing. I will finish the step that was missing in my earlier discussion and then send it over to GitHub. That will allow you to continue. So in this folder, in that location, I will create a new folder on my desktop right here. And in that folder, I will create a folder called mkdir-gargan. And then I'll go inside that folder and say, initialize Git repository right in this location. Something like git init. Initialize it right here. And I did. So now I have a Git repository. So what I will do now is somehow make sure that the repository is committed to in form of a creation step that is needed. So this creation of initialization will need to add some initial element, like a readme file, some readme file to describe what we are going to do in that readme.txt that I will describe. And then I will make a commit. You don't need to create the Gargan folder, right? When you clone it in the location, it automatically creates the Gargan folder. For you, yes. For me, I need to have that because I cannot clone. For you, yes. You don't need to create this Gargan folder. This is a one time operation of initialization. And then I need to create something like add a readme file. And then I commit it, and then I push it to GitHub like this. And then everything proceeds. So these are the steps that I need to do. These are one time steps that I missed. One time steps. And that's what I am doing. You don't have to do these steps. So these one time steps involve initializing, which I just did. Git init. Then I need to create a readme file. Something like touch readme. And in that file, I will say edit this file. So I'll say atom readme. And in that atom editor, I will write something. We will collaborate to create a folder. Create 26 files, each beginning with the letter in English alphabet. That's the single one liner description I wrote in the readme file. And now I have the readme file ready for me to commit and push. So my readme file looks like this. And I will now commit add and commit this item to the repository and then push it to GitHub. So that step involves me adding. So git add this readme. And then git commit this readme. And with a comment that I want to provide, the commit message I want to provide is say, let me describe this commit message also. This commit message idea is to communicate with team members what the heck I did. So in this message, I'm saying I added a readme file. That's the message I want to communicate to my team members. And I committed that. Now I want to establish a relationship between this folder and GitHub. So there is currently no relation between this folder and this GitHub location. So I will establish that relationship and then push. And that step involves me going to push an existing repository from the command line. So I need to go do these two steps. So first one is to establish a relationship between my folder and that location on GitHub, which is that line, which is to add a remote connection. So I did this line. And then I will push. So git push to GitHub. Now I can push. And I just pushed. I need to give my login name here. And since I am using SSH keys, this remote was wrong. That remote should be SSH, like this. So I need to change my remote. I think this confuses a whole lot. So many of you must have confused by now. So I will do these steps one more time just to cut down any confusion. And I think it's a good idea to maybe describe to you these concepts one more time just to get clarity, because this can be a ton of confusion if you don't know what's going on. If you know what you've seen before, it is not confusing. But I think I just managed to confuse all of you, because what is the SSH business and what is HTTP business? I want to do this all over one more time to clear up any confusion that you might have, especially these one-time steps. And let's do that part. Let's do that. So I'll erase. So let's reset. What essentially constitutes a repository in a different place like this folder that I have? So I have a folder. This is a folder. It doesn't become a repository until I initialize. I add something. I commit to it. And when I do that, then it becomes a repository. Now, this repository sits on my local machine. If I want to make a connection with some other location, like GitHub, for example, I need to have a remote connection. This remote reference has to have a name. Like origin is the name GitHub proposes to use. You can change this name if you like. And this remote name establishes this connection between that local repository that you have and a GitHub location that you create through the web browser. Now, that remote connection, once you establish, then you can just push. And push means it goes there. And a reverse of push is pull. It is also another step you can follow if you are pulling. If you are pulling the whole thing, it is called clone or fork. The two names do a slight variation to the way they operate. And those are some of the things push and pull is obvious. Cloning and forking are bringing the whole thing down. I should not call it down because it's not really up and down. It's siblings. They are brothers, sisters. So essentially, you are replicating. These are replication steps. Both of them, forking and cloning. This is a send operation. This is a receive operation. So that's the overall picture. And with that understood, this remote connection that you have establishes in two methods. One is HTTPS method, and the other one is SSH method. HTTPS method requires a login and a password, which I think you will use. In my computer, I have disabled login password method. The only way I can get to GitHub is through SSH key. SSH key. That's a security precaution that I have made on my GitHub account. So I cannot log in using login password. That's why I stop at this stage. And I cannot proceed because even if I know the password, it is not going to work. So I'm going to break this and come out one step and erase the folder, rm-rf, one more time. And that folder has gone dead. Having done that part, I will now begin again. Now watch these simple steps in a logical order like I described here. So first thing, I will create an empty folder. The folder by itself does not become a repository unless I do these things, to initialize, to add, and commit. This basically constructs all the logic needed to convert this folder into a Git repository. But it is still local to my machine. I need to establish a remote connection, which I will grab from GitHub, like here. I have this, and I intend to delete that, by the way. Since I'm cleaning up and doing the whole thing again, I want to delete this and say, yes, I want to get rid of it. So I am basically saying this repository also goes bye-bye. So I deleted that. Now, there is nothing in GitHub right now and nothing on my folder at all. So I'll basically begin again, and I do it on this terminal. At the same time, I will write what I'm doing on the other side. So watch this step. Nothing anywhere, nothing on my computer, nothing on GitHub, beginning from fresh, doing it step by step. First step, create a folder, which is this. Now, this creates a folder. So that was step number one, create folder. Now, we want to get to this point where we have this thing known as make it a repo, make it a repository. How do we do that? There are interim steps, like two and three. Those are needed. We have to create some item, add an item, some kind of an item that sits in that folder, and then commit. This commit action makes it a repo. That's what I will do now here. So mkdir is created that folder. Second step is to add an item. So I'll create a file called readme. Say readme file created, and then I will add it. So git add readme. Oh, I forgot one step here. Yes, Dinti, you had to do init. Yeah, I forgot. I should say init here. So it's 1.5 step is init. I think I should use a notepad to write as opposed to handwriting. So I will do that. That's much better. So in this sheet, it's easier for me to go up and down. So first step is mkdir. That's the creation part. Then I will create a file. Then I will add that file. But before I add, I have to go initialize the repository. And before I initialize the repository, I have to go inside the folder. And then I initialize. Then I add readme. And then I git commit. And then pass a commit message like this. I am adding a readme. Nilesh Mukesh here. Do you do the touch readme before init or you will be doing after? That's immaterial. So you can do it before or after. It doesn't matter. So you could change it like this if you like. But this touch basically creates it, creates a new file. And this is the addition command, as it's obvious. And touch, you can have this like a file operation. Number four is a file operation. Six and seven are git operations. So that's what we are doing. We can do this later or before. It doesn't matter. Now with this touch that we are going to do, we are going to go along as I'm writing on the right side. And I will see that I have this folder called cdgagan. In that folder, I will go initialize. That initializes the repository. What does happen inside? Let's go take a look. You will see that this folder doesn't contain anything. When I say show me the tree inside the folder, I see nothing. However, there are things hidden from view. You can see that there is a folder called.git created. This folder gets created. It is hidden because it has a dot in before that. And that folder.git is a hidden folder. That's where the magic is sitting that gets created because of this line number five. So if you remove that line number five, or rather remove the.git folder, your repository is gone. You're basically back as an empty folder again. So you have to repeat that step. This line number five step creates that.git folder. So we are going to do that line number five again because I killed my git repository. I created it again. So I repeated that step, line number five, repeated. Once I do that, I will have that.git folder created. This folder is where git is managed. You can see the content inside that git folder. If you are really curious, you can actually go and see the entire tree. And the tree contains a folder called.git. It has head, config, description, books, info, objects, and references. A bunch of other things. This is where git manages that repository for you. Right now, inside the folder, there are no files, but there is a hidden folder called.git. That's got created through line number five. Now, in our folder, we will create a file called readme. And then we will add that file to the repository like this. And then commit. I am adding a readme like this. Now, it did something. It changed something in the repository. It told us that one file changed. No insertions, no deletions. And create more, create a readme. A file got inserted inside that folder somewhere here. A record is kept of that file somewhere here in that folder. We don't see it unless we go and inspect it. But I think it's a good idea to not mess around with that particular.git folder at all. Now, some of the interesting stuff that you may want to see are actually right here. Let me make some room here so you can see properly. What I want to be able to do is show you some magic of Git even before we go to GitHub, even before going there, just locally, only locally right here. If I decide I want to check what is going on in my Git repository, I can simply say git log. So show me the log. And it says, at Tuesday, 27 September, Nilesh added. Nilesh said, I am adding a readme file. And that's a commit hash, five brother, brother, two brother. This long hash that you see is a reference to a new node got created that I was talking about early on here. And I'll show you. So it's a reference to a repository. So this is a commit hash with a five brother, brother, two brother. And that hash that you have is this reference of commit that knows that something has happened in that repository. It is preserving something called a readme file. And there is a commit message that says that. So that repository, that folder that we created called Gagan is now under control of Git in form of a repository with this commit hash. Now let us delete the readme file. And I'll say yes. Now I have managed to delete the file. I have a data loss. But worry not. We can bring it back. We just changed the state of this folder from something that it had to something which does not have that readme file. So no readme file at all anymore. And so this file is now missing, which means our state of the folder changed. It is not this state, but something different. So we want to go back to that location. We can simply say a couple of things like restore my setting, basically. Reset my folder. So if I go see my folder, I don't see the readme file. If I say git reset, and now I see the readme file back again. Because whatever changes I made, I can revert those changes as I go along. That's a simple way of understanding that if I make a mistake, I can revert back. As simple as that. Now if I make some changes inside the file, like I go to the readme file itself, and I say atom readme file, let me edit that file. The atom editor will open, and I'll edit the readme file. In this folder, we will create 26 files and save. So that's the thing I saved in that file. So my readme file shows that. Now this change is a change in the body of the file. So the git status is going to show you that something has modified. And this is a modification in the file, the body of the file itself. Which means I need to keep track of whatever I'm changing. If I don't keep track, I might lose it. In order to keep track, I need to again do those operations, such as git add and git commit. And when I do that, I'm basically changing the state from this five brother, brother, two brother that I had to another state, another new location, another new hash, with another hash identifier, which contains the changes in readme file itself. And that change is also tracked inside git, and you can see that. Here I will say git add and git commit, and then I give a message. I added some text to readme, and then I save it. Now I have a git log that shows that there are two hashes. One is for this five brother, brother, two brother, which is the older one, and a new hash called 38817. This hash indicates that I added some text to readme. And I can keep adding like that, keep adding things like this. So I have here with nothing. And then here with the commit number five brother, brother, two brother. And there I add a file, add readme file. And then I have another commit hash called 38817. In that case, I change the readme file by adding some text to it. So I'm basically traversing like this. And I'm keeping track of whatever I'm doing in my folder. The folder in our example is this name, Gagan folder. And it is being kept track of inside this repository by use of these git hashes or commit hashes. And you can go back to any hash that you like. You can go to this point or come back to this point or go to that point if you like. So you can basically traverse along the way as you develop or as you create new content. So now let us see what does readme contain right now. Character readme. And it says, in this folder, we'll create 26 files. Now if I go git checkout and give me the five brother, brother, two brother. And so after checking out the five brother, brother, two brother, I can see that my readme file contains nothing. There we go. We have nothing. Now we can go back again and say git checkout and give me 38817, please. And so now we see that our readme file contains the changes I made in the file. And we can keep modifying like this. I can further say I readme, edit that file. And we will divide the work among our team. And then I modified this further. I saved this line. Now I have my git status again saying something changed. Git status shows modified readme. I need to again repeat the steps one more time. And I will now get another commit hash. New hash number comes up, which will include this further change that I made just now in that file. I expanded this language that I wrote in the readme file. And I'm going to modify it. Now I'm going to basically add and commit. The add and commit step will create a new hash for me to operate on. And this becomes our git log shows us that we are changing things as we go along. So in there, git add readme and then git commit. With a message, I further improve the readme. Now I have a git log that shows that I am basically beginning with adding a readme. Then I add some text to it. And then I further improve it. And this is log number A5827. And that's a new number we got, A5827. We don't have to remember these numbers. I'm just saying that it's easy for me to write down to illustrate the point. And we are building our git structure, systematically keeping track of what was the thing before and what is it right now. And that's the git structure that I'm basically beginning to create. Now, having done this part, let us establish the other concepts, such as what I want to be able to do is go back to this sheet of paper. And here I want to establish a location in GitHub, for example. So we have to have a place in GitHub. And this having a place in GitHub involves creating a repository in GitHub. That's what we will do in a web browser. So we go to that location in the web browser and say, you know what, please create a location, new repository. And here we will call it the name Gagan and make it a public repository and say, create one. So it does. It creates that. Now, by default, I am using SSH for authentication, which is a better secure method. And the default method is HTTPS method, which is what I think you should be using. But in my computer, I have disabled HTTPS access, and I am forcing myself to go the difficult route, which is the SSH route. And it is a little bit more secure route. And so that is what I will need to follow along. But remember that you have to operate in SSH because you are not yet ready for SSH. So you will make that changes eventually at some point. At that time, you will know what to do. So for right now, we have to push an existing repository from the command line, which means we have to establish a link and then push. So essentially, we have to do these two things. First is to establish a remote connection between our repository here, add a remote origin to this location. So read line number 11 very carefully, it shows you that the location is this line number 13. That's the remote location. You want to add that remote connection to this repository and call it origin. Just a name, origin is the name that GitHub likes to use. You can change it. You can call this origin name whatever you like. It doesn't matter, but I'm just using the name origin. And so we're sticking to that. And with that understood, this actually is one long command, line number 11. And so it basically establishes a remote connection to whatever you want. So back in here, before we run that line number 11, I want to show you that my Git remotes are empty. Not Git remotes, but Git remote is empty. I do not have any remote connection. Having understood that part, I will now execute line number 11, which is establish a new remote connection. Now I can see that I have a remote connection called origin. I can see the detail behind that remote connection. And it will tell me that I can push and fetch from this origin location, which is an expanded form, which is a dash V form, shows me that I have a method of establishing a remote connection. Now I just noticed that I again made that mistake of using HTTPS, whereas I should have copied the SSH link, which means I need to remove that link one more time. And I will do that by removing the remote. The remote I have included is wrong for me. I have to remove that remote because I need to use the SSH remote, not the HTTPS remote. So I need to click this button and then grab that command as opposed to the HTTPS command. And this is just a security thing. So I'm going to modify these again and put these in place. So now this is line number 11, slightly different. That's what I need to use for my machine. And I have accidentally used the HTTPS link, which means I need to remove that remote. So I'll say git remote remove. The RM, I think it is. Let's see. How do you remove git remote? Let me do that through a command. How to remove git remote and git remote RM. So the command is git remote RM origin. That will remove that origin remote connection that I have. I will now check my remote connection again and I don't have any. Now I will insert this line number 11 one more time with a proper SSH link as opposed to HTTPS link. And I go and insert that link. Now my remotes are correct. Now it will work when I push. So I have established a remote connection between my folder and the GitHub location. So this is the Gargan folder, which has been a bunch of things that I have did. And it has reached a stage of A58272, this commit hash that you see. You can see it again in git log. Git log will show you that. Git log will show you that I have this A5827. And that's the commit hash I'm working on, A5827. Prior to that, I had 38817. And then before that, I had five brother, brother, two brother. And that's how we are working on creating interim steps towards creating our repository's current state, is this. And this is the log that you see in this left side. I have created a location for me to make a remote connection between this folder and GitHub. And so that remote is established, as you saw, in this step. And so now all I need to do is just push. So when I push, my changes will go from here to GitHub also. You can see that right now GitHub is empty. It doesn't show me anything. My readme file doesn't show there. So I will do a git push. I think it's origin master. So that line, dash u origin master. And this pushes my changes from my computer to GitHub using SSH protocol and a public key pair. And that is what you will see. The readme file pop up in that location. And now you should be able to fork. And this readme file shows you whatever I have. In this folder, we will create 26 files. This was this garden folder. You can see the history of two commits that I made. So one is I am adding a readme. And then this change that I made, which is the file itself, this contains no change. If you go to the previous location inside, you will see that the file actually contains this item. So in line number four in this folder, we create 26 files. And you go back here and you say git checkout master. And you see that this checkout master was basically making sure that I am on up to date with the origin master. So this is my local master, five, eight, this number I have here, which is that number. This is my local master. And this is making sure that I am in synchronization with the origin master. So the same exact thing should show up here as well. And that's what I'm looking at in that command that I said git checkout master. It shows me that you are leaving one commit behind but not connected to any other branches. If you want to keep it back in a new branch, it may be a good time to switch to that branch. I think this command is a little bit complex to read and understand. So we'll study this git checkout business later, just a few minutes later after you do some hands-on experience with it. We'll study checkouts and check-ins and mergers momentarily. But for now, I think you should have a position where you are in a place that you can actually fork this thing. We can see it. I think you had just forked it. One person forked it. David Rivera forked it. And in there, you see that David has created folder A, folder B. Yeah, there we go. So these are files, by the way. It has ABC written there in folder A. And that's what David is doing. And what I can see is that David has, instead of creating a file called folder A and folder B, and writing ABCD in there, what I would suggest is that the design that I had in mind was not very clear, apparently. It seems I must have not written down clearly. But the idea was to have 26 files with these names, like that. So you have a file name called folder A, which is different from what I thought you would have. So please create those files called A, B, C, D, like that. And so you create a new file like this, and then you proceed ahead. But I am not going to do it for you. I'll let you do that portion. And once you're done, what you need to do is send me a pull request. And so the collaboration idea that I have discussed now, now that we are proceeding forward with this initial step, I have a folder here somewhere in my computer. I call it Govan. And in that folder, I have made a remote connection to GitHub. And what I am suggesting that all of us do is fork it. And so in our own forks, we are going to work on our own folders. And in there, we will create our own content that we will have. And then after you fork and you make your changes, you want to send it back to me. The way you can do that is to ask me to pull. So it says, please pull. And this please pull basically means pull request. It's a request for me to pull whatever you create. You cannot push to me because you don't own this. I have the ownership on this location for that folder. So you cannot push. Push not allowed because you don't own it. And so right now, all you can do is send a pull request that you request this origin person to please pull. So the person can decide whether to pull your content or not. And that is what I would suggest that you do. So the idea would be, say, let us go take a look at what David is doing. And I think David is in a position to actually send a pull request. So that is what I will see. We have no pull requests by now, but let us go see what you guys are doing. We have three people, three or four people cloned it. So what I'm going to do is maybe take a look at David's computer and help him send a pull request. And then I'll come back to my machine. And David, please share your screen so I can see and help you in making sure that you are able to send me a pull request. Can you please share your screen, David? Thank you. And so here, David has created... Where are you right now? Let's go on the top of this browser, please. So on the top of the browser, there is a Fork button that you must have clicked already. And so you want to click the Fork button one more time. There we go. And it will take you to your Fork, which is this. In that Fork, you have made... There is a button to create a new pull request right there. There is a button called New Pull Request. Not a new file, but a new pull request. There we go. And that is how you create a new pull request. And you're saying that I'm going to send you these one, two, three, four changes. A, B, A, B. So you created and deleted whatever you made changes. You want to send them to me by clicking the green colored button. By the way, you have actually no change because you modified it. You created and deleted. So you could create something. So create something first before you send a pull request, please. So before you send a pull request, go back to the Gagan folder and create a file called A. And create a new file, call it A. And capital A or lowercase a, depending on convention. So we follow a common convention in the team. And we just say, propose new file. And that is what you're doing is basically saying, you know what? Create pull request, green button. And you're asking me to please create a file called A and send that request over. Now on my side, I will actually receive that request just like David sends. And I will now share my screen to you to show you what I see on my side. And you will see a very similar conceptually similar thing with one pull request pop up. And here you see that David says, create this file called A. And he has one file changed. And that comment that he's suggesting that we do, and we'll take a look at what he's suggesting. And we will basically review the changes and incorporate those changes. So we approve and submit. And at this moment, I'm going to merge that request into the folder. I confirm. And now I have a new file called A showing up right there in that folder. And so this was possible with help from our team member, David Rivera. And so he was able to create a new file. And he pushed it over to me through a pull request. We have one more pull request coming. This time it is from Mukesh Shahi. And this person has created B. And so he's suggesting that we have a file, that file B from Mukesh. And so he has sent us a pull request. We are going to review that change and say that, you know what, I like that change. I'm going to approve and incorporate. And so that change comes in. I'm going to merge that pull request and confirm. And thereby, now I have A and B, two files created by two different team members incorporated into that common centralized location called Gagan. This is the word centralized that I use because we are using it as a convention. Actually, the origin was my computer here, not GitHub. So what I need to do is bring down whatever David and Mukesh did to this request by way of pull request, whatever David and Mukesh sent, file A and file B. It is sitting in GitHub, which is nice, but I don't have it on my computer. So I need to get it here on my computer. And I can do that very simply by saying pull. And once I pull, I will receive them. So before I pull, let us see what we have. We have only that original file called readme that I had to begin with. And when I say git pull, it knows where to go, what to do, and just does it. It knows that it has to go to GitHub because that's the remote connection. So we know git remote is the GitHub location. And all we need to do is git pull, and it pulls. It will bring down those changes. The file A comes on, file B comes along, and we'll see those two files are available, A and B, and we can even see the git log showing up. You can see here that this Mr. Shahi created B, Mr. Rivera created A, and so we have these files created. And then I merge them. So this is a merge request. This is a merge from pull request. And this is the actual creation by Mukesh. This is the actual creation by David. And there are more changes. Before that, I added some text. Before that, I added that file, and like that. So this whole git log, if you draw it in the form of a diagram, what just happened is that I began with nothing, then I added a readme file, then I added some content to the readme file, readme improved, and then I basically pushed it to GitHub. And then I gave our team members a link to where this thing belongs. So, you know, team members did a fork. All of us did forks. And Mr. Rivera, what David did was he modified and added a file called A and then sent a pull request. And Mr. Shahi created a file called B and sent a pull request. And I took these two pull requests and said, accept it, so that this new location includes changes made by this person and this person. So those two changes came along in that location. I need to just pull them here to my computer. And that's what you can also do is basically, if you're operating on a terminal, you can also pull these changes and bring them to your computer. And all of us here, here, here, and everybody else will be synchronized by simple actions, such as push and pull, as long as they do not conflict. If there is no conflict, this synchronization will happen seamlessly, no problem. But conflicts are a way of life. They will happen. And so we'll talk about conflict resolution as to how do we manage that. And the bottom line summary is that this is a distributed method of managing a large collection of files, content, folder, document, code, pictures, movies, whatever you want to put. Git also handles very large files these days. So Git has large file support. Git has large file support on Git LFS. So it's an open source Git extension for versioning very large files. You can do that. It is now available as open source product. So it also works with GitHub if you buy a service from them. But again, you don't need that service. This is an open source product, so you can run it locally. And the idea is Git is not just for source code, not just for text-like files, but you can store whatever you like as long as you have appropriate storage capacity and appropriate software loaded, get large file storage. It also works very, very similar to GitHub, or rather I should say Git. And so what we are looking at again in this folder is there are more pull requests coming in. And we have Mr. Mark Myers sent us this file called D. And so he has given that D. I'm going to merge that pull request and confirm. So now I have in my Garmin folder A, B, and D. Let us see two more pull requests. We have C by Mark Myers. And so I'm going to merge that C file and confirm. And I will also go back and see if there are other pull requests open. There is a create A. And this A is going to cause a conflict. Basically... So I deliberately create a conflict. I know, you deliberately did that. I can tell that you want to deliberately create conflict. Because let me tell you, this not only happens deliberately, sometimes happens by accident. Thank you. I expected that. This is totally... Because that's what I want to discuss. How do you handle conflict resolution? And so conflicts are a way of life. They will happen. We are people. We will conflict. So the best way to handle conflict is to communicate. You have people A and B and C, multiple team members in the team. The best way to handle conflict is to talk. I mean, even today with modern technology, this is the only way to solve conflict. Just go talk to the other person. Hey, you created A and I also have A. What do you do now? Which A is better? And so that's basically it. You have to really look at what outcome that we want for the customer and which file, conflicting file, whether this A or that A, which is better. And we'll keep the better one depending on what we discuss. And we discuss on merit and look at what the customer wants. And based on that, we will decide whether we keep this version or that version based on our design. And that's what we want to really do. So in this file, we have a commit in the file changed. File says, this is file A from Mukesh. In our folder, we already have a file called A. And this file says nothing. It is empty, which is expected. That was the design, by the way, is to have empty files with just the label A as the A or B or C like the title as the file name and should not contain anything. Whereas if you look at the other file that we have just received from this pull request that says, create A. And if you open that file, inside that file, the file changes show that this is a file from Mukesh. That's the comment in the body of the file that we have, which is not what, according to our initial discussion and design, we said that we need these files to be empty. And so this file, I don't like. So I'm going to say decline. I'll review the changes. I'll say I'll comment. And we expected an empty file. So sorry, we cannot take this pull request. And we can just comment and send it back. So basically, even if you have a conflicting pull request, unless we decide to resolve it, there is no need to accept a pull request. You just ignore it or just say, you know what? I'm going to close the pull request because I don't want it or say that thank you. Thanks, Mukesh, for your help. But we cannot take this pull request. And just comment like that and save it. That way, Mukesh will know that you are thanking him for sending the pull request, but we cannot take this because it doesn't meet our initial design request. The design was to have these files empty, but this line is not the one that I wanted inside the body. So we close that pull request, and now we have files A, B, and this create C is actually not created correctly. The file name should be just the letter C. So I'll go modify that right now myself. And I'll say, you know what? This file should be called, like Mark did here. He said file name is D as in Delta. That's good. But file C as in Charlie is not named C as in Charlie. We need to rename that. So we have these files created. It's best handled locally in a terminal. So that's what I intend to do back in the terminal. We'll say, you know what? Pull again. Gift, pull. So we'll pull the changes again. We'll have C and D come down. So we now have C and D. We'll just open our folder. Open the folder to see what the content is. And we see that there is A, there is B, there is C. The C is called create C. So I'll just modify that file name to be C. And we now have A, B, C, D. That's good. Now we'll see that we just changed something. So git status will say that something changed. We deleted C and created a file called C. That's a change. So we want to go git. Add these changes. And then git commit. And send a message. I renamed to C. I renamed this file to C. That file to the letter C. Now I need to make sure that I push these changes back to GitHub. So I'll say git push. And the changes will go back to GitHub. And you can see that it is sending. And now back on GitHub, you can see that the changes are now. This create C will disappear and will become C. And you can see that these. There is one more pull request, by the way. And we have create F from David Rivera. And so that merge request does not show any conflict. I can just simply merge it and incorporate. And now we have that incorporated. So we have A, B, C, D, and F available to us. And now we can see that this whole work that we are doing right now is actually visible in the form of 13 commits. One after the other. And you can see that these things happening. I'm adding readme. Added some text to readme. Create A. Create B. These things have happened that David did this. Mukesh did this. Then I merged these two changes. Then Mark Myers created C. Mark created D. Then I merged these two changes. Then David created F. Then I renamed that file C. Sorry, create C to file C. And then I merged that pull request. And now I have these changes incorporated. And I see there is one more pull request. So I can update B and see that there is no conflict. So I can merge that pull request. But before that, I want to make the file empty. So the changes that we have now was deleted. This red line shows deletion. The green color shows nothing added. And that's the change we made. So thank you, Mukesh, for making it correct according to what we discussed. So I'm going to approve this change and say submit for review. And we merge the pull request and confirm the merge. So we now have this file, a, b, c, d, e, f, all according to what we want. And the commit logs are improving. They're basically telling us exactly what we are going to do and are doing along as we proceed in developing this folder together in a small team like this. And now back in our terminal here, we can pull, git pull. And it will bring it down, all the changes like Mukesh just did. So B was corrected. And we can see these things in our folder. So we just say open the folder to show we have a, b, c, d, f, and the readme file. And that is goodness. Now, sometimes it is not super intuitive to look at git logs in terminal like you saw. So some people prefer visual representation. And for that, there are also open source tools that will show you visually how this structure actually looks like. So there's 15 commits that you see and this network activity of people contributing. You can see that these people like me and Mark and David and Mukesh are working to collaborate to construct whatever we have done. And so that collaboration work that we have accomplished is up to this point is what we now have, is the latest change. And we can see this visually in form of this graph that shows on GitHub in the network section. However, if you don't have a web browser and you want to deal with local git repository, there are at least two good ones, two good pieces for software, open source. No, they're not open source. I think they're free, I should say. Free as in $0. So they're not open source, but they're good. And one of them is called Source Free, which is from an Australian company, Atlassian. And this is a free, not open source, but free, git client. That is one. GitHub also has another desktop client, which is GitHub Desktop. And that is also a very nice one for visualizing what we see in the change that happens in our repository. So in this git repository that we now have accumulated with git pulls from multiple people, and it should show us in form of a git pull. If you repeatedly pull, nothing will pop up because there is no change already up to date. When you see git log, you can see the git log in a terminal, but sometimes you want to see this visually. So we will use that Source Free software, like I mentioned, and see these visually from what that software shows us. And in here, you're looking at what we just collaboratively created in form of this representation, which I want to point out that it actually is a beautiful way of looking at how we begin adding a readme file, and then these commit hashes show up, 5 brother, brother, 2 brother, 3, 8, 8, 1, 7, and like that. And you can see that at the same time, David creates A. And you can see these forking actions. At this point, it forks over to David. So this line, yellow line, a golden line, is David operating. Anywhere you see that color is David's actions. Anywhere you see this greenish, bluish color is Mark Meyer's action. And you see the other purple magenta color is Mukesh Shahi's color. So they're assigning the software randomly assigns colors and shows you these dots. These dots that are looking at the crosshair points are basically representation of these commit hashes that we work together currently in multiple locations without centralizing or having a dependency on one central location for everybody to synchronize with. And that's one of the biggest benefits of Git that it provides, is that Mukesh, and Nilesh, and Mark, and whoever is working on it can currently work on their own computer without depending on a central location. You can cause conflicts, and they can be resolved after the fact, but it is basically a non-blocking way of working. So the idea to really understand is that this representation that you're looking at, this history representation, which is basically a representation of Git log, you can see that these files are getting created and merged into the central location. And this picture will actually show you very simply how. Let me take a snapshot of this picture. And so you will understand it much better if I just paste it over in SlackChat. So that is what I intend to do, is grab that picture from there and paste in Slack so you have it, or maybe paste it in this notepad. And that picture is right here. So maybe we'll do a new piece of paper and paste that picture right there. And so in that sheet you will see basically the representation of what we just did. And the idea here is to do a couple of things, like I mentioned, one of them being non-blocking. And that is, imagine if you have a situation where people are working on a centralized location. So some central location where the company decides that, you know, we will all keep our code here, keep our code, our document, our design, whatever we are working on, we'll keep it here. And then somebody is making a change here, some change happening. At that time, you know, people like you and me and David and all of us, we cannot really make our changes because we are dependent on that central change to finish. And that's a problem that we want to resolve. We can very, very easily and simply make our changes locally on our machine without worrying about this central location. And that's a contrast between older technologies and Git, is that Git does not need or depend on a central location. All of us can basically keep on making our changes and keep on working on our own independent machines without having to have that cross-dependency either among us or with a central location because there is no such thing. You can basically continue working unblocked from each other. And as a result, yes, you will have conflicts. Like, you know, you saw one. You saw a file conflict that we were able to resolve by basically rejecting a pull request. There are many ways to resolve conflicts like that. One of them was to just say no. And the way to resolve conflict essentially boils down to the fact that team members need to talk, need to communicate, and get to a point where we can actually have a resolution to remove that conflict and move forward. And at some point, all of us will synchronize our changes across to other people, other team members, and they will also send their changes over to you. All of us will keep working towards our own goals, individual goals that we may have, and also the overall team goals. So essentially, if you see that picture that I just pasted here in this representation you have here, that one, this representation, the idea is that this tree, this graph that gets created here, this graph structure that you're looking at is basically a method of working in using Git. What does that boil down to? So imagine if you have a big product release that you want to drive towards. What you can do is establish a train of release that you want to go to final production. And that becomes a thing that you want to put. So this is your production branch, if you call it that. So imagine this picture here. That one, each of these lines that you see here, I should say this line and this line and these lines, these three are independent lines that can operate on their own without actually having to come together. So at some time, these lines will actually come and merge like you see here. That merger will happen at some point. And this merger, when you go horizontally towards another one, that's what is called a merger. So you are looking at one line breaking away, that's the fork, and this is bringing it back. So here in this yellow line, you have David working on this change. It created F, and he goes away, goes on his own, works on it, and then brings it back to the main line. And that's the main branch, if you want to call it that. Essentially, what we are really doing is identifying multiple branches that we will work. So we will have a team branch. The team will work on for development purposes. We will have individual branches that each one of us will have. And so we just name them by our own names. Neelesh and David and like that. And so everybody will have their own local branches. We will keep on making our changes. We will focus on our work area. And at some point, we will say, you know, all of us, let us get together in a meeting and resolve our conflicts and then merge the changes that you are making into the team development branch. And at that time, all of us will synchronize. We will get together, talk, discuss, resolve conflicts. And then go off to do our own thing again. So we will basically change colors and synchronize that back and forward. So push and pull conflict resolution. And Neelesh needs to work on his private branch. David continues to work on his branch. He'll basically push and pull and synchronize with the main team branch. And at some point, when you are getting ready to release something to the customers, at that time, you will decide now is a good time to take from here and give it to the customer. And that becomes your production branch. And this production branch, whatever you have, is a finished product. And that is ready to be given to the end user customer. And that is something that you want to actually deploy to the cloud. And so you want to create something. Our team members will collaborate, fight the conflict. All of that usual thing will happen. People will obviously conflict. But that's okay. That's a good thing, actually. Having some conflict is a good thing, because you will have winners out of those conflicts. So bad ideas will go down, good ideas will go up, and they will all come together in the form of a team development. Once you reach a specific milestone that you can actually prepare to finish the product at a given milestone, that you can decide that now is a good time to release it. And you can actually push that out to the production branch. So you basically push those changes from your team branch over to production. And that becomes something that you deploy to the customer. And the customer, in turn, pays you money. That's the ultimate idea. You want to give value to the customer and get paid for it. And that's how businesses work. So that's the usage model of using Git as a tool for communication, collaboration. And the beauty of this is, as long as you have internet access, it doesn't even matter whether you are in the same building or not, because you can be anywhere in the world and still collaborate just like this, having your own independent branches and having team members geographically spread out. And they can continue to work on whatever they're working on and still operate as a team using technologies like this. And, of course, there are many more. And we just did this one exercise. Let us pause a minute for here and listen for questions, if you have any, in terms of usage of Git. And our specific usage of Git is revolving around understanding how do we take whatever work we are going to do. So each one of us will build something to begin with and make sure that we're keeping track of our changes. That's the primary activity I want to be able to do with you, is this Git log thing that I mentioned. This log keeps track of whatever changes we are making. So if we make a mistake, we can roll back. That's the primary use case I want to use Git for, at least in the next couple of sessions, is to be able to keep track of whatever we are making changes so that we can roll back and go forward and at least know what we are doing so we can understand and review whatever changes we made. That's the primary use case. Now Git is fairly elaborate in terms of what we can do with it. And the scope that I want to go is to narrow it down to somewhat of, apply the 80-20 rule. You can apply 80-20 rule to anything, including using and learning Git. So at this moment, what I would like to ask you is for questions that you might have just on what we discussed or even beyond in usage of Git. As to why Git, why does it matter, how do we make use of, where do we make use of, anything of that nature. Please go ahead. Anybody? Hey, Malish. David here. Hey, is there a concept of a master gatekeeper where everything is supposed to, who's supervising the actual master code emerging? There is none. That's the beauty, is that there is no such thing as a master. It is really a convention. In other older software, you used to have this centralized location, for example, in CBS or other pieces of older technology. The master location mattered a whole lot. And so this master location used to be the central office or the central company headquarters, where everybody, before they start working on, will do a checkout, will make their changes here, and then they send it back. And the other people here, this guy and that guy, they are waiting for this change to go back, and they cannot actually do another request until these changes are finished. So there was a deadlock. There used to be a deadlock if you have a master. So by the fact that you have a master actually causes this conflict. And this conflict is a bigger, more problematic conflict than the conflict that Mukesh created by creating conflicting files. We handle conflicting files, no problem, by just talking among ourselves. I say, which file is better, this or that. And that's how you resolve conflicts. But this conflict is a very bad one to have because you are waiting. And that wait is a waste. You don't want to wait. You don't want anybody in your team to wait for anything. Just do it. But the fundamental change you don't want to have is this wait time where people are waiting, doing nothing. They might have great ideas in their heads. But since they cannot really access because this change is happening, this guy is locking it up. And this is contention. Resource contention happens when you have a master. And that is a bigger problem than this kind of a conflict handling where file A and file A both aren't decent. Both are good. But there is some merit to this versus that. And so in that case, you discuss, you decide, and you agree that this is good. And you proceed forward. That's a much more simpler resolution than this resolution of contention or waiting. That's a hard one. That costs money, loss. This you can handle by communication or talking. Totally you can manage it. But in a fast moving target, you're just moving, moving, moving. How can you certify that all your QA test passing and all your QA testing actually lands on time and where you need it to be? So now you bring up a different topic. You're talking about testing. So the way I would suggest is how I see people operating in larger companies is that at least in old time Microsoft used to have this trial role of PM, dev, and test, if you recall that. You have a PM will write the specification. Then you have developer will write some code. And then this guy will test it. The good old days. Yeah, the good old days. This is gone. The present days of Microsoft. Right. So this function, this style is gone. This style of operation is all gone. So the idea is that you don't throw code out to another window, to another person and have them test. But the idea is each one of us tests. Each one of us, PM, dev, test. These roles actually have disappeared in some sense. I think you know more than I do about, you probably are there. I'm not. And we have current employees there with us. So they can tell us how exactly things are operating. But the idea is essentially each member in the team, no matter what role you may have, you should test your own stuff. That's the fundamental premise. That if you are making a change, you better test it yourself. And only then, at a given periodicity. So let's take a different ink here. So you will have, say, multiple team members, A, B, and C. Let's go three. Three is good. So the idea is this guy is working and this person is also working. And they're all working together. And they are causing conflicts. But each one of them is individually testing. Testing themselves. And it seems to work on their own. In fact, each one of them will have a complete clone of the entire repository on their computers. And they are making their changes and individually testing the whole thing through automation. Automatically testing every time you run something, you make a change. The moment you run, it is automatically tested because you don't need a test person there. Because you are the tester for yourself. Because you are writing automation to write code. And any time you actually press the Control-S or File Save option, wherever you have this file and save, every time you press the Control-S, Command-S option, you need to have automation in your system that actually tests it for yourself every single time you run a unit, you press Save, it should test. And immediately tell you whether you have an error or not. Right then and there. So every person who is working and making a change needs to be testing themselves. And then the other concept which is popular among, at least in Amazon, I know, is this concept of a two-pizza team. Two-pizza team is this concept which is, probably you know it already, but the idea is that you will have a team that can be decently fed with just two pizzas. And each one of them, each one of the team members is sufficiently fed. And nobody is hungry. And that's the optimal size of a team known as two-pizza team by Amazon. You may have heard of this word before. So what does that mean is that if you have, say, five to six people, two pizzas are probably good enough for a quick bite or something that is satisfying everybody. And so that's the kind of optimal size of a team. And if your team sizes are longer and bigger and wider, that's a bad thing. That's how Amazon operates. And I think it's a valid way of thinking. I would argue that it's a good way of operating when you have the team small. So you're essentially focused on one part of the problem, one unique and complete portion. So you get a complete portion of something that you're developing together, and you have those five to six people together, two-pizza teams, and you make sure that you are periodically and almost sometimes every other day, sometimes every day, small teams get together and just chat for 10 minutes, see how they're doing, see what work they have done, and make sure that they are actually driving towards that common goal of completing that given portion. You want to make that you complete. And then this same concept applies at a higher level as you integrate other features, other teamwork into larger teams. So same idea where you have five to six people, and you integrate that to create a complete portion. You apply the same concept to a slightly higher level where you have, say, five to six teams get together to assemble the larger picture. The larger picture can be putting together these complete elements that these team members will create, and you assemble them together and have this kind of meeting maybe every Friday or every Monday, so maybe a weekly, and identify in form of your sprint cycles, as you call it, or agile methods companies like to use, and apply those concepts to making sure that you are actually creating something that is useful to the customer. So essentially, each one and every one of us, whether you are a part of a larger team or not, you're essentially operating at a small team level, five to six people, and you're driving towards completing a portion, completing something that is useful. It may be small, but it is complete. This word of completion is a very important word because nobody gets paid if you do half work. People get paid by customers, companies get paid by customers for delivering a full product. You cannot deliver half a product or less than 100% of a product and expect to get paid. If you do 99.9% of work and try to sell it to the customer, the customer is not going to pay for it. They'll say, no, I will not pay because I need 100% of the product. Only then it will be useful for them, and so they will refuse to pay. So no payment for you. And that is the critical thing to remember and to understand is completion of whatever work you have, however small it may be, is to focus on getting that completed. It may be tiny, but completion is important. And that is the focus that I would like you to remember and carry along as you operate, as you collaborate, as you use tools is to divide the work in fashion so that it actually is a complete unit by itself, however small it may be. And keep these completed units together, assemble them together and individually test them yourself without expectation of having a test person to help you. Because I think Microsoft laid off all the test people. I don't know. That's what I hear from outside. And so everybody is gone, gone. And that's a nice thing, actually, because you're basically reinventing yourself to understand what's the next thing that you should be doing for yourself as well as for the company that you used to work for or maybe the new company you work for or maybe your own business is to really focus on delivering value. Delivering value. And when you deliver value, that's the only, absolutely only way to get paid. Only way to get paid. If you do not deliver value and you still take money, I think that is called theft. And that is possible, by the way, in many cases it might happen that people deliver less value, but they still get paid. And I think that is almost theft. I'm not defining it to be theft, because I'm not a lawyer person. But I'm basically saying that you give value, and then you're very likely to get paid. In fact, your contract will be obliged to get paid. So that's the focus at a unit level. Individual level is to keep working, keep building components that you want to be able to do. And when I say components, I don't necessarily mean code. It can mean anything that constitutes together to form a thing that you want to sell it to the customer. It doesn't have to be code. And it applies to any kind of business. It doesn't apply simply to software development, not just for this. It applies to anything, just anything. You deliver value and get paid. Make it complete 100% for the customer and give it to them. The customer will more than happily pay for it. If they meet the need of the customer in 100%, they will pay you. Absolutely. That happens all the time. So that is a slightly longer answer than you expected. But let's keep going with questions in the context of collaboration. So Git is basically about collaboration. And this discussion will eventually lead to DevOps. How do you collaborate using tools like Git, for example, and other tools to synchronously deliver services to your customers, typically over the cloud? So you have cloud-based services. You deliver it to the customer. And this customer will receive those services that you want to deliver. And your team is basically making sure that you're collaborating and automating end-to-end delivery of your services to the customer through the cloud. So let's go take a quick look here. I'm looking at this picture here. So when I say final production branch, like I mentioned, your team members are collaborating, merging, incorporating changes, and basically creating a team development work here in this blue section. And at some point, you decide that now is a good time to give it to the customer. Some companies today, especially the more recent modern companies, they're able to do a cycle of product development and do push to the final production branch almost any time they feel like, any time. So it is not every month, not every week, not every night, but just about any time they feel like they are in a position to push to the final production branch anytime they have a need for it. And that is one of the goals in terms of automation and using tools like Chef and Ansible that we will cover pretty soon in the next three sessions away from us from right now, is to basically use those tools to automate and have the agility, have the ability to make an impact to the customer any time you need based on the need. And so that design, we want to be able to see as to what things do we need to put in place so that we are capable of pushing a change to the customer anytime we feel like. It doesn't mean that we go whimsical and do whatever we feel like, but actually anytime the customer needs that change that we are able to give it to them on demand. So it is basically being driven by the customer's need, being driven by their demand, is to operate in a fashion to orchestrate our entire teams, Nilesh and Dan and David and everybody in the team, to operate in a fashion that we can actually deliver a final production to the customer and deploy it in the cloud for the customer to consume that service on customer's demand. And that change requires a lot of not only software and tooling and technology change, but also how people operate. And that's what something we'll discuss maybe. It's coming soon, like two sessions from now. So we will talk about these things pretty soon. How do you do that? And then we do use tools like that to actually make it happen. We'll start that discussion at a pretty short time from now. I think today is day number seven. So yeah, one more session on your platform as a service that we would like to do the next time. And in fact, after having understood this little bit of Git, I would like to talk about platform as a service also today and do another exercise with you that will use Git, that will use the Heroku platform. And there is a step-by-step written down already somewhere here that you should be able to grab and walk along. But I would like to actually show you that in real action. So I will basically start my virtual machine. Break? Yes, please. Break is a good thing. So we'll take a short break and then proceed. In the meanwhile, let me just quickly check my time. So I know how much break you want to take. So the time right now is 6.45. We'll take a five-minute break. Is that okay? Should be okay. What do you think, five? So 6.50. Right now it is 6.45 p.m. So we'll take a short break and resume. We will use platform as a service. And I'll begin describing it and showing it to you along the way. There is an exercise for you to do it on your own. It is fairly easy, but it looks fairly long. That's the only challenge, but it's not difficult. It might look long, but it is not that actually long from a time consumption perspective. It should be very quick. I should not take you more than 30 minutes for that exercise in itself. And I will probably take longer because I'll explain along. And that is what I'm intending to do. So I'm going to that site and then I will take a short break. And so in that location, I will find that exercise. I think it's one of the modules that you saw somewhere here. Yeah, this one, module 15. That's where I intend to begin. And so we will do that exercise in our virtual machine. And we put them side by side. So I'll be back in one minute. I'm keeping the microphone open, keeping the camera active, and I'll be back in just a minute. Okay. Okay. Okay. Okay. Okay. Okay. Are we going to use the virtual machine? Yes, sir. I think I missed you. Yeah, sorry. Yeah, no worries. Go ahead. Are we going to use the virtual machine again? Yes, indeed. It will be useful because that machine is set up already with all the tools needed to make Heroku work and Ruby work. So our idea would be to use this platform from this company called Heroku. And our idea is to take some application and deploy it here and see it live. And it doesn't take too much work to make it happen. If you try to run that application on your own, it will require a lot of work because what it takes is on the underlying infrastructure as a service, you will have to have these dependencies that you have to manage. And then all these dependencies that are needed need to be actually meeting the requirement of the application that you want to run. And then you want to be able to scale this infrastructure out or in as you like. And that scenario is where you want this application to be made available to your customer. Now, if you want to do that on your own on an infrastructure as a service, this is the hard part. And so what we want to be able to do is avoid at this moment, avoid the hard work, but instead use platform as a service. And so it is very easy. Just take your application and put it right there. And this company that provides platform will do all this grant work for us, grant. They'll do the grant. We don't have to. All we do is just take the app, put it on the platform, and it becomes available. It scales, no problem. That's the core idea behind platform as a service is you get rid of the grant work. You focus on your application and let other people deal with this grant work so you don't have to worry about it. So just focus on the application development, give it to the platform, off you go. App, pass. And done. That's the idea. So it's actually simple. What is difficult is to run a platform yourself. This is going to be you. Then that will be difficult on a infrastructure as a service. So if you outsource this to Heroku, super easy. Outsource this to Microsoft, super easy. Outsource this to Amazon or Red Hat, OpenShift. A bunch of companies do this, by the way. Google, they will provide you a platform. All you need to do is give them the application, and they will scale it for you, scale out, in, and all you do is you pay them money. $30 per box. That's the kind of pricing approximately I think they have. They may have reduced the pricing, but that's my memory tells me that's the pricing, roughly, depending on what the box size is. They may be a little bit less. This is an old number. The pricing may have gone down. So that's the exercise I wanted to be able to do is to help you understand this concept of platform as a service where we will begin using Heroku. And we are ready. So we should do that. Which means the first thing first, go to heroku.com, sign up. It is a free service. The free service is free only if you go, you stick to only one dino. So if you go more machines, more dinos, you have to pay for it. So we'll just begin with one, which is free. And even that one dino that you get is $33. The first one is free, but it is free with a condition. The condition is that it will run not 24 hours a day, no, but only 18 hours. Yes. It will sleep for six hours. And that's the design for free. So this is the free model. This is the paid model. If you want it to be running all the time, you pay them money. If you're a developer trying to learn, you sleep for six hours, your machine will also sleep for six hours. And you will work for 18 hours, and this is free. And you can learn. And so that's the model I think I want to use right now. So we'll take the free model and just start learning. And so that is where this pricing is. For heroku, you can see the pricing shows that it is free. And there are a couple of different plans. You don't have to get any plan. Just go to the free one and proceed to create an account. It takes half a minute. Authenticate your login name, password, and you're ready. The idea would be to log in using a terminal. And so here in our computer, we want to log in onto heroku with the terminal. So here is heroku.auth.login. That's the login method. This method, heroku.auth.login. I'm going to log into my account using the terminal. And it says heroku command not found, which is interesting. Which means I need to first install this software called heroku on the machine, which means I need to install heroku tool belt on the machine. Now, the heroku tool belt can be installed using one line they will give you here, which is this line. This one line should do it. And so I'm going to paste that line in your Slack chat. And also in the OneNote, I'll make a note of it. And I will run it right here. And this line will install heroku tool belt. I'm going to give my machine password. And it installs heroku tool belt, which finishes that step. I will proceed along with this instruction after I install heroku software on the terminal, which is basically a method of operating on heroku using the command line. It's much faster that way. There is a browser-based method also. But again, it will at some point expect you to be on the terminal because you are going to be an application developer. So it is expected that you are there. So we have installed heroku command successfully. Now we can log in. And here it will ask you for a login name and password. I'm going to grab my login name. And I will find out that my login name is this one. So I'm going to copy that login name. And then I will copy my password and then type it in. And it should let me in. So now I have successfully signed on. It shows me that I am logged in as me. So I'm connected. That's the beginning step. If you keep proceeding forward, most of the steps, I think absolutely every single step is written down. Having said that, I'm going to follow along quickly. In this step, what I'm going to do is provide our key pair to heroku. SSH key pair we want to give to heroku. So this command will do it for us. What we are going to do essentially is to establish a SSH connection between our machine, the terminal window that we are working on, and the heroku services. So the platform as a service that heroku runs. This connection that we want to be able to authenticate, we will do through SSH key. And for that, we have to create a key pair here and send the public key there and keep the private here. That's the action that we want to do manually. That action, this creation action and public and private, keep the private private and share the public with heroku, that action has been automated for us. So we will run that command, which is this. So that one line command will do all of it for us. And like this, we'll say create a key pair. You don't seem to have a key pair on my machine. So would you like to generate one? And I'll say yes. It might tell you that you have a key pair, and so it's going to use your key pair and that is also okay. I think most of you have a key pair. I don't. So I am going to generate one and I'll say fine. Please generate one for me and put that in the SSH folder right there in that location. And then the public key will be copied over to heroku. So I'll go and do it. So it does. It sends the public key to heroku and we are all done. So basically, like what we do by hand, it will do it for us. So it uploaded that public key over to heroku already, which means in our heroku account, you can go and see the key. Heroku, login, and I can see the key visually. If I sign in, I should be able to see that key pair somewhere here. If I log in, I should see my key right there somewhere in heroku. And that key pair should be in, come on, where are you? Creativity, account settings, security settings. I think one of these keys has just got added. I don't know which one it is, but one of these four keys that I show, one of these guys, I see one, two, three, four. One of them is the one that I just uploaded through this method. So now that we have the key there, the next idea would be to build a new application. And it's going to be a very simple application, a trivially simple application that just shows you the time of the day. Very, very simple. And we will use the Rails software. As you probably know, Ruby on Rails is a great application. Rails is developed by this gentleman. His name is David. He is a founder of a company called 37signals, which has a new name called Basecamp. And he created the Ruby on Rails software, which is what the foundation was to construct Twitter and GitHub. And a bunch of other companies are basically built on top of Ruby on Rails. So GitHub and Twitter are the original two, if I remember. But then there are many more that use this software called Rails. And Rails is available like a gem. You know, you recall we did some Ruby gem work. So Ruby gem's website has the Rails gem, and it has been downloaded 76 million times. And it is in version number five available right now. And that's what we intend to use. So to create an app, we need to make sure that we are installing the Rails gem, which means first we want to be able to make sure that we follow along those steps. So create a new Rails application is what we intend to do using Ruby on Rails software. So we will install the Rails software, which we do not have in this. So we'll say gem install Rails. And that's what I intend to do. So gem install Rails should bring down the Rails gem. And along with it come other gems that may be necessary for us. And so this Rails gem has a bunch of dependencies. Those dependent gems will also be built and brought down to our computer. This particular Nokogiri action takes a little bit of time. It also requires more memory. That is something that I cautioned you last time, that you need to have enough memory on your machine in order for this build to succeed. This build will fail if you do not have enough RAM on your virtual machine. So in my machine, I think I remember I modified the RAM to about 2048 MB. So that should be good. It should not fail. So it finished. That portion that took a while actually finished. And now another one that also finished. And so we succeeded in installing all these 36 gems that are needed for Rails to work. And you can see in this machine that on that gem that we have installed, we need to make sure that they are available as an executable. So we need to rehash our gems. So that is this command. Very simple. Rehash the gems. And so the idea is to use R, B, E, and V. Rehash the Ruby environment. Rehash all the gems that we have. Where is my mouse there? Yeah. So what I'm doing is R, B, E, and V. Rehash. And this rehashes my 36 gems that I added. And now I am going to delete any folder that I might have by this name called MyApp. MyApp is a line that I have here because people repeat the exercise many, many times. And sometimes they will forget that they have created a folder called MyApp. And they will leave it like this. And then you create a new app and that older folder conflicts with your new folder. So that's why we have this line to remove that app folder that you might have from a previous attempt. There is no reason for this line to be there otherwise. But since I now have a folder called MyApp, I want to remove it. So I'm going to remove it. And then I proceed in creating a new Rails application. Creating the application is just running that line. That's all it takes, by the way. For those of us who have never created applications, you will find it amusing how easy it is to create applications. It is literally a joke. I mean, honestly, it is this gentleman doing all the hard work for us. He has done it. And so what he has done is basically given us tools to write code through simple techniques that I'm going to use right now. He will basically do all the hard work for us through his software, creating a new application. That's the command for that. And we are in this command saying Rails new application called MyApp. And so Rails new application by the name MyApp that uses the database Postgres SQL. And that's what I want to use. And this Postgres SQL is a recommended database that Heroku recommends that you use. And so you will find that when you are deploying a Rails application on the Heroku platform, that is a recommendation. And so we are at the very beginning following along with what the platform needs. What does that really boil down to? It means that we know that we want to deploy an application on some platform. So we are building our application, beginning to build our application. And we are building it in a fashion that already fits the need of the platform. Now, Heroku uses Postgres SQL as a database. By the way, this is probably 30 or 40 years old. Let's see how old this database is. Very well established database system. Postgres SQL is an ancient and very mature database. It is also known as the world's most advanced database system. Let's see the marketing for it. What does it say? World's most advanced open source database. And I think it is pretty rock solid. I honestly think it is pretty beautiful and open source and it works. It has never failed on me. And that is one of the reasons I like it. And Heroku also recommends it. And that is what we are intending to use. So in this one line, we are basically creating a new application that intends to use a Postgres SQL database. And there we go. So it created that application for us. It will bring down whatever it needed to make the application work correctly. And we should be ready with it as soon as this thing finishes. So it is building whatever it needed to make the application ready for us. It is going to give us a template, a place for us to run our application. And it failed. It said error installing PG. So PG was missing. So we need to install this application PG first. I think I don't have PG in my machine, which means I need to get Postgres installed. So I need to quickly install Postgres. This is a change I need to make. In the writeup, I don't mention it. In that writeup, I should mention that Postgres is needed before you create and use a database Postgres. I need to install Postgres quickly here. And so I think that should do it. Let's make sure that it is the right method. I think that should be the right method, just confirming that. And these two lines should do it. Those two lines are these two. And I'll do them both one at a time. And here I'm installing the database itself on the machine. And it is proceeding along, which gets me the database installed and running. Once that database gets loaded up, we should be able to continue along and finish that step, which was missing in the previous attempt. The red line showed that we could not do this action, gem install PG. We could not succeed. So we had to run the bundle install command one more time, which is what I intend to do after the Postgres installation finishes, which seems to have finished. So I'll just run bundle install after that. Sorry, bundle install in the My App folder, so cd My App, and then bundle install. And this should actually install the missing elements, like the PG element that was missing. Now it will find Postgres database and still failed. Make sure that this PG is installed. It fails because of what? That's what I'm trying to find out, why it fails. Gem install PG has to succeed. And it fails because... If this fails, I think I am going to skip this exercise. I'll do it on my own and then I'll give you a machine, a different virtual machine that will have all the things needed to make it work. That's what I intend to do. If this fails, I don't want to waste your time on this meeting where we are debugging, which is probably unnecessary. So I might want to actually skip this discussion altogether and doing a live demo because if it starts to fail like this, it will cause a waste of time and all of you watching and doing nothing, which is not very interesting. So I don't want to do that work at all right now, which means I will later on give you a separate machine for you to use. It will come down in your synchronization software, the Resilio Sync. And in that machine, you should be able to work this exercise no problem. I will push that machine out sometime tonight, and you should be able to continue along this same step sequence without any trouble on the other machine that I will send through the Sync software that you will receive tonight. I do not want to further waste time on debugging what's going on here because I think having six of you watch it doesn't make sense. So I'm breaking it and quitting that exercise completely. I will fix this tonight and send you a new machine. That should work. Having said, let us understand a couple of other things from a platform perspective. I will skip that exercise that I was doing, so I'm going to shut down this machine. I will talk. So in the action for me that I will do on my own is tonight, I will send a new machine for you so that you can run the Heroku exercise yourself by following along module 15. And I think that should be one of the easiest exercises we have. It seems long, but it's basically one-liner step-by-steps that you can follow along to get this idea of how do you create an app, how do you deploy it on a platform and make it available to your customers and make it scaling by itself. And the scaling out happens only if you pay them money. You don't have to pay them money, but just understand that once you pay money, they will scale the machines out for you. Now, if you see similar steps that you just saw here in other platforms of service, platforms as a service available in the industry, let us go take a quick look at a couple of them. So in this browser window, I'm going to make it a little wider. And in there, you will find that not only this platform that you see, the Heroku platform, gives you a choice of running your applications. The core value proposition essentially is you... Where is that? Heroku. The value proposition is you get straight to building your applications, and you do not focus your time in managing your infrastructure, which can be daunting. As you can see, a bunch of things going along, you just wipe that off and you focus on building your application, you deploy, you manage, and you scale. You don't have to worry about these things. That's the core value proposition that this company or this platform as a service provides. Similar to this is the other example that you may have heard of, that probably some of you may have used it also, is this one from Microsoft. You may have seen it. I think I need to log out to a different account, not this one, where I have a login. So I'm signing with a different login, and that is this one. And it will log me into the Azure account, which provides us a platform available to us for us to deploy Windows-based applications. And not only that, these days Microsoft also provides a platform for us to run other non-Microsoft applications as well. For example, here, new and web application, you can create from gallery, it's not available. Okay, go to the new portal. Apparently the new portal is what Microsoft is pushing everybody to, so they don't like me to use the old portal, so they have disabled it, apparently. So in the new portal, this is what it looks like in a Microsoft Azure account. And here you can create a variety of applications that you can either in the open source domain or things that you will create yourself. All you need to do here is basically start those applications that you might have in mind. For example, all of this interface is new to me, so I'm still exploring this. I'm used to the older interface. But if you want to create, where are they hiding it here? Let's search, WordPress. And here you can just click and deploy a WordPress application by clicking this button. It is as simple as that. So here, as soon as we proceed forward, and you create an application, give it a name, and so I'm going to select a name for it. I'm going to say Cloud Genius and create a new resource group, get Microsoft SQL. Oh, nice. You see that this is MySQL. This is an open source database Microsoft provides now, and it is in preview mode as opposed to the older database that you used to have. Microsoft now is providing MySQL in app preview, which is beautiful, and that runs a local MySQL instance with your application and shares resources on the app service plan, and that is not intended for production use. They will not scale beyond a single instance, so just remember that this is not scalable quite yet, but it is in preview, so Microsoft will come up with a solution for us to use MySQL databases and run our own WordPress, and we should be able to basically create. There are errors here somewhere. We have to create a use, create a new. The value should not be empty. Where is the empty value? Come on. Use existing. Let's use this one. And let's go create. And now it is going to install the WordPress application for us, which is this application from here, open source WordPress.org. That application gets installed in somewhere. Where did it go? I just clicked on it. It should show up on the dashboard somewhere, apparently. Otherwise, we'll give hard time to as the deployment started, so it is telling us that something is getting deployed, and it is deploying. Let it deploy while we go to another cloud company and see what Google does for platform as a service. Google App Engine is the name of the service that Google provides. This is basically a platform as a service from Google where the idea is to take your applications and run it on Google's infrastructure, and they will help you scale it. The bottom line is, again, same thing. You will have a console to go to. This is the App Engine console. If you have a Google login and a credit card with them, you have a language to select, and there you can select Node, Java, Python, PHP, Go, or Ruby language. These languages are supported. Just like a variety of Heroku languages that you can see. You can see what language does Heroku support. I think the languages choices are similar to what you see in Google. Google has these names, these language names. Heroku has probably similar. In concept, you can take a Ruby application and say that I want to use Ruby, and you say continue, and it is going to clone a sample code for you. It is basically take a sample example, and that is what you will select, say development, and in here, and continue along. It should actually take you to... I think it's running a demo or something, which is not what I want to run. I want to actually go and deploy some example code ourselves, but that is not what it's doing, which is interesting. It is running a demo. Now, I don't want to see a demo, so select a language, select Ruby, and let me run my own application. So continue cloning a sample code. Tutorial will continue automatically once it is done. Now, that's not what I want. We have sample Ruby code prepared for you in the Google Cloud repository. To view your cloned code, click the menu button, find the development section, then select it. So here is development section, and click it. So click that, and then development section, and then we clicked it, and here we have the source code get started. Now, you can push your code from a local repository that you might have in GitHub or in your local computer, or you can have your repository cloned to a local Git repository and also mirror from GitHub or Bitbucket. So three choices of sending code to Google, which is one from your computer, one from your cloud repository if you have, and the third one is from GitHub or Bitbucket, one of those two services. So if you happen to have some example application, you can select that from GitHub and connect. When you connect, it will go to GitHub and authenticate yourself. And then you can type in your password and see which application that you already have on GitHub that you want to actually deploy. So it will here give you a choice of all the repositories that you might have there, and then let you select. So here are a bunch of applications that I have as examples that I want to maybe select. And that is exactly how you would go ahead and select an application that you might have in your GitHub account and load it up on Google Cloud, and it will run. That's the core idea. Just like you're looking at Azure in Microsoft, and it is still deploying. Let us see whether deployment is finished by refreshing the screen. And it is succeeded, which means that we should be able to access that particular location with our browser. So let's go see what they have provided us in terms of an endpoint. Cloud Genius Hosting Plan, Hosting Location, the operation details, and where's the endpoint? What does this mean? Templates redeploy? No. I want to see my services that I'm running. I ran WordPress. So where is that thing? Oh, man. What does this say? No, not this. I need to get the link to the endpoint to see WordPress, and I don't find it in the new border. OK. Now, I don't want to give hard time to you guys in Microsoft, but I think this is bad experience, unfortunately. I cannot find my own application that I just deployed, and that is crazy. Maybe that is it. Maybe this is it. I think this is it. No. This should be it. Let's go compare. So comparing notes with what I wrote here, and what I started was this name,.azurewebsites.net. That's where the application should get deployed, and it is not there. The application activity log doesn't give me anything like that, which is nice, which is very nice. What about this one? Does it give me anything? I think that may be it. So go hit it. What about there? You should see WordPress, please. Show me WordPress. Then I will say that Azure works in the new border. Otherwise, I will complain that Azure doesn't work in the new border. There we go. So we have WordPress. It was slow, but it came. So now we can proceed forward, and you saw that I was able to deploy WordPress very, very easily. I mean, not so easily, but almost easily, I could say. And now we have to allow WordPress on Azure, username, password, and confirm the use of the password. And off we go. So we have this password, and install, and say not now, and we are now connected. And it is slow, as you can see. But we have to wait for it. And now we log in. And then we type in the name and the password. And we should be in, in the dashboard. And nice. Yes, we have it running. So see how easy it was for us to pick an application that is already available in the community and just run it. Now, if you're developing your own application in your own code, there is a message from somebody, or no? Yeah, I just, I just messaged. The gem install PG was failing because I put it in the Gargan room. I see. You put that in the Gargan room. It required the Postgres Devpack. OK, OK, OK, OK. Good, good to know. Thank you, thank you. It requires gem install PG, libpqdev. OK, thank you for pointing it out. So we will go resume that if that is appropriate. But let's go see. So I'm going to start it up again and see if we can proceed forward. Thank you for catching it. I think PG was missing in my machine. That was the problem. And so PG and libpqdev, those two tools should be added on. But let me finish this Azure discussion. The idea was to basically grab any application from any developer that either you develop in-house or you are using open source community-provided applications or you are buying commercial applications, wherever you bring them from, commercial applications. Either of these, you have to have a unique set of dependencies. And as long as those dependencies are met by the underlying platform, each one of them will have a unique set of dependencies. As long as these dependencies are met by the platform as a service, then you can have very, very effortlessly deploying your applications, open source applications or commercial applications that you buy or rent and run on some platform and have them function like we just did this example of using WordPress application and deploy it on the Azure platform as a service. Azure already understands how to deal with the dependencies and the uniqueness needed for the WordPress application because it is a PHP, MySQL, Apache application. So Azure already knows these things. So they put these components together for us and all we really need to do is to make sure that we give them the name of the open source application or our own application if you have yourself. Give them the understanding of what dependencies are needed and then you run it. It is as simple as that. And this gives you a scalable infrastructure under the hood. Now, as long as like in case of Azure, the clarity, they said that MySQL solution is not going to scale because it is still in preview. So you don't understand these details from that particular platform. They told you that MySQL will not scale. So you don't understand that that is not going to be a scalable solution. In that case, you will go to some other cloud, like not this but some other cloud you find and run it there and they will scale it for you. Azure is not yet ready for scaling MySQL, which is understood. They told you upfront. So let's continue along with what Ram just helped us in locating the error, which was basically making sure that we run the libpqdev application. So those two things that Ram has given us, which is app.get.install.pqdev, which is lib library for libpq. And we are going to install it. And then we should be able to say gem install pg and then bundle install in the myapp folder. And that should continue along in our journey of creating our own app, like I described here, our own application. That's what we are really building right now. We just did this portion where we took an open source application and deployed in the cloud that worked along with some limitations of not MySQL, not scalable, which we understand. But then other solutions will provide you a scalable method. Your app that we are going to build, our own app right here. So this gem pg finished successfully. We should go to the myapp folder and say bundle install. And that should finish the bundling process. And we should go forward with our series here. This discussion that we were doing early on should continue. So that Rails gem finished. Now we should be able to go inside that myapp. We are already there. And I think this spring stop applies to older versions of Ruby. Sorry, older versions of Rails 4.0, I think, that is not applicable. But you can still run it. It doesn't hurt. Spring stop, you can run that. It doesn't hurt because spring is not running, so nothing will happen. And you proceed forward with the next step. What we are really doing is building a new application using Rails. So the idea here is this concept of model, view, and controller. I think many of you already know this intuitively, but I will help you understand what is MVC quickly. And so if you do not know this, here is a quick primer. The primer behind model, view, and controller is like this. In writing code, the idea is to separate the concerns. What is a concern? A concern is something that you have to worry about or do something about. So if we have a model, a view, and a controller, three separate pieces or areas of code, the model is where you store your data. The view is what it looks like. And the control is how it operates like. That's how you should think about MVC. So let us redraw this MVC again in a different fashion. Imagine you have this control piece of software. And this model piece of software. And a view piece of software. The control is the logic, the brain, the function. This element you cannot really see. There's nothing visible, nothing to see here. It's only logic, the brain, how the application is going to operate. The view is what user sees. User sees this. And model is where the data is stored in the model. Now let us take a quick example as to what it means. So you have, let's say, an application that you are creating, and managing dogs and cats. So there is a view that shows you that you have zero dogs and zero cats right now. And that is awesome. I mean, that's how you begin. But then you go to the shelter. And in the shelter, you find a dog that you like. Then you bring it here in your home. And then the representation changes because you now have one dog, zero cats. And to address this representation and show this view of one dog and zero cats, the view changed from zero to one. And who changed that thing is the logic. The logic said when you bring a new dog, you should change this number from zero, make it one. That's the logic part. That's the control part. The view part of the code is going to show whether it is going to show you one or zero. That's the view representation. And there has to be another place to store information about how many dogs and how many cats you have. And that is the data store, the model. This model will actually keep track of how many dogs and how many cats you have. And so when you want to run and create a complete application for dogs and cats, for example, this view might show you that you have one dog and no cats. And in the database, you have dogs equal one and cat equals zero. So this is the model. This is the view. And your control logic runs in a separate piece of code that controls what needs to happen when you go grab one more dog and now your dog count becomes two. So your view should change like this. And when you get two more cats, so it becomes two here also, you should get view like this. And this is how you separate concerns in your code writing between model, view, and controller. Does that get the point across in terms of NAMDC? NAMDC is that you have a dog controller to control the number of dogs and show how many Ds you want to show. And similarly, you have a cat controller that sees how many cats you have and shows the number of Cs you see. You get that? The separation of concerns, idea? Any comments on this? Yeah, pretty clear. So that's what we intend to do in this step here is we want to be able to understand NAMDC and then proceed to creating our own NAMDC structure. So we'll create a welcome controller. This welcome controller, by the way, our app, what we are building essentially is a view that shows us the date. That's it. Date and time. The time right now is whatever that time is. That's what it will show. That's the only application. It's actually trivial, very, very trivial application. That's what we want to show. The time right now is blah. That's the view. To show that view, we need to have a controller to something that I call welcome. And this welcome page is the main page, the front page that will show the time right now is whatever time is. And that logic we will call the welcome controller. The welcome controller controls whatever you see. The time right now is blah. And in our example, we don't have to worry about a model because there is no data to really worry about because all we are doing is just showing the time. So there is no model. Model is not needed. Welcome controller is needed to show the place where you can show the date and time and say that the time right now is blah. And the view will actually show you how it looks. And that's the controller that we are creating. So we don't have to write code by writing code as in writing Ruby code, but we generate code. And thanks to this guy, DHH, who does it for us. So this guy is doing it for us. Thank him. And while he does that, let us make that run. So in our window, we'll say Rails generate controller called welcome. It generates for us. And we have a controller running. Nice. What does it look like? It creates a bunch of files and folders. And we'll quickly see what they've done for us. So let's go see what they did. And so inside that welcome controller, we will see what we have. Yes. Quick question. So are you using the new updated virtual box image for this one? Correct. Both of them are still Node.js or any? Yeah, the only one thing that is missing from between the new box and the old box is one line command. And I will type that command in Slack chat. The command difference between the two boxes is that's it. That's the only difference between the two boxes. That is basically David found out that Node was missing. And so we added Node and just pushed a new image. That's the only change I did. And so in this machine, you will have Node. In the older machine, you will not have Node. So you'll have to add it. That's it. Now, after having created a controller for welcome, we'll just inspect the content of the folder and a tree, and that tree opens up in Atom Editor. And we'll see that we have a bunch of things already now. We have an application folder. We have a binary folder. We have a configuration folder. And this and that goes on and on. So this code is written for us automatically by the gentleman DHH, who is David, by the way. And that RubyRail software wrote this code for us. And it is kind of usable already. It is already useful as is. We have to make some changes to make it suit what we have in mind in order for us to make that welcome controller show something. What do we want to show? We want to show the time right now is, our time at this moment is whatever the time is. That's what I want to show. So I want to create a view. A view is created by creating a file in a specific location. The location happens to be the application views. You see how the separation of concerns is working? Assets, channels, controllers, helpers, jobs, mirrors, models, views. These are separately called out like here. So there is a view folder. And in there, there is a welcome folder, which contains nothing expected, totally expected. It contains nothing because it is empty. It doesn't know, it doesn't have a mind of its own as to what to do. So we had to tell exactly what we want to do in the view folder. We have to go in the view and then welcome. And inside that welcome folder, we had to create a file called index.html.erb. That's the name of the file we need to be. And so we have a new file. And in that file, we will save it in that location called application, views, welcome. And then the name is index.html.erb. And that's the file I want to edit now. And in that file, this one, which is this file name, index.html.erb, that's the file name. I will now insert this content, which it basically says, hello, cloud genius. The time at this moment is time.now, meaning the time right now. This line, time.now, is a Ruby expression showing the current time. Whatever the time is at that moment when you run it, the time at that moment is time.now. That's a Ruby expression to show whatever the time is at that time in the time zone of the browser. So whatever the browser is, whichever country the browser belongs in, it will show you that time for that browser in that country, wherever the window is open. And it will show you the time at that location. We will save it and close, Ctrl-W to close. That particular file closed, we'll proceed to the next step. We have a new view created. We have to now understand the logic. And so we have to define a route to the welcome action. What is a route? So a route is basically a place to go when somebody visits your application. So if you have a website, www.something.com, and then after that.com, you have a slash, followed by whatever, or followed by nothing, whatever it may be. So this nothing basically implies that you are going to open the index file. When you say nothing, it will open index.html. If you have something, it will open that something. If you have nothing, it will assume this and open it. So between something and nothing, you have to have something. So instead, I'm going to use the nothing portion, which means I'm using the slash route. The route to my application is after the address, www, followed by nothing. So that is the route that I want to go to. So anytime people visit that location, which is defined by the slash, which is the main application, the gateway to the application that happens to run on this site, this is the main route. And that is what I want to address through the welcome controller. So anytime people visit the www.whatever.com slash route, the main route, I want this logic to run. And in this logic, I will show them the new view that I have created, which basically says this. Time at this moment is time.now. And that is what I'm intending to do in this logic. This logic basically is whenever people visit the site, which is the main route, I would like to write my logic to open and show the current time. That's it. So I'm basically modifying a route and associating it with the welcome controller. That is what I'm doing next. So here, I'm saying adding a route to the welcome controller, and it says, edit this configuration routes.rb, which is not in the app folder, not here, but in the configuration folder. There is a routes file. And this routes file is what we want to edit. I think there is a change in Ruby 5, apparently. I see a ready reference to this. But never mind, you can add this. You can just add this route. In the write-up, I see that I have a removing the hashtag. It will look like this. There is an older Ruby version 4 used to have this. The new Ruby doesn't have this. New Ruby in Rails version 5 doesn't have this. Rails, I think, 5 just came out, it seems. The Rails 5 release was... When was it released? OK. Any ideas when the Rails release is going to be? Rails 5 release, the answer is... 5.01 was the stable version. It was released on August 11th. OK, so this year? August 11th. That's fairly new for me also. My writings and lessons are written on version 4. And this is August, as in last month. So yes, that updated, not updated for version 5 yet. So we can tweak that a little bit by going back a step, if you like, or we can... I think going back is probably better. So I'll tell you how to roll back to an older version of Ruby by modifying our project a little bit. So by default, when you install, you say gem install rails, it does it for you and it gets you the latest version. But I don't want to use that version. I want to use the version that I want, the older version. So we can go grab a little bit older version by modifying in our project folder, modifying a gem file. Somewhere in here, you will find it. This file should have a reference to the version of Rails 5. I will make it to go version 4. And so that is what I intend to do, go a little bit older. And where is that older Ruby Rails version? Okay, this is the latest. But what about 4.271? That's a good one. So we'll say, get me 4.271, please. And not that one. So I'll just save this and close, close, close. And close and say bundle update. That should bring me older gem, older Ruby Rails gem with version 4.0 installed. And that, I think, is coming down. You can see references to 4.271. It was 500. So I brought back a little bit. And now I will do a couple of steps again, which are the previous steps, which is I have to generate my controller one more time with the older code, not the newer code. So I will generate. I think it's better to do it fresh. Better to do it fresh. So I'm going to remove this MyApp completely. That might cut down some of the confusion if you're doing it first time. I might have removed my apps folder completely and then quickly go back a couple of steps where we were. We did this step a while ago. So we are going to resume back to that point and proceed forward from there. So we are removing older version of the application and then create a new app like that. So here the app is deleted. I'm going to begin creating a fresh app and it is going to install the newer version of Ruby again. And I will go modify that MyApps folder and make sure that Ruby version is the older version. So here we have to go, say, 4.271 again, 4.2.7.1 and remove the new reference, put the old reference back, and then do a bundle update. So bundle update. That's what I'm doing to MyApp folder and then bundle update. And this should update to the older version of Ruby on Rails, 4.0, 4.2.7.1, this version. And now we proceed to the next step, which is where we understood MVC. Then we proceed forward to understand generating a new controller, which we did again. So it's going to create a new controller this time, and it fails. And it hurts. I don't like failures, but they occur occasionally. So it says uninitialized content, development RV, uninitialized constant, active support. I think it's cross-dependency problem, probably. I think it is a dependency problem. So basically, let me do this grand work. I don't want to waste your time, really. Thank you for pointing out this PG resolution around, but I think doing it live interactively with you guys on the phone is a waste of time. So let me deal with this later. I will provide you a resolution to a clean working method where you can find out how to basically generate an app and not run into errors like this, which is mind-boggling if you're seeing it first time. They're not mind-boggling to me because I've done it many times, but it is scary. I mean, look at this. Look at this ugliness. What is going on? Why can't you generate a proper controller and it tells you something happened somewhere, and what is going on? This is hard to digest, but if you are interested, I will work on it myself and give you a clean working path so you can follow along and get to the concept. The concept essentially is to get your apps deployed, and it can be either you create or you use open source or you use commercial. Any of those methods of you using these components, you have to understand the dependencies, make sure that the platform can handle it, and then you run it on the platform that scales for you, and the idea is to pay them money, and they will give you a solution which scales nicely. In the example that we were successful in running was this example. We use WordPress application, and we took that to the Azure pass, and it ran for us this WordPress solution that is still running, by the way, and the solution that you see running is available in... Where did it go? Here? No? Here. There it is running. It is slow to my taste, but it works. It doesn't scale, which is bad, but it works. That's a drawback currently that Azure is developing the MySQL support for scalability, and it's not ready yet. It's previewed. The other topics that I want to talk about for the preparation of the next time, which is going to be a little bit intense exercise, and I'm cautioning you already, it is this exercise after the Heroku 1, which is after module 15, which we will go... I think we covered module 16 already on using Docker a little bit. There are more interesting, by the way, examples if you want to follow along using Docker. Module 16 will give you a little bit more interesting examples that I did not go over with you on a live session, but these are actually interesting. You could try them out, module 16 on your own, and it will give you a different perspective on what that can do for you. There are certain examples you will like to try. These are written down examples that will work just fine with module 16 that I think you should try on your own. If we have some more time, maybe we should try. How much time do we have right now? We have seven minutes. Let me finish describing what this thing is going to be and what elements do you need to be aware of in order for us to actually succeed making it work the next time when we meet. That's what I want to make sure that I do. That exercise is relevant and probably more appropriate for certain types of uses where you want to retain control of your destiny and not depend on third-party companies like Heroku and Microsoft and Google and things like that. Instead, you tightly control what you want to deploy and you are able to basically systematically regulate the entire experience end-to-end all the way from infrastructure layer towards delivering a value proposition, a solution to your customers. The difference between the module number 17, which is this one I'm looking at, which is what I intend to cover next time, and the one that I was trying right now with Heroku is that Heroku is actually pretty darn simple in that you just take your app and you run it. You don't have to worry about these things. You don't even have to worry about because this company is giving you a service and you are giving them money. You don't have to worry about the grant work. All you do is either you create your app or take an open source app and run it. But in the other case, you are actually getting married with the platform provider because you are tied so closely that you're dependent on them to run and scale your service. So as long as you feel comfortable with the marriage, there's nothing wrong with that marriage. You can get married and actually use a platform of your choice and continue using them, and as long as you are paying them money, they will keep providing you service, and that is a good thing. There's nothing wrong with that approach. But sometimes what happens is certain companies that I have seen that do this thing a little bit differently, and that is that they will make you go involve and change your application in a way that specifically ties you towards the platform as a service. They will lock you. An example of that that I ran into myself several years ago is when I was developing an application, I got tied with Google App Engine, and I gladly and probably a little bit ignorantly modified my application to meet whatever Google was telling me so that my application will work on this platform, and I was very happy about it at that time because this thing was free, and so I gladly took it, and I took this what I would call lock because it was free, and I was a little bit naive in doing that. I shouldn't have done. In hindsight, what happened in a couple of years after that is at some point Google decides that they are not going to be free anymore, but instead they will steeply increase the price, and at that time, I got bitten really hard, and I had to actually roll back all the changes that I had made custom to fit Google App Engine platform. You can see this written down in a blog post somewhere here. I wrote about that in 2012 right there in this blog. There's a reference, and there's also another reference where I am talking about the same issue here. Can you avoid vendor lock-in? In that article, this problem that I ran into a while ago, I have written it down. You should read that. The bottom line is that many platforms as a service providers, some of them will want to make you change your code in order for you to fit in so that they can serve your customers, and then you pay them money, and they give you service. So paying money and getting service is all good, nothing wrong. Just change your app to fit a given platform. This is a given platform. That part is bad. Don't do that unless you have a long-term guarantee that the pricing is not going to change on you. Don't modify your application to just unnaturally fit in into a given platform. That is something you should avoid, because it doesn't make strategic sense. The reason is that you want the ability to walk away. Walk away to a different platform as a service. If you don't like them, no problem. Just walk away and use this one. You can quickly walk away and quickly go back to them if you don't have to change your app. That is one of the keys to be able to retain flexibility. I'm not saying that you don't change or you change. What I'm saying is that you retain the ability to change, the ability to go away, to walk away. I think that is a fundamental characteristic that you should remember all across, is that you should have the ability to walk away from a cloud provider. You don't have to go, but at least have the ability to go if you want. Then a very subtle but fundamental shift happens when you do that. The simple concept is that if you have this negotiating table, when you negotiate, and you are negotiating with platform as a service provider, just any vendor, this applies to anything actually, not just platform providers. This logic applies to anything. There are vendors, let's say vendor A, vendor B, vendor C, and you are the only one on this side of the table. This is the negotiation table. The more choices you have on the other side, the better off you are. This applies across the board in anything, any discussion, any business. It doesn't even have to be a vendor. Any negotiations that happen when you are the only one on the other side of the table, you are better off by definition because you can compete these guys against themselves. The moment you have another person on this side of the table, that makes it a little bit different in the game. The competition is tough in that case. If the other case happens when you have only one provider on the other side of the table, you are basically screwed. You are screwed because they can dictate. Always have an option, always have a plan B, or rather if this is A, always create a plan B for yourself so that you can at least have a fallback plan. If this service doesn't work out, then you have the fallback. That leads you to a longer-term success in anything you do. It doesn't have to be cloud services. This fallback plan applies across the board in any negotiation that you do in life, not just platforms, not just cloud services. I think that is something to remember. That is the reason why, that is the reason why in the next section, what I want to be able to do in the next time when we meet, is to run our own platform in our own containers and no matter which cloud. We will begin picking a cloud and create our own platform and then in that platform, we will run our own application and in that cloud, we will basically do something like this. In the example that we have written down there, the idea is to use some infrastructure as a service and we'll create a bunch of machines, some number of machines. Then run a software that is open source, so we retain control. The software is called Days. It's open source and it is like Heroku, pretty much like Heroku but open source. Not as good-looking as Heroku, but who cares? It works like Heroku. It may not be good-looking, but we don't have to have a view. As long as it works, there is, by the way, no view. The challenge with Days is that there is no web UI at all. The only thing you get is a command line, but it works like Heroku does, just like that. All the tools, all of them work. What we intend to do is to run a Days platform as a service and in that platform, once we have this, our own platform. This, basically, you can run it in any cloud. You are not logged up, you are not logged in. You have the ability to go walk away. Once you have this platform running for you, you can then take your applications, run it. You don't even have to pay these guys because this thing is open source. All you have to pay is here, infrastructure layer. With that, you can run it on any cloud provider. Most of them are all the same, basically. Some of them are faster or slower, but they are all commoditized almost to a great extent. With that understood, we'll get an infrastructure as a service, run our own open source platform, and then put an app. Then scale it. Scale it out, scale it back, and we can continue modifying our app and push our app. Yes, we will push the app to our own platform, not to GitHub, to our own platform. Just like we did pushes today, git push to GitHub, we can git push to our platform, and it will go live as we push. The moment we will push our application to our own platform, it will go live. Same thing you will do in the Heroku exercise when I give you a new machine to work with, and you will follow along. You will also do the same thing, except that in the example that you will do with the Heroku thing, you will not have days, but have Heroku. You will have no scaling unless you decide to give them a credit card. But don't, because you don't need to. Don't give credit card, not necessary. You will be able to use Heroku for free and enable the same scenarios of running your applications and running it on the Heroku platform, which in turn runs on the Amazon EC2 cloud, by the way. This runs on the Amazon cloud. We will choose our own, let's say, digital ocean cloud to run our days pass. That's my intention for the next time. It is going to be a fairly intense exercise. I'm just cautioning you. This one-page exercise is fairly, fairly intense. Just cautioning you on that. Read up on it a little bit ahead of time. Let me now work on preparing a different machine. I will push that out to you in that Sync software. You will receive, I think there are two machines right now there. You will receive a third one. I'm just pointing it out. I will label it differently. The machines that are sitting there right now are these two machines that you can see, the old one and a new one. I'm going to delete the old one right now, right here. It is gone from your computer also. Now, the only machine I have is the workstation that you see. That machine is the one that did not work today. I will give you another computer and I will call it Another OVA. That's the name I will choose. You will have a new file here in the same folder called Another OVA. We'll call it just Heroku OVA for that simple. Just call it Heroku OVA and use that one for the Heroku exercise and come back to this OVA for other exercises. That one is just for Heroku. It is already tested. I will do one more testing for you and pass that machine over here. Call it Heroku.OVA and that's the one you use for Heroku exercises. It will simplify some of the errors that you are running into, that I ran into today. You should continue along in that direction. With that, let us resume our discussions on 29th, which is Thursday, 5 o'clock at the same Pacific time zone. We will do this exercise where we will run our own platform as a service using this. This basically says your pass, your rules. Nobody dictates. The dictation I have suffered through that, which is described here. Learning App Engine and modifying it and making sure that we change our application so it works on a specific platform as a service like Google App Engine was a bad idea. I think in hindsight, I can say that. We were very happy that they are giving us free services, but that was idiotic, I think. We did that several years ago. This was 2011 timeframe, so several years ago. But that's what it is. Just remember and realize that don't lock yourself in. That is, I think, a critical thing to remember. Don't lock up because locking up yourself is a bad thing. Have the flexibility, and then you keep using the service. Nothing wrong with that. Thanks so much. Yes. Thank you. You're welcome, sir. Let's resume Thursday. See you then. Thanks so much. Bye-bye.