Hey, guys, we are recording the session, and I was talking we will focus today on Git, then a platform as a service example, then we'll straight up switch to infrastructure as code, meaning using Chef, Ansible, things like Docker containers, and then we'll spend quite a bit of our time in this segment, which is Kubernetes, which I have written in the entire segment. You can actually take a look. This is, I think, at the bottom of this listing somewhere, wherever you will find it. Extensively rewritten the whole thing, and most of it is live exercises. So we'll focus on our energy on that, which is this item here, Kubernetes, and that's the new element that we will be incorporating in our bootcamp based on, you know, some of you have told us that we need to go deeper, sooner, apparently, you know, some of you are already experienced with some of these technologies. So it's initial few sessions are actually a review, so get everybody on the same page. And now that we have everybody on the same page, I think we should focus in greater depth. So that's the plan. We will begin today with just a reminder to everybody that please clean your browser cache. If you do that, you should be able to see this new feature where you can just search for anything inside the website. I know it is difficult to identify which sections are where, so that's why we have incorporated the search capability. You can just see that you can easily search whatever you want. Right in the window on the top, that window should be visible to you right here. And that is where the new capabilities are incorporated. It should work for you already. It is working out nicely. It is very, very fast, really fast search, as you can probably witness yourself and give me some feedback. With that said, let's get focused on Git. And so Git is the thing that I want to discuss the other day we were discussing. I am assuming that you may have seen this video already. I'm just saying that you may have, but don't have to. But it's a very good video to understand concepts. This gentleman, Michael Schorn, is based in, I think, Portland, is a Perl expert. And he talked about Git a few years ago in Australia somewhere. So that's the video that you have, that you should take a look. There's also some write-up here that you can follow along to get some concepts, but I will not be using any of that. I will use just the command line right here. And to supplement that, we have been beginning to look at an empty folder. We added a file there called A, if you recall, that file opens up in an atom editor, like you will see on the right side. This A file contains some content. And you can track changes in this entire folder called test. In that folder, whatever we do, whatever we basically add and commit, we'll be able to track changes in that repository effortlessly as we go along. And so that's the plan to help us understand what is Git, how do we use it, and Git can be a complex subject, so I'll simplify it. It is complex. Even I don't know all of Git. It is quite complex, to say the least. But what our goal is to not comprehensively understand each and every aspect of Git which may not be relevant to us, we will focus on the primary use cases in which the portions that are relevant to us from a day-to-day usage perspective. So that's the idea. Having said, let us begin understanding what Git actually does. So Git helps us in tracking changes. The tracking changes of what? Changes of whatever you do in a file, in any line within a file, multiple lines, portions of a file, all the files themselves, or new folders. Whatever we create inside a given folder, anything below that, all the files, all the folders, any change in the body of any file, they will be tracked. That's the idea. Track meaning you will know exactly who did what, when, why, things of that nature. So we have begun creating this repository with this body of text inside this file in this folder. And that has been put in a Git repository. That's the idea that we began discussing this with. Now, I told you the other day that we were able to delete this file by accident. I'll do it again. And you can revert it. The idea is I'll delete that file here. So say delete. And the file goes away. And then I can say, you know what, I lost the file, but I have it tracked. So I'll say Git status. And you will see that the file got deleted. It tells you that the file is deleted. But we have it in the Git repository, so we can reset our Git repository to bring it back. I think you saw this already. I'll do a hard reset on that. And so it brings back that file. And now we have it. That file shows up. Now, the key thing to understand here is this thing is kept track inside that folder, which is what I would like you to understand, explore, but not mess with it. Don't mess with that folder. It will mess up the repository. So you can see the folder, and most of these files right now are barely containing anything because our folder doesn't contain anything. So all it does is currently tracks this one file with that content. So that's the concept. Now I'll draw some illustrations to help us understand this idea even better. So I'll go back to my whiteboard and help us understand this idea behind Git as to what exactly Git does. So under the hood, you begin with nothing, like flat, like bottom or tabletop. Think of it as a beginning point, like basically empty folder, empty folder. It contains nothing but the beginning point. So anything that you will put inside that folder, we need to track changes. So you put some things here, and you write something there like that. And then you want to let Git know that you have added these things. So what will Git do is put them in a stage. When you add, it puts them on the stage. Puts what? Put these things on the staging area in Git. And then when you say commit, it actually puts a hash of some sorts. It's a globally unique identifier. It puts a GUID number associated with the stage item, and then calls it committed. So the commit action leads to a hash. It will also put some stickers, like this is the head, and this is also the master branch. So it will put some flags to help you identify this in human form, like English, master English word, as opposed to a number, which is a basically global unique identifier. And then you keep on adding these actions, add, commit, add, commit. And that it will begin to build what I call a tree, or actually in mathematical terms, this thing is called a directed acyclic graph. Now don't get scared with these words. They have not much meaning from a simple English standpoint. But the fact that it looks like a relationship diagram in which you will have these nodes, and these nodes will represent whatever you have in mind that you have added and committed. So whatever you add and commit, that creates one of these guys. Each one of these that you will have will have a unique, globally unique identifier, also known as a git hash, and will have some English names to go along. And they will have relationships, like how did you arrive to this point or this commit hash? It will have some arrows to go and tell you that you came in from here. These arrows basically indicate how you traverse from one point to the other. And these points have these flags or labels. So basically it means that you can go from any flag to any flag in any direction that you want, even in reverse direction if you like. And they are all connected to each other from a traversal perspective. So that's the underlying simple idea of a graph that you can read in mathematics. I'm not going too much in math, but more in terms of usage. So the idea behind this DAG that I mentioned, directed acyclic graph, is something that you should read on your own. I don't want to spend time on this because it's not too much relevant to what we plan to do. Having said, let us go play with git ourselves by giving ourselves an exercise, a group exercise. So right now all of us we have on the conference here, we have access to GitHub. So what my plan to do is, I have that test folder that I created, and in there I have a file called A, which contains something. So I will clean that up, make it cleaner and nicer. And then I will move this, or rather I should say, push this to GitHub. Now what is GitHub and how is it different from Git? This was Git in my folder, in that folder where I have files and I'm tracking changes and all that. What I'm doing is pushing all this into GitHub, where I will call, this is going to be a place where I will share it with you, place to share my Git repository. So I want to share my Git repository with you, I will be using this service. So GitHub is a service to place to share Git repositories. Like GitHub in your company, you probably use GitLab, so it's very, very similar. GitLab is open source. And you can see that it behaves exactly the same way, except it is different product. It is also a commercial product, by the way, but it's, I think, open source primarily. There is a commercial variation to it. So in your company, I think you have GitLab and you use it internally. This is very, very similar to what you have publicly available, GitHub, GitLab is also publicly available and open source and a commercial product. So it's a combination of many, many things. So it's very similar to what you have in GitHub. There are also similar products like Bitbucket, Bitbucket is from the company called Atlassian, which is basically a similar thing. It is also a place to share Git repositories. And you can have these companies provide you services to manage Git repositories. Git repositories are basically folders, folders containing things that you want to track. That's the underlying idea. So what I will do now is go to GitHub and let's go there. So here is GitHub. And there you will find that I am on GitHub. And I'm going to go to a place like here, for example, and there I will create a new repository. Now this phrase that they're telling me is actually wrong. I don't agree with that phrase because the repository, I'm not actually creating one. I already created one right here. So that's why I think that phrasing of the word creator repository is actually wrong because I already have this created here. My folder containing Git repository is already created. What are you going to create for me? Nothing. Like this already exists and that one already exists. So what are you creating? You're not. That's my point. But it's a very minute minutia. So just focus on the concept, not this idea whether I'm creating a repository or not. In fact, if I was talking about these things, I would say, you're not actually creating a repository. You are creating a place for me to store my repository. I already have it here. So that's my repository. It is on the master branch. And that is the folder which contains this file and it is in Git control. So that's what I want to push to GitHub. And I want it to create a place for me to store my repository. That's the nuance, but it's tiny. So just take a note of it and move on. So I'm going to create a repository. I'm going to call this what I want to call it, I'll call this alphabet, just a name alphabets, alphabets. Yeah, alphabets. Yeah, that's a name. So now this is going to be a public repository. So anybody and everybody can see it. I want to make it public. And then I create a repository, which actually is going to create a place for me to store my repository as opposed to actually creating a repository. So that said, I'll create now. I created a place. Now what I need to do is push. Push what? Whatever I have here into here. So how do I do that? Here that's the action. I want to push an existing repository, which I already have from the command line. So the concept here is that this Git repository, it knows of nothing about this company, GitHub. It has no idea. It's just a folder. Come on. It doesn't know about GitLab. It doesn't know about Bitbucket. It has no connection, no linkage, no relationship whatsoever. So first thing we'll do here, which is this action, is to establish a remote connection. And so this folder will know that there is such a thing called GitHub and that I have a place to go, which I can go and I can push. So if somebody says push, then I can take this and push it to here using the push action. And that's the plan. This two-step process will finish the push. Now let's go read what these things actually do. The first action, so let me erase my ink. The first action is git remote add action, add a name origin, and the actual location will be this, which is the folder called alphabets in my account, cloudgeniuscompany and github.com. That's the link to this remote location, which is this page. And so that's what I want to add a remote by the name origin, by the short name origin, the long name this. That's what I want to actually do. So what I will do is clear and then copy this like that. And before I execute that, I want to check what is my current set of remote connections. So git remote. What are the remote I have? I have nothing. It has absolutely no idea about anything about GitHub, GitLab, Bitbucket, whatever else. It doesn't know. It's just a folder. So I will now add a remote. So I added one. And now I check, what are your remote connections? So it knows that I have a connection that I can make, and I can make a connection to this location if I want to fetch. So if I want to basically bring it down, I can use the fetch action. If I want to send stuff, I'll do a push action. Right now, this guy doesn't know it has nothing. And whatever I have is here. So I need to push first. I cannot fetch because there is nothing here. So I want to push now. And pushing is simply this action. So we will push. And I'm clearing my ink and copying that over, which is just the push action here. And then push. So it pushes as simply as that. This action, when you will be beginning to play with Git, which is right now, you don't need to worry about the terminal quite right away. You will work on terminal, but not right away. So right now, we have the Git repository with the Git remote connection available to us on the right side. This one was empty. Now it is not empty. How do we see that it is not empty? We just refresh the page, and it will just show up. So clearing now. And I'll say, hey, come on, refresh. And there it is. It shows up. I'll take that link here, by the way, on GitHub. What I'll do is I'll pass that link to you so that you can get to it also. And then you will be able to play with Git right in the browser window with me. So this is the folder that we had. In that folder, we had a file called A. This A. And it contains something. It contains what? Now, this is not empty. That was the text that I had, I still have, in this location. And there is the file, and it says, no, this is not empty. Now this is empty. Now what I want to do is I want to delete that line. So I'll delete and save and close. And back in terminal here, what I want to do is I made a change. So I would like to Git status. And I see the change. I see that the change is that I modified the file A, this file. It got modified. So Git needs to be putting this change, which is, by the way, you can see the change, Git diff. You can see the difference. The difference shows up here. Like this red colored ink shows that it was deleted. And there is no corresponding green colored ink, which means nothing is there anymore. Nothing was added. This red is deleted. And there is no green ink. So there's nothing, basically, in green color. So nothing was added. I just deleted the whole file. It's empty now. The file exists, but it is an empty file. And so that's what you see, the diff showing you the red line. Sorry, I should change the ink. And so the red line shows that it contains a deletion. This needs to be added into Git and committed. If you see the Git log, it shows the first change I made, which is, hey, I added A. That was the log entry that I added. Now having made this change, which is the diff you see, and the Git status you check, it shows you that there is a change, which shows that the change is modified A. I want to say, Git, add your change. So I add the changes called A. And then I Git add A. And then I make another commit. So Git commit, minus M to pass a message. And then I'll say that, hey, team, hello, team. I cleaned up A. And then I finish my message to the team. And I say, commit. So I have committed. And I check my Git status. I see that my branch is one ahead, one commit ahead of the other guy, the origin guy, which is the GitHub location, which is this location. It doesn't know. This guy still contains this text. And I want that to be removed. So I have removed it here, and my Git status shows that I am ahead of the GitHub location. So I say Git log, and I see that my log entry shows two items. First thing, I say, hey, team, I added A. That was on February 1st. And now February 4th, I say, hello, team, I cleaned up A. That's the two things that I see in my log entry. Now GitHub has no idea that I made a change, because these are distributed systems. They have no idea about what is happening here and what is happening here could be completely different. They're unconnected. They just know about that there is a remote link established, but they operate totally disconnected, totally distributed. And that is one of the most beautiful features of Git is that there is absolutely no dependency or deadlock between what you do here versus what you do here. It is disconnected. You can push, you can pull, you can grab changes, mod changes, do all the things, but there is no deadlock. What does that do? The benefit of this is that if you have multiple people, like hundreds of thousands of people working on a common folder across the globe, they can all operate independently, distributed without having to even talk to each other. They can operate on whatever they're doing. They can keep on doing, building new stuff, creating whatever they want in that folder. And they can proceed without a central locking facility. And that leads to a different problem, which we'll talk about. So when there is no deadlock, there will be eventually conflicts and conflicts. You will see conflicts. I will create conflict in our project example that we are going to begin. It's an exercise beginning up. I will actually create conflicts and you will see how do we deal with conflicts. So the idea of no deadlock is actually a very powerful capability of this being distributed. Any other source code control system that you may have used in the past usually has a central repository where you go and you grab and while you have checked out the source code, then other people cannot check in because it's a lock. And so that actually leads to slow down in your development cycle. And so you don't want to use those tools. That's why people have migrated away from centralized version control systems because they lead to a deadlock. This one doesn't have it. By design, it doesn't have it. It also leads to conflicts. But of course, conflicts are a fact of life. You will have them in any situation. So we'll discuss conflicts also. I'll create some for us to discuss and focus on the idea that it is actually lets us operate on our own. So let's go play with it now. How do we want to play with it? So what I want to do is, first of all, clear my illustrations. And this thing is like two things here, one and two that I made. So by the way, there's a git commit hash and another commit hash for two actions, one for February 1st, one for February 4th. I did two commits. And so this is one commit here. And there was one made on February 1st. So those two commits have two git hashes. So these are hashes that are called basically commit hashes, and these are just numbers. They're actually very long numbers. This is just a short portion of that showing up here. And that two entries, two log entries here, but this one doesn't know the second entry of commit that I made. This guy has no idea. So I need to do what? What do I need to do for my changes to go from here to here? What action? I made a change here and I need to send it here. So what is the action expected? Nobody. You have to commit. Well, I already committed. And so see the commit is already right there. So commit has happened. And so what I want to do is send my changes. So the commit is there and it's right here. What I need to do is push. So I will push. So it's a git push. And so it pushes. It already knows where to go and what to do and how to push and all that because of git remote. It knows what my remote buddies are. And the remote buddies are these guys, for fetching their action and pushing their action. So it knows the same place to go push, pull from and fetch and all that. And so that is how you push. Simply saying git push. So it pushes. So when you push, both your changes are pushed over to this location. Now here you go and examine. You will see that this file, by the way, the new comment shows up already. Hello team, I cleaned up A, already shows up. And then you go inside the file. It is empty. Zero lines, zero bytes. That's what I want. And so that's I have. So now let us define the project, the exercise we want to do together. And what I will do is in this file, which is empty right now, I'll close it. I'll create another file here and call it read me. And that's where I will describe the project or the team for all of us to do it together. Our action collectively is to create a project. It's a very simple and actually very silly project. So you'll see how silly it is. But it gets the concept across. That's why I do it. It should not take like more than five minutes for us to finish it off. But it's something to do to understand, to really appreciate the capabilities of git and it will show you what happens. So the project is create a folder containing 26 files. Each that's one portion, each named after a letter of the English alphabet. That's it. That's the full action. So I save it. That's the task, I should say, the task. And the further specification of this task is that we'll get together in a team and decide that there are A through Z, there are 26 characters, and there are how many people on the team right now? We have seven people. So let's divide this. So I already created A. So we have 25 remaining. So we just decide that, you know what, let's assign names. So we have Greg Lopez. You please create B, C, D, E, F, G. Let's go up to that. And then the next one is Dominic. So you please create H, I, J, K, L, maybe M. And then next is Mary. So actually, it should be beginning, so what did I do? M is good, M. Then it begins with M, D. And then we have Rich. I think it's an unequal assignment, but I guess that's okay. It's not a big deal. Vaishak will handle W, X, Y, Z. And I already finished the creation of A. So that's the assignment. I'm just assigning it. And then I will need to push this task over. This task file in the readme file, this task needs to be pushed over to GitHub, right? So if I check my git status, you will see that there is a file called readme.md, but it is not dragged. It doesn't know about what you want to do with it. So untracked files found, your branches up to date and all that with GitHub. And so the two commits that we have, they're all good, but you have a new file apparently. I don't know what to do with it. So tell me, what do you do with it? If you tell me nothing, I will do nothing. So git will ignore it unless you explicitly add it to the stage and commit. So I think I want to add that. So I will take this file and say, you please git add. And so I'll say git add the readme file and then git commit and pass a message to the team saying, I add a readme file for you. And then I git push. And when I push, then GitHub knows about it. And so I pushed and the push should finish. And now I go upload, I mean, just see it on GitHub and I see the task right here. And that's the task. So now let us begin doing the task. And what I would like to do is just illustrate to you how to actually create files in GitHub without even using the command line. I was using command line up until now, but I'll just pick a random example here. So I see the a file created and what you can do is on GitHub. Go to this location, the alphabets file, which I gave you in Slack chat already, go to that location and there the first thing you need to do is create a new file right there. And when you do that, what happens is it will get forked. The whole repository will get forked. Now this is a new phrase. So I need to describe that. This phrase means simply that what you know about fork is, so if you know fork, like in English language fork, the one you use to eat food, that fork, that's the same idea. So now what I will do is go to a notepad and describe this concept of fork. So here we go. So what happens in Git is when you have a commit structure like this and you're creating some things and you're creating these hashes, commit hashes by saying git add, git commit, git add, git commit, like that. So those actions keep going on. And when you have such a structure and you call this a Git repository and you push it to another location, say GitHub, and then this whole thing is also here also. And so when another person comes in from outside and looks at GitHub and you want to create a new file into this folder, create a new file, a new item, anything changes, any change and you want to make a change in this folder, well, you don't have permission. You don't have permission yet. I haven't given any permissions. All I did, I made this repository public. And so I did not give anybody a permission to make a modification, but I'm still asking you to create a new file in my folder without giving you permissions. So when that happens, when such a thing happens, which is very common, people don't want to give permissions to people on the internet, otherwise people will create a mess here. And so you don't want to give public writing permissions because that's a bad idea. So you don't permit, but you still ask people to make changes. So I will invite changes here. So please change, please change this. That's what I'm really asking you to change the folder. So when you say, okay, create a new file, that's a change. So when you don't have permissions, what happens is that the whole thing that you have in GitHub becomes a fork. So the whole exact thing like you have here will be created in your account. It will look exactly like what I have here and also have here. You will also have the same thing here and it will be called a fork action. It happens at the background. You basically create two replicas. So one is your, this is my copy, this is your copy in your account and it is actually called a fork. So what it actually means, why I call it a fork. The reason it is called a fork is because if I am going in this direction, you have the ability to come in and follow along with me in that direction and maybe make a contribution change. And then we'll all go together or you have the ability to go in a different direction and not make a contribution and keep going in that direction because it is all open source, you know, open to the world, GitHub, open source, Git repositories, you fork and you fork and you go away and we go in this direction and you go that direction. Now this is a fork. That's why it's called a fork. It doesn't mean that you have to go away. You can always come back and maybe make your changes and you then send them over. Now this send changes idea, send changes. This action basically is a very simple concept. Let's see the action in a clearer picture that I would like to go to a different sheet and draw there. So then in another screen, the idea is that you, I begin here, I have a folder like this and with an item called A and then another item that I add another item. So I have A and I have read me and then I push all this to GitHub. So that's how it looks like right now. And before that, there was another thing called A and this is edited and this was A with junk. It's cleaned up and then I push. So there is A and then read me and that's what you fork. You have exactly the same thing, A read me and you want to now create a file. So you create B, you create C or you create something else. And then you want to ask me to take the changes. So you send me the changes. But you don't have write permission. You don't have it. You had the ability to fork it, fork away. So you went away in a different direction. You made a change A, B and C and you added some things. Now you want to send them over to me, but you cannot write to my repository here. So this is my repository. You cannot write to my folder because you don't have permission. So at the best you can, what you can do is, is when you send a request, you actually ask. Please you send a request like this request, please take my change. My changes are B and C. So you request me, hey Nilesh, would you please take my change? And this idea is called a pull request. You will say Nilesh, here is a pull request, please take my change. Then you and I will review, is that change a good change? And if it is, I will accept the change. As soon as I accept the change, these files become a part of my file structure in a different git commit. So that's the flow of operations, a flow of actions and you can keep on doing the same thing. I add B and pull request, C pull request, do the whole work and pull request. And sometimes you make a mistake, deliberately please make a mistake and send a pull request. And sometimes you do it right and send a pull request. And we'll all together at the end, sit together in a team session and find out which pull requests should be accepted and which should not be accepted. So that's the concept. You can see in our alphabets folder that I have no pull requests yet, which means you need to go and create a file pretty much like that and add this file by the name B. And then in the file B, you basically say create B and create a file. You commit the file and then now I have B. So here I have A and B and I created B just now. So exactly like this, I would like you to please create something like, like fill it up A through Z, simple files, simple file, open a file, add it, commit it and keep adding in your folder structure. And once you are there, you should be able to generate a pull request and send it to me like this pull request idea. That's where you will be able to send a pull request by creating a new pull request and send. No, I don't see it because I am me. I need to be somebody else to be able to show you. So what I can do is potentially log into a different browser and see the same thing. And so I'm going to do a different browser right now. I just sent you a pull request. Thank you, sir. And that is Z and that came in from Vaishak. You can actually see it right here. So what Vaishak did is he clicked on the alphabets link. He forked. So there are two fork right now, which is Vandana and Vaishak both have forked it. And Vaishak went ahead. And then in his fork, which is a fork of my repository, as you can see this, it is forked from my location. And what Vaishak has done is that he has in that alphabet repository, he has created a pull request for me and he sent that back to me about 11 minutes ago. So there is something he added, I think Z. So you can see that pull request showing up in my side as there. And so here is another file created W and Z created by Vaishak. And so those two pull requests are available here for me to review with the team. And so what I'm doing is reviewing with all of you right now, excuse me. So the first one, so let's go see the Z item here. And that item Z is a file, which is an empty file. You can see the file itself and it contains nothing, which is the idea that we create empty files with appropriate lettering, the, excuse me, so the change showed up. I can see that it is ready for me to review. So I could make a comment or I can just approve. And since I am the owner of this original repository, I can actually accept the pull request. So what I'll do is I'll go look at the Z pull request and then simply merge it. So I'll say pull merge the pull request. So I click on the merge button and say, confirm the merge, because actually the file that I reviewed Z is done correctly. So I would like to merge it. So I merged it. And then one of the most important things I need to do is to remember to thank the contributor. So I thank him and then make a comment. And this is the most important thing in Git is to just thank people because Git is actually about collaboration. It is not something about pushing and pulling and merging and diffing and oh my God, there are so many commands you can not, you know, it's hard for me to remember all these things. So I don't, but Git is not about all these commands Git is about collaboration. So you need to thank people who are developing stuff for you and you're making a contribution to your repository. You should absolutely make sure that they continue to continue to work with you. That's the core idea. It's collaborative stuff. It is human stuff. It is not a technical thing. Git may sound technical, it is actually about people collaborating, creating and merging good things, rejecting bad things, reducing conflicts and getting things done. It is about that. It is not about pushing, pulling, merging, forking, God knows what. And so it is about people. Having said, let's see other pull requests. So I have closed the Z pull request, so the Z one is closed. I can see that the other pull requests that I have here are open. Let's go see, look at the X pull request and it is telling me that the X file changed is done correctly. It is supposed to be labeled X. So I like the change, I'm going to merge it. And so we'll say this X pull request X, I'll merge it, confirm the merge and again, thank and comment. And another pull request like that, you should be able to create a pull request and finish off the project. The project is trivial, but the concept is, let's go check this file before I confirm. I will check the content of the files are clear. And I will like to take this pull request from Vyshark. And so pull request W needs to be also merged. So I confirm the merge and again, thank Vyshark. So that's the underlying idea behind Git. Now the action of creating these files A through Z is actually trivial. I mean, it is so trivial that it is a child's project right now. It's actually ridiculously easy. Having said, our goal is to not actually complete this section. We don't have to finish off A through Z. That's not the idea. The idea for us to discuss this is to understand how Git actually works out in real life. What we are really looking at is, by the way, if you are still creating a pull request, just let me know. If you're not, that's okay. You don't have to do it. The goal is- This is Rich. This is Rich Erwin. I'm going to declare stupidity. So you want us to on our virtual machine create a README file or because I mean, it's easy enough to go to the site, but then it wants to compare whatever letter file you create against the master. So I'm assuming we need to create something before we go and create our pull requests. No, you do not need to do anything at all with the terminal because that terminal thing was a one-time action, which I already did for us, for the team. Okay, but when I attempt to create, well, U or V, what happens is that I get told that there's no difference between what I want to create and master. So I'm assuming I have to create something at the command line level beforehand. No, you don't need to, but I would like to see what you have. So if I would like you to show your desktop- If I can get things to work, I will do so. Everything is kind of gummed up because I've been busy since 5 a.m. dealing with people who can't deal with snow. Okay. So go ahead. You'll have to go ahead and keep doing what you're doing because it's going to take me a while to get things to display. So go ahead and do your stuff while I shut this down so I have actual memory to display things. I understand. I'll wait for you when you're ready, just tell me. So right now, there is no need to use terminal. And our goal is to just use the browser. And using the browser, we will be able to create a new file using that button there here, which will create a fork. And right in the browser, you will add a file like that. And then you make a commit. And then you send a pull request, like we have another one coming in. So we'll just see that. And then once the pull request comes in, like this one, for example, here is Vandana created a V, the file called V. The file called V shows up. And I see it. And I like the change, so I will incorporate that pull request right into my main branch and I confirm and then I thank Vandana. And then I comment. And so she knows that I took the change and that her change is now in part of my repository so that these files show up inside my main folder. With that done, what I would like to do now is to actually bring all these changes down to my machine. If you look at my machine, I have nothing. I have just A and read me. And so I want to bring all these contributions that we have from people in the team down to my machine. And they are available to me in my GitHub location here, but they are not here. There are lots of files here, but they're not here. They're here. So what I would like to do is from here, pull. And then I have it. You will see it. So I will now get pull. And here it comes. So you can see the files now. And now they match up exactly item by item. What I have here matches what I have here. So that's the idea behind synchronization. Now let us create a conflict. The way to create a conflict is for two people to create the same file at the same time with different content. And so I can do that by deliberately creating something wrong. So I will do that right now, wrong as in not according to the specification. The specification is create an empty file with the English letter and all that. And so what I would like to do now is to illustrate a conflict. And you will see this in, I'll exploit a tiny little difference in our example, which very few people will notice, but I'll make it very clear to everybody. So you'll understand how conflicts can occur. And here it comes. So in my folder, you will see that I have these files. And in there, I will now create a conflict. For example, I'll create a file called V. And this is just to cause confusion. You will see how it causes confusion. And what do you think will happen when I create this file called V, will it let me create or not? If I say V, do you think it will let me create for long time windows people? They'll say, no, it will not let you create because the file V exists right there. And so I'm going to create a file. And this is just so you know, capital. This is lowercase. What do you think will happen when I create a file lowercase V as in vector, as opposed to capital V. It will create. That is, by the way, not a conflict. It's just confusion. So just so you know, this is not a scenario of conflict because in Unix, it is okay to have a file named letter V and a big capital V. Both are okay. At the same time, in the same folder, it's a valid scenario. And so it will allow that. And now I will have two files. The conflict occurs when we will have a file containing different content by two people. That's where conflicts occur. So I will clear my annotations and draw. So now you have another file called lowercase vector. Where is the touch, I did not type it, touch, sorry, create the file touch V. And now I see that I have, hello, I wanted to create a file called V. What happened? The change in, is it a Macintosh thing or what? It should create a lowercase letter V. There is a file called V, hold on. But I think we are running into some kind of a esoteric scenario where lowercase V versus uppercase V is different in Unix Linux, but not in Mac. So this is a Mac. So I'm not talking about that anymore right now. Let's actually create a conflict. My conflict creation, what I want to do is, is to create a file that somebody else wants to. So for example, let's take a look at what was Vandana supposed to be doing. So Vandana has, I didn't even list her name here apparently, is that right? Apparently so. I just ignored her. I'm sorry Vandana. In this list, I don't have you for some reason I don't know why. So let's say, so Vandana was supposed to create a letter V, which she did. And what I would like to do now is to ask Vandana to create one more file, but just wait for me. I'll actually create a file that you were supposed to make. So let's say I'll ask Vandana to create another file by the name M. That's what I would like to ask you. But before that, I will actually create another M. So Nilesh will also create a file called M. So that's my plan. So I'll create, I'll create a file called M and then I have it here, sorry. I have it here now. There it is. Now I'll get add and then I get status. And then I say new file M, then I get commit, rather I should actually make some edits in the file itself. So here is the file called M there and I'll type this is created by Nilesh and save, close. And now I'll say get add, get commit, Nilesh added M but shouldn't have, and then get push. And then it's so good to go to GitHub and see what's going on. So here you will see I have a file called M showing up, there is the file. So Nilesh added M but should not have. Now having seen this file, which contains something, this is created by Nilesh. What I would like you to do Vandana is to create another file called M and try to push. That will create a conflict. A conflict is basically something that two people disagree on. So I say this file contains something, which I did, and you will have something else. So that's the conflict. So now I'd like you to push or I'd like you to create a pull request and we'll resolve the conflict by doing something about it, like it has to be done manually. So that's the conflict resolution scenario I'm trying to build. I'm waiting for somebody like Vandana to create a pull request. A pull request with this specific name, which you can see here, this name, lowercase M. So create a pull request with that file containing something else different from what I have. What I have is my M file contains, this is created by Nilesh. That's the content I have. So please create something else that is different from that language. It's easy. Just create it and send a pull request and you will see the conflict pop up right here in this window. So waiting for that. It should pop up any moment. I guess she's busy doing it, right Vandana? I hope you, I hope she heard me. Yeah, sorry. Okay, good. Awesome. So please go ahead and send that so we can illustrate a conflict scenario and we'll just understand how to handle conflict. It's a real life conflict situation that we are trying to simulate. It's giving me something like compare changes. You need to just create a new file and send. So send a pull request. It's not here yet. So in the meanwhile, what I'll do is I'll create another login and I'll create a pull request here also so that you will just see it because I don't see the pull request quite yet. So let's see if I can create the same exact folder. I'll go to the folder here and then create another same change into that location. Let's see if I have a pull request yet. No, I don't have it yet for some reason. So I'll create that pull request myself being a different persona. So this is not me. This browser is not me. It's a different login. So I'll see that file, alphabets folder, I create a new file and there I have to have a fork. So I create a file called M and then this, oops, cancel, skip, cancel. And here I'll say this is not Nilesh, not Nilesh and see what happens. So when I try to propose a new file, it says conflict shows up right there. A file with that name already exists. So that's the scenario you saw that file already exists in that folder so that it is not even letting you create a file with that name. So I have to cancel this to illustrate a conflicting scenario, but you will see that if I want to actually simulate the conflict with just a web browser, this method that I initially proposed you that you please open a file, create a new file and send, that scenario is not working because GitHub doesn't even let you create a file if it exists. So to now create a conflict scenario, what I need to ask you to do slightly different, which I will do that by the way, is to just go to the M file and here I will edit the file right there, the edit button. And there I'll say, you know what, Nilesh, you are wrong. This should be empty. And then you send the change to propose a file change that's going to create a pull request and then I send it over. The pull request is now popping up here. Now it popped up. Now this pull request came in and I see that it has no conflict because the file that came in actually erased the content and overwrote the content that I have. So if I want to see the change, they are here. And so the red line shows deletion, the green line shows addition. I can either accept this or further modify by reviewing the changes that, you know what, these changes are actually not right because I want even that portion to be empty. So I can basically say that, you know what, I delete this pull request or I don't agree with this pull request or I reject the pull request. And I can say that, you know what, this is not a pull request I would like to accept. So I say, thank you, but thanks, but the file needs to be empty. And I comment and I don't accept the pull request. That's one way to handle resolution. There are other ways to handle resolution is to basically ask this other person to send a file that is empty. So then they can actually do it that way. So we'll go to the other person's account and say, you please go to the M file, edit it and make it empty. Then send the file as a change. And so proposing a change, the change comes in. And now you create a pull request and send and a pull request pops up in my browser here. And I see that in, there are two pull requests. I'll get the second one. And this one looks like, okay, because the file is actually clean. It is emptied out. The red portion is gone. The green portion is empty. So I like the change. I like to take that change and I will merge the pull request. And then my file called M is empty. So now having seen this, the scenario that we want to play is to just get pull again. And now my file M is empty. That's what I wanted. So people collaborated with creating stuff in our project to get to a result. Now we don't have to actually finish up the entire collection of files from A through Z because it is kind of pointless and boring at the same time. So we are not doing this exercise actually, but just to illustrate the concept of Git. Having seen this, what I would like to now do is switch over to the idea of using a virtual machine and getting to an exercise we can actually use to use the platform as a service called Heroku. So that's the exercise we are beginning. We are going straight to Heroku and there we're logging in. You have an account already, I'm assuming. And I'm going to open my virtual machine and there I will start the exercise. This Heroku thing expects you to have a login. So you need to have that login there. I'm going to log in here. And then once I log in, I should be able to use the Heroku tool. By the way, this exercise I'm going to do right now, many of you have Macintoshes. Don't do it in Macintosh. It doesn't need to be. It is not a good idea to just run this exercise in Macintosh because I don't want to mess up your laptops or desktops. So don't mess with it. Just leave them alone. You can do these exercises right in the workstation, which is a separate machine. It is meant or designed for us to create mess. So you can handle mess in the virtual workstation. Don't mess up your real computer. Having said, let's go to our cloud genius site where these instructions that I want to do is actually written down. So that's what I'm opening up. Here you can probably see that I can search for the Heroku exercise. And that popped up here, I think, here. That should take me to the Heroku beginning step. So we'll go to the hands-on with platform as a service introduction step. That's what I want to begin with. And so this is the beginning point for the exercise. So I'd like to give you the link in Slack chat. So you are there with me. And we'll begin with that. The actual exercise is very, very simple. But again, the goal here is to understand how do we use platform as a service. And then we conclude our three types of service offerings, like infrastructure service, platform services, and software services. Then we'll switch on to using concepts of DevOps using Chef, Ansible, Docker, and things of that nature. We'll go deeper in that direction. But right now, our idea is to use the workstation, which is misbehaving right now for me for some reason. Because I don't see my start button. So I need to reboot my workstation, it seems. Look like so. So I'm rebooting my machine. Here I go, CPI shutdown, reset, reset, reset. Reset the workstation. And once the workstation starts up, we will begin with creating some of the basic connections between our workstation and the Heroku software. The Heroku online platform as a service solution, which requires us to have a Heroku account and a login. And then we need to install a tool belt. The tool belt is a tool available from Heroku here, tool belt Heroku. That will get us to that point, which is here. And that tool belt is what is the first step that we need to have in our workstation, where we need to use this. Why is my start button missing? It's really strange. No. So when this happens to a workstation, what you should be able to do very, very effortlessly is something that I will now demonstrate because this issue is happening to me. It might happen to you also. And when it does, this is what you should do is when you go to machine and go to go to machine settings, then you will find that you might have an image captured. If you don't have an image captured, it's a good idea to capture an image right away. So that when you run into an issue later on, that you actually have a method to restart the workstation from a previously known good state. Right now, my machine seems to not give me anything that I want, but just showing me this screen, the wallpaper, and not giving me any other actions. I don't know why this is probably because of a reset updated workstation or something else. But I want to go to my initial state. So what I would like to do is just restore my position to that point in time that I was at the beginning. So I will basically shut down my machine and restore my snapshot to the initial point in time when I know it was good. And it will take me to the point when the machine was functioning okay the last time and assuming that this was about 14 days ago. And so you will see that this snapshot was created about 14 days ago. That means the machine should resume from that point in time in history and let me continue forward. So this initial step that I want to go restore is what it did and so now I will restart the machine from that point in time in history, which is 14 days ago and proceed forward. So there is a break request, I think it's a perfectly fine time to take a break. I understand you need a break. And so what I will do is actually start the break right now. So we are beginning to use the Heroku exercise. We'll begin that direction. But I think since there's a break request, what I would like to do is just take a break. So here we go. So we are going to take a break right now. So timer for seven minutes, I think the request of five, I'll just make the seven minute break and here it goes. So the break has started. I'm here. I will be here and you can see the break timer on my desktop and it will resume from the break when it finishes and that's the signal to let you know that we are on a break right now. So yes, we are on break, but we can talk to anything you like. When I create a Heroku account, what language should I select? It doesn't matter, but we are using Ruby right now. So it doesn't really matter because it lets you create any language of your choice as long as it's supported. So we'll just use Ruby for this example and let's just say Ruby, but it doesn't matter. You can give any answer you like. By the way, I'll just go wash my hands and be back in just a second. I'll be back in just a second. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. All right. I'm back, by the way. We'll start as soon as the timer finishes. Okay. So now just checking if you guys are back, the timer has finished. And I'm going to check if you are here. One, two, three, four, five. So I'm assuming that you guys are back. Just give me some feedback so we can proceed. So what I want to do now is to make sure that I connect my computer here, this one, the workstation with Heroku. The way to establish that connection is using your login and alongside that you need to have this tool belt connected. And that tool belt is the tool that Heroku provides so that your command line is able to interface with the platform as a service. So now in this exercise, what we plan to do actually is to build an application. It's very simple, but we have to build an application, build an app, just like any developer would. It will be a build a simple application for our example understanding. And then we will, you know, put that application in a Git repository. And then we'll establish a remote connection with this guy. And then we'll say Git push. It goes here. And then that's it. We are done. The application will be visible to you here. That's the plan. That's the plan. Now to build an application, we need to use some language. So my plan to use a language of choice today is Ruby. Git repository is simple to create. Just say git init. So it creates a repository. You git commit and git add and git commit. So it commits. Once that commit is created, we have to establish a remote with Heroku as opposed to GitHub. This remote connection will be established with Heroku so that when we push, it goes to Heroku. And then Heroku takes over and runs our app, the app that we will build right now. We'll build it here on the workstations. We'll run it here locally to test it out. And when it works, we'll push. We don't have to worry about anything here at all whatsoever because that is not the point. The point is to use a ready-made platform and all we do is git push. And then we expect that the application that we created here in our workstation will run in the cloud, the platform as a service cloud. That's the idea. This is actually too much of a demand. When you're assuming that they will know how you have crafted your application and what are the dependencies are and they will be able to just take your app with a git push and run it for you, it is too much of an ask to think about it that way because you're expecting them to know how you wrote the app. So we had to come to a common middle ground and we had to follow a very disciplined approach to writing applications. Otherwise, things will not work. So the best way to approach this kind of a scenario in any example, it doesn't apply just to platform as a service, but any example, these things that I'm going to say now will apply. And those things are, let's go to a white sheet here. So when you're working with a team that you're very likely to be in most cases, you will be working with a team of people. The idea is to have everybody on the same page. That's a simple idea. But you need to make sure that everybody understands everybody else. So this is me, this is you, and there are a bunch of other people. You need to have the application that we will be collectively creating. You need that application to run here on my laptop, here on your laptop, here on your laptop. And this is our local development machines. We need to run it just like that. It should also run in our staging area, in our production area, and any side testing that we will do. So any locations that we will have, separate locations, separate staging area, we will expect this application to just run, just run it here, just like that. And wherever you throw it, it should run. So that's the discipline that we need to be able to put in our team here. So these team members, multiple people creating, collaborating an application, building an application, will want to make that application run comfortably, effortlessly in any location that you want to send the application on. So for that to happen, we need to make sure that everybody is using the same language, the same version, the same set of dependencies, same database, same everything, basically identical structure in my laptop, in your laptop, in everybody, in the staging area, in the production area. It needs to be identical. It needs to be understood already that, you know what, this is how we'll operate, and this is how it will actually work out. So make sure that at the very beginning, you design your application from the very beginning so that it works with a disciplined, structured approach. And so this detail needs to be written down, written down somewhere. And that's the idea that I will focus on next. So we need to write these things down in a file. The file, let's call it a file for now. You know, the file needs to write down dependencies that I will be using Ruby version 2.3.1. I will use this package and use that package and this, this, this, and that. I'll write all these things down. That thing is called my requirements, my dependencies. So in various languages, like in Python language, this thing called requirements.txt is a file that you will see in most Python projects. If you're writing a code in, you know, writing your application in Python, you will have a file called requirements.txt, which lists out the Python version and other packages that you need. They will not be gems. They'll be Python packages. But you need to have such a structure required written down in a file. Similarly, if you're using something like JavaScript to write an app, you need to have a file like that, which is called package.json. That file basically lists out all the files, all the dependencies needed in the JavaScript washer and this and that, everything that is written down, just like that. So take another language, Ruby. You will have a file called gem file, which will basically write down those things that I just mentioned. So that's the requirement. You need to have these pieces of puzzle together so that we can actually operate collectively. Having said, let's first begin understanding what's the beginning point, which is somewhere here. So we need to grab that tool belt and make sure that we are connected our machine here with the Heroku platform. So we'll paste the Heroku tool belt link, which should be... Let's check what the notices are here. So I just want to make sure that we are... The tool belt is open source. I hope it is gone. Heroku CLI, okay. Apparently, there are some changes happening in... I see some broken links on Heroku. You just saw me do that. I click on the tool belt package and it goes to CLI, download and install for Linux and other installation methods. And so here is the link. So I think there's a slight change in between what I had and versus... Yeah, I think this method should work in our Linux. So let's go check that with what I have. So in my notepad, I have this link and in my website, I have the same link, slightly different link. Well, the website link should also be identical. They should be redirecting to each other. So I think let's stick to the website instructions. This one should actually do it. Let's go try it out. There are some changes apparently. So we'll go see which one works. We'll go run this instruction already provided and we'll just run it. That should take us with a tool belt ready setup. And so it is asking for a password. The password is CloudGenius. And we provide the password and this should install Heroku tool belt. When the tool belt is ready, it should... Yeah, I think it is finishing it up. The tool belt is installing properly. And once that finishes the action of install, we should be able to log in using the command line. So that's the next action. Next action is Heroku auth login, which is basically using the login password you may have from your Heroku login. Use that same detail to log in onto the command line. That's the idea. So we are updating Heroku right now. The tool belt is getting installed. Once that installation finishes, we'll use the command called Heroku auth login like this to log on to the command line like this. Heroku auth login. It'll ask me for a Heroku login password in a browser. So it'll open a browser window. So we'll say enter. So it opens up a browser in Firefox in the virtual workstation. And there I will go to... It'll take me to Heroku and that's where I will log in to Heroku CLI. I will need to provide my login password in the web browser. And that's what I will be doing right now. So we'll say, what is my password for Heroku? And that password is this. So I have the password now. I'll just type it. And my email and my password should let me in. So I log in. And I logged in. So now it tells me that you can close this page and return to the command line. It should now be logged in. We'll close the page and see that we are logged in as me. Awesome. Login succeeded. So now our command line here is connected to the Heroku platform as a service here. And so what I want to now do is, first of all, add a key pair, which we have here. So do I have a key pair here in this SSH folder? Apparently, no. So I need to create one. If I don't have one already, it will create it for me. So it's an easy game here with Heroku. If you don't find a key in my.ssh folder, which apparently I don't have, because I may have removed it, but I don't have any keys. So that's OK. You probably have a key. So I'll try to simulate the experience you have, which is you have already a key pair. So I'll create a key pair right now. So ssh keygen. So I'm going to create a similar scenario just like you have by having a key pair. So now I have a key pair. And that key pair shows up here. And I'm going to use that key pair public key to go to Heroku. In most cases, you may have seen me that I will cat that public key and copy and paste into Heroku. That is not necessary. Heroku makes it simple. All we need to do is run this command. And they will grab our key pair and send it to Heroku like that. So there we go. We found a public key called id rsa.pub. Do you want to send it to Heroku? I'll say, yeah, let's send it. It's now established. That's it. Now the connection is established. Now we can proceed forward. Now the next steps in this sequence essentially are about creating an application, about understanding the concepts of running an application consistently across any team members' computers. So anybody's laptop, desktop, in your staging environment, in your production environment, whatever environment you have, including the Heroku environment, we'll all follow along a disciplined approach to managing our dependencies. In an example, like Python uses requirements, JavaScript uses package JSON, Ruby uses gem file. We need to have such a file called gem file. We'll actually use this gem file structure and create our own application. It will be a very simple application we'll create, and we'll ask git push to Heroku, and you will see that the app goes live on Heroku website on a dedicated portion of Heroku website. So it will be looking like a canonical name record for ourselves, for our application that Heroku will generate for us, and we'll be able to use it. So we want to create a Rails application. So we use Rails as an underlying ready-made tool to create a bunch of things for us, an application for us. And so what we intend to do is not write the entire application ourselves from scratch, but instead use some ready-made work. So what we intend to do is use this guy's work. This guy is David. He created a package called Ruby on Rails. So this gentleman created Ruby on Rails. And let's go briefly understand what this Ruby on Rails thing is. So the idea here is you have Ruby language, and you put Ruby on Rails, on guided Rails, if you will, guided Rails. And so what will that do? It will make your life simple if you follow the guided Rails approach. If you follow the Rails ways of doing things, you will be able to create an application very, very quickly, because this gentleman who created this product will do the work for us. We don't have to do it ourselves. If you follow the disciplined way that they follow, then you follow the guided Rails way. By the way, there is a book called Rails Way that you should read if you're into this business of developing applications. I don't think you are application developers. That's why I'm making it really simple for us to create an application using ready-made tooling. We want to use the Ruby language. We want to use this tool to create an application. And all we really want to do is to see how platform as a service works. But for that, we need to have an application. We don't have one. You create one. Use a ready-made solution to generate applications, and then use that application to run it here, on our laptop here, and then push to Heroku to make it run there. That's the plan. To get to that, we need to use a ready-made tool like this to help us build an application that we can actually push. That's what we're trying. That's what we're going here. But we need to go through this route to get to a point where we will have the application ready for us. That's what we are really doing right now. This exercise can be a little bit involved if you're not into development, which I suspect that you are not. If you're not interested in this exercise as such, in terms of spending too much time on this idea, I can skip it if you like. But you need to tell me. Because if you're not into application development and you're not interested in this game, we don't need to do this exercise. We can just skip ahead. We have way too much content ahead of us to cover. That's why I'm asking this question to you. I don't know whether you actually are developers or not. If you are developers, please tell me that you already know this. Or if you're not interested in development or application development as such, please tell me to skip this. Because I will skip. And I will move forward with other ideas like using Chef, using Ansible, using Docker. I am rich and I am not a developer. Okay, got to know that. Please tell me that you're also not interested in writing new applications. If that's the case, I don't want to waste your time. Most of what I will be doing is determining the efficacy of whatever stuff is using Cloud. I see, I see, I see, I see. So there is a comment from Dominic saying, I'm a developer very interested in writing new applications. Okay, there is a conflicting scenario here. Are you a Ruby developer, Dominic? No, let's not skip. Okay, Vandana is saying not skip. Got it. Vandana says do not skip. Dominic says no, he's not a Ruby developer, but he is a developer. Okay, got to know. So I will follow along like we're doing. So what I will do is I get the idea that some of you are interested. So I'll keep on track. Most other tools though. Good to know, good to know. So yes, we are not skipping. Do not skip. Got the point. So I will now describe this idea in a manner so that we'll make it easy for us to understand what our ultimate goal with this exercise is. So we have to have an app. We need to put it in Git and we need to push it to Heroku and Heroku will run it for us because they have a platform as a service. So we just push and it runs here and we'll see it live and we'll be happy about it. To have this app, we need to use a ready-made solution. We plan to use Ruby as a language and to make Ruby applications quickly and easily, this is the solution. This is one of the several solutions. So we'll use this Ruby on Rails thing, Ruby on Rails. It is basically putting Ruby on a guided rail so that it gets us a very disciplined approach to creating applications very, very quickly. That's just Ruby on Rails. There are a variety of frameworks like this. So this is a framework. So in Python language, you will have frameworks like... Let me just show you. Annotations are erased and now we'll go to... So Python has a framework called Django. Django, not unchanged, unchanged but just Django. So it's called Django project. So that project, this project is a Python framework. It also makes it easy to write Python applications. There is also another framework called Flask. And this is a Python framework. Similarly, Ruby has Ruby on Rails. This is a ready-made package that helps you write Ruby programming language applications. That's what we'll be using right now. There's another one called Sinatra. Sinatra. And that's another Ruby framework to create Ruby language packages available here in the code. And so you can see it on GitHub. And there are a bunch of such open source products available out there. Sinatra is open. And Sinatra is open. And like that in every language you will see, like here, for example, Next.js is a framework to create React-based applications. And whatever you see here is actually based on that framework. So this site that you see, that you use, is actually a constructed site. It's a static site generated by using Next.js. So that's another framework. And JavaScript has probably a million frameworks. JavaScript frame, it's not a million, but maybe hundreds of thousands. I don't know how many. So here is a bunch of frameworks on JavaScript. It's a long list. You can go through that. It's a fairly long list. You can see which frameworks are better. But JavaScript is a nightmare in terms of just too many things available. That's the problem. Just too many choices. We saw about Rails scenario, Flask example, Django example. And we want to just stick to one, not too many. Just one language, one framework, get to an app, get to make it push to Heroku to see how it works out to understand the platform as a scenario concept. That's what we are really trying to go this direction, is to see this flow. We need to have this app. So we are using a framework to build an app, so that we move in this direction. That's the game plan. Having said, we have established our terminal and made a connection between this command line to the Heroku website here. Having said, now let us understand what this Ruby on Rails is. It was created by the gentleman called DHH, who is also a founder of a company called... What's the name of the company these days? 37signals. I think that's the name. They have a new name for them. It's called Basecamp. So that's the company here, basecamp.com. And this is the site, this is the product. It's a commercial company that uses Ruby on Rails under the hood. And they have open sourced Ruby on Rails several years ago, I think. And they have created what is called a package, gem package. Anything Ruby put together in form of a package is called a gem. And these are available on RubyGems website. You have seen it before. I think I mentioned RubyGems. So Rails was used to create this software. And Rails was developed by the gentleman I mentioned. And this guy, and he has open sourced the entire package. You can see it here. You can also go to RubyGems.org website and see that this thing called Rails is available. And it has how many downloads? 159 million downloads. That's a solid number. I mean, so solid that you will know that this site called github.com uses Rails. This thing is built using Rails. Twitter, when it was first created, was built using Rails. It is an extremely popular and extremely easy to use application package called Rails. And that's what we'll be using. We'll be using some version of Rails that we have. So that is what I plan to do in our exercise here by creating a new Rails app. So we're going to create one. So we need to have Ruby and RubyGems. So we have that Ruby thing already installed here on the command line here. So if you say Ruby version, it should already show you the version installed. We have Ruby. And since we have Ruby, we need to now install RubyGems. Sorry, we need to install Ruby on Rails. So we'll go follow that, get the Rails gem installed like this. So we'll install Rails gem. That's what we are going through right now. It is installing the Rails gem. And it finished. There are eight gems that came along, total eight gems. So a bunch of other gems. Action view, action pack, this and that, and then Rails. A bunch of things came along because they were dependencies of the Rails gem. So now we have that gem ready. We should be able to move forward with using the gem. Now we have a special tool, open source tool installed in our workstation to handle multiple softwares and multiple versions of Ruby. And that makes it easy for us to play around with a variety of scenarios. So that requires us to rehash our gems so that our tool knows about the new gem you just installed. So we'll say rbenv rehash. So it just goes and reads all the gems. So now that's a simple step that we just finished. Rehash. Then what I have noticed in the past is that this particular exercise, many people do it multiple times, over and over and over again. And therefore, they will end up with a folder called myapp, which I don't have here. You can see that I don't have a folder called myapp, but if you do this exercise over and over and over again, you will have that folder. And the second time you will do it, you will get stuck. Therefore, I have this instruction for you to delete the folder called myapp, which I don't have, but I'm going to delete it anyway just to show. This is what you need to do. Let it get rid of the existing prior work that you may have done halfway through. And you want to begin from scratch? You delete the old folder like that. If you want me to edit or adjust the font size of my terminal or the font size of my browser, please tell me. I can adjust that if you need me to so you can see it properly. Now, having said, I will install a bunch of things. Now, why do I need to install a professional high-end database on my workstation? Why exactly am I doing that? Can anybody guess why am I installing a high-end database like this on the laptop? What's the point? Why can't I get without it? Why can't I use a simple database like SQLite? Why do I need to have this heavy hitter? This is like a professional grade, probably the best database you can find on the planet. Postgres is 40 years old. It is stable. It is better than any other database known to mankind. Maybe I'm biased, but it is open source. It is better than your Microsoft, better than your Oracle, better than you bring it whatever you want. That's the database that I'm talking about. Why am I installing it here? Do you know why? Can you guess why? Why do I need that here? The answer is simple. I mentioned to you that I need to get everybody on the same page, every team member on the same page, every solution that I will be using in our example, like all the people in my team here, here, here, everybody, and all the platforms I'll be using, staging area, production area, testing area. Everybody needs to be consistently running the exact same set of things, the same language, same version, same dependency, same database, same this, same that. And I know Heroku runs Postgres. So I need to run Postgres right here on my laptop so that there are no differences in between how Heroku runs and how I run. And so there is no confusion with anybody else as to how things will run when it goes to the actual deployment or actual cloud in platform as a service in Heroku. I need to run exactly how they run and they need to know what I'm doing. And we need to be on the same page. That's why we are installing the heavy header database, which actually is a light one. It doesn't take too much time. And this action should do it. By the way, it is already installed. So this will not take much time. So I'll just go and install this action, should take care of it. So let me just see if I can type my password and proceed forward with the installation. It should already be installed. And there it is. It's already installed and running. Having said, we need to have a Postgres role and a database created inside Postgres. And that, I just used a confusing word, so I need to clarify that. What I just said is to create a database. And then I also, just a few minutes ago, I said I need to install a database. And that might throw people off. So I need to create a database and install a database. So what's the difference here? So this and this, people generally use the same word for it. The word for this is actually database server. And the word for this is database in a database server. So when you have a database server, it can store many databases, one, two, three, like that, many. So what I'm going to do right now is to create a database to store in the database server, which is this. I already installed it. I have the database server installed, which is this step. Now what I am doing is to create a role and a database. This is going to be inside the server. Maybe I should just make it clear that this is a server software. And that will reduce some confusion, potential confusion. So I have the server set up. I will now create a database in that server here. And that's what I will do by logging in as a different user. So this is a user login called Postgres user. So I'm logging in as that user and then create a user and a role and database and things like that. So that will synchronize what we will have in our laptop with what Heroku will have when we go there. So we'll first take the role of a Postgres login. Now you can see that my username is Postgres, not the other one. It is Postgres at the workstation, not the user at workstation. So different user now. This user has special capabilities to manage the database server that I have installed. So that's inside this user. I need to create a role named user and grant it super user privileges. This is a typo here. It should be T, not D. And so super user privileges, I will grant that. And let's go proceed to do that. So doing that now, I am going to create a user interactively. So that interaction will walk me through the steps necessary to add the name, the role that I want to add. So I need to add a named role called user. So name of the role to add is USER. Oops, I'm not searching right now. Hold on. I'm not searching. I need to add a role here. So say USER, that's the role. And will that user be a super user privileges? So I'll say yes. I need that to be a super user. So I'll say yes. And it failed on me because I have done this exercise multiple times. So it already exists. And by the way, it might fail on you as well because you might have an image that has done this step already. If you're doing it on a fresh machine, that's a required step. That's why we have it here. Now, having created that user role called user and granting it privileges of super user, we are now going to create a database inside our server. So that action is create DBE. And that's the database creation step. And it also failed because it already exists. But if it's a new machine or a different computer, it will not fail to create one. Now I need to quit out of the Postgres user. So I exit. Now I'm back to my regular user. That's what I did. In short summary, what I did was I had a server software here that I installed called Postgres server. And inside there, I need to create a role called user, granted super permissions, and then create a database by that name. Where is that? No, not this name. This name. Database by that name. And then I exit. So I come out of the super Postgres user. And like a regular user, I'll proceed with other steps. Now, back here on the command line, I have a database created and I exit. Now I need to install some things. Now what are we installing here? So the ideas that we have here are that we need to interface with our Postgres database. We have the PG database, by the way, this Postgres database that I mentioned. Postgres is this database here. It is the world's most advanced open source relational database. And this is not a joke. This is actually very high. And many big companies use it already who don't want to pay lots of money to Oracle or Microsoft, they would use this. And it is free and open and highly maintained and open source. That's the beauty of this thing. It is a 30-year-old active development. 30 years is not a joke. It works beautifully. It has never failed on me. And I have worked in this industry for many, many years, since 1990. That's what I've been doing. So it's a very good solution, by the way. Having said, this database doesn't talk Ruby. It talks its own thing like SQL queries. So you need to have a structure where you can talk Ruby language to this database. For that, you need a thing called pggem. This pg is a gem to manage your Postgres database. And it is how you will talk Ruby language to the Postgres database. So this is the Ruby interface to Postgres. You need to have this pggem installed. We will have it installed. But then that pggem itself requires certain development libraries. And those are libpqdev. That's the library we need to have. So we'll install that library first so that the pggem is ready to be installed. So we'll install the libpqdev library first. And then gem install pg. That will bring the pggem. This pggem will let us talk Ruby to Postgres. So it will understand us. The gem is installed. Now we are ready to use pg to interface with Postgres and talk Ruby language to Postgres. By the way, all these database-y thingies, we are not going to use it. But I'm just illustrating these concepts so that we know what is necessary. We are not actually writing a database-based application. We are just going to skip that portion. But these steps I have here so that you will understand what is necessary. Next, we'll actually use the Rails framework that I mentioned, which is also here on the same site called RubyGems website. We can just search for Rails gem. And that gem is this one. And that's what we'll be using. We have it installed already on the left side. We have the database installed. We have Rails gem installed. And we have the pggem installed. And the pggem is this one. And we will now proceed in asking this gentleman to create an application for us. Simply speaking, he'll create it for you because we are using his software, Ruby on Rails, this one. That's what we'll do is ask this software to please create an app for me. You will see that it will create an app called MyApp. And it will use the database Postgres SQL. And install it and make it ready for you, simply speaking. That's where it will happen. So we'll say Rails new MyApp. And use the database connection Postgres. And that's what I will do. So when I do that, you will see that a new folder gets created by this name. And a bunch of things happen. And that's your app. That's it. There's not much to it after that. So we'll have an app ready. The app gets created. And a bunch of files get created. All the green items here you see on the left side are happening. So they're getting installed right now because this gentleman is writing it for us. This guy. So that new Ruby application is getting created for us for right now. It will do nothing much. And we don't want it to do much because we just need a placeholder application. We'll tweak it a little bit and make it our own, customize it just a tiny little bit. And then we'll put that in a git commit and then push it. Then we are done. That's the plan. And so let this finish. And then we will go back here. And we have an app, by the way, ready. And so at that point, once we have the application creation completed, which should like a minute or so, it should finish. And then we go into the application, my app. And then proceed forward to the next step. That's the plan. So this should finish by now. There it is. Finished. And so if you somehow see an error here, somewhere here, which I don't see any errors, this is expected. And so I don't see any error. But if you do see an error, you run this command. If you run into an error, I don't think you will, but I will skip forward. So go next. Then we have to understand this idea of MVC. For those of you who are not actually developers on a day-to-day basis, it's a good idea to just briefly discuss this concept of MVC. This idea of MVC is how you need to think about when you are creating applications. So now let's go inside here in the folder here called my app, that folder. That's where the application is created today, February 5 at 2 o'clock London time. This is UTC time. So that application is there already. We can go to my app and see it. So that's the application. You can see that it has a bunch of things already. In Atom Editor, you open it up and choose. And there are a bunch of files and bunch of folders created for us already. And here is the app. So there is the app containing the application files here. There is a binary folder and a configuration folder and a database folder and a library and logs and public and this and this and that, a bunch of things created for us. This is what the application actually is. And you will notice here a very important feature and an important thing that I already talked about is called a gem file. The gem file is the crux of what we want. It specifies all the dependencies that this app needs. So you can see that this app needs these gems. You can see them. It needs Rails gem, it needs PG gem, it needs this and that and this and so a bunch of gems listed out one after the other. And that's how the application got installed is what you see. Now, the idea behind this application as you will see in the app folder, it contains a bunch of subfolders and those are assets and then controllers and then helpers and then mailers and then models and views and layout and concerns and this and that and the other. So this is something to understand. This, by the way, is how Rails likes to do it. Rails gem that we have used created by this gentleman. He likes to write down his application in this exact structure. He likes to segregate different things and put different things in different folders like that. JavaScript will go here, style sheets will go here, and controllers will go here, and helpers will go here, and mailers will go here, and models and views and like that. That's his disciplined approach. And I like it already. I like it because it is very, very clearly called out as to what is where, what goes where. And just by the fact that you know that there's a specific place to store a variety of pieces of code in separate folders, it already puts you on a straight, simple rails, guided rails, to get to success quickly. So that's the point. Having said, we need to understand a way of writing, a way of writing what I call applications. And one such architectural pattern is the Rails MVC pattern. This stands for, MVC stands for, do you know what MVC is? It is model, view, and controller. But do you know what MVC actually is? What is model, what is view, what is controller? Do you know what these things are? Is this new to you? If that is new, please tell me. If that is not new, at least I'll understand. So please tell me that this thing is new or not new. Have you heard of this thing before? That's new to me. Okay. So let's go understand this thing a little bit. Dominic's is not new. Okay, got it. So MVC pattern, by the way, just like this, there are various other patterns of creating applications. This just happens to be one of them. One such pattern is MVC. And so let's go see a bunch of other patterns like MVC. So MVC pattern. And you will see that there are such other patterns like MVC, like MMVC, MVVC. People will just make stuff up. I don't want you to focus too much on this idea, but just understand at a top level, what do they actually mean? What do they mean by creating these patterns? The idea is like this. Let's say if you want to create an application, which shows you in a browser window. Browser in window. It shows you how many cats and how many dogs are in the house. So this is my house, and I want to create an app that just shows how many cats are in the house and how many dogs are in the house. That's my browser window. That's what I see. So therefore, I call it my view. And so any code I write that will show me the view will go in the views folder. That's the idea. So whatever you create that will show the view in a browser window or an application, an iPhone app or whatever app you have. So that's a view is what you see. Imagine right now I have no cats and no dogs. Imagine that. Then I go to the shelter, and I find one dog. And so I bring the dog home. Oh, man, this is crazy. The dog actually walked into my room right now. So the dog, he just walked in. And so now I have this one dog in my home. Having said, what does this do to my view? My view needs to change, right? But the view doesn't change by itself. View will change when you have the data change. So there has to be a data store which stores the data about how many dogs I have. The data was zero. Now it needs to be plus one. How many cats I have? Well, the data was zero. So there has to be a place to store this data. And the data needs to change when I bring a dog home. I need to make a change in the data structure here. And then this view should automatically update to show that I have one dog. So this data portion is what is the record is called the model. That's where the word model comes in from. The view word is what you see. Model is what you record in a data in the storage or data store, database, whatever you have. And then there has to be a third piece which actually controls the whole thing. So the action which controls what goes to my data, data structure in the model, or whether I go to the shelter and get a dog, that action. And those actions are basically dictated by a controller piece of software. So controller.rb, excuse me, there will be a file called controller.rb or some other file like that. That will sit in the controller's folder which will actually contain the code that controls the behavior of the whole thing. So if I redraw this, I have a controller piece of code that controls what my data has and what my view shows, simply speaking. So this is called model. And this is what shows. And this is what controls. So this is your controller that controls what is shown, what the actual data is, and that's the idea. So now if I take the dog, one cat and one dog right now, zero cat, one dog. So now I take my dog out of the home to go for a walk. So if that happens, then my data needs to change. Now this dog should become zero, dog in the home is zero, dog outside with me is one. So I walk the dog and this is me and the dog. So this is your dog. And those two guys are walking, but they're not in the home. So this is number zero. This is number zero. And then I go back home. So then the data needs to change in the database. And as a result, the view should be one. And that's the underlying idea behind MVC. There are various changes, variations to the same idea, MVC, this pattern, that pattern, but all of them basically operate the same way. It's just to make things simple. I wish I could, but I can't open apps here. Sorry about that. These guys will talk. These devices talk all the time. That's crazy. So having said that, let's go back here. So we have a folder containing our controllers. This is where control logic goes. Our model, this is where our data management logic goes. And what we see and what we show people will go here. So that's your MVC pattern. There are some other related items also, like how you store your assets of images in JavaScript and style sheets and some helper functions, some mayor functions. They're related to whatever else you may be doing, but core ideas are MVC. That's the idea. That's the whole concept of this app built using the MVC pattern of Rails. And that's what we'll be using now. So we'll go back to our browser. And there we have our exercise, which is what we were doing. We're discussing briefly what is MVC. And now we will make some changes to the code. So what we want to do is in here, customize our application and create a new controller software. This controller that we have basically does nothing. And it is empty because the app doesn't know what you have in mind. So it doesn't do much at all to begin with. So what we want to do is to actually create an application to customize, to generate a welcome controller. So we are again asking the same person, the DHH person, this guy. We're asking him to create a piece of controller software for me to welcome people when they visit our page on the website that we'll be creating. And so that is going to generate a welcome controller. What will happen as a result of this action is a new controller will pop up right in the controller folder right here like this, when I paste. So when I say generate a controller, it will create a new piece of code and dump it in there. So it says created this and created that and created this and created that. And you can see these creations happening showing up here. You can see that there's a welcome controller now and there is a welcome helper and there's a welcome folder here in the views, which contains nothing and like that. There's a welcome SCSS, which is also empty. So you have a bunch of things created, generated by this gentleman for you in your folder based on what you asked for, which is to generate a welcome controller. Now, what we want to do is to create an index page to show when people visit your welcome page, which needs to go to the views folder in the welcome section. And in there, we need to have a file inside it called index HTML RB ERB. ERB is a template file for Ruby. So index.html.erb is a template that we want to create in the views welcome folder. So app view welcome index ERB and you create a new empty file. And in that file, I just dump this very, very simple. I dump it, save it. What this does is shows a view of what time it is right now. That's it. Nothing much. That's the view. It's not cats and dogs. It's just showing the time. That's my change. I need that change to actually take effect. So this welcome index that I have created here needs to take effect. That effect will happen only when you change the routing of the configuration of the app. That means when somebody visits my website, whatever.com slash. That is the beginning route, the beginning point. So when I hit that link, it goes to the front page. That's what shows up. That is the route to the front page, the welcome action. That's what we are creating right now. So we have created a welcome index page, but it will not show by itself. You need to tell anybody who lands on my front page needs to be shown the welcome index page, for which you need to make a change in the configuration. That configuration change happens in your config routes.rb file. So the config routes, you will see it is available in here. Go to the config folder and then look at routes file right there, route.rb, and you need to edit that file. To tell this application that whenever somebody lands on the front page, please show them this. Show them the welcome index file. So we need to make that change in the configuration routes. And the welcome route is basically right there, line number 6. You need to change that route. It is currently commented. You need to just remove the comment hashtag. I just removed the comment hashtag and I'm going to save it. And then I close my config routes like that. Having done this thing, I remove the hashtag. It will look like this, which is what it does. And then I need to see if my application actually works right here, right now. So we'll go back to the terminal and see if our app runs right here. How do you get the app to run right on the local machine? It's a Rails server. So please create a server for me right here and show it to me, show my app to me. So now Rails is running a server and it is telling you that it is running at that location. So you can go to that location right here. You copy the link address and open the browser and just wait for it to load, paste and go. And there you see your app. I mean, I spoke before, but yeah, here you see the app. Hello, Cloud Genius. The time at this moment is whatever the time is. It is 2.20 in London and that's what's showing up here. It shows the Cloud Genius machine is a UTC time machine. So it works in the London time zone, which is where you see the application is running already. Beautiful. Close it. And now here you want to break your My App. And the server is broken and you're out, back to the terminal. Having said, you see the application running on your local machine. You break it. You proceed to the next step. And then you need to put this all in a Git commit and send it to Heroku. Before you do that, you need to edit the gem file. Make sure that you are matching the Ruby version, Ruby-V. The Ruby version I have is 2.3.1 and the instruction here says 2.5.1. That needs to be edited. So I'll just edit that quickly. So here I need to make that change right away, otherwise it might confuse you. So I'll make that change in the website. And you can actually see how I make changes to the website right now. You can see that I'm going to the website and I'm searching for 2.5.1. You can see that I should be making a change like here, 2.3.1. And then I will send my changes to the website. So npm run start should push my changes to the website and it should go live right here. So this 2.5.1 should automatically become 2.3.1 in just a second. So now it should have finished by now. And now I just refresh my page and it should show 2.3.1. There it is. So that's what you should be using, 2.3.1 as a line reference in your gem file. You will open the gem file in Atom Editor. So there is a gem file as you know already. So it's in the section here. And there you need to add this line at the very bottom of the gem file. And by doing that, what you're telling Heroku is to use this gem. And so you're saying, Heroku, please use this gem. So like that. And we have to also cross check with Ruby, with Heroku, that they actually support this gem. If that is not the case, we have to change our Ruby version. That might happen sometimes. So this 2.3.1, let's go check whether Heroku supports Ruby 2.3.1 or not. That cross check has to happen. It is telling you that 2.3.1 now supported. Okay. That's good to know. So Ruby 2.3.1 is supported. It is telling you that you can add this line, Ruby directive to the gem file to know that 2.3.1 is supported and that you intend to use 2.3.1. So that's what we intend to use, 2.3.1, right there. And so we add that to gem file, close the gem file, and continue along forward. Now we bundle update our gems because we are modified. So we need to make sure that we are up to date. So we run our bundle action. Bundle action, I think you're not new to it. You have done it at least once in the very beginning. You're running Octopress, you ran this action to bundle. A bundle update, what it does is looks at your gem file and just updates whatever is necessary. And so that's what you're doing right now. It just finished quickly updating. Now you want to make sure that you want to run this application for any user. Currently, the user is who? I mean, who am I? I am the user-user. I can be able to communicate with anybody that the username that you may have is different, could be different. It doesn't have to be this exact user-user. It can be your name, it can be somebody else. And we don't even know what the username is with Heroku because they don't tell us. So we need to make it agnostic to any user, for which we have to make some changes in our database YAML. And so we'll go to our configuration again. And in our configuration, where is that? Here, configuration. Let's look at the database YAML. And there, we're going to make some changes to this file and specifically remove this line called My App. So there is this file called username My App. It should be at the bottom in the production section, line number 84 as I see it. That line should be deleted because it is tied to our username, My App. So I'm deleting that line and saving the file, closing it out. Having said, at the end, our file should actually look like what you see here. So that's all I think we have. So let's cross-check. The default section we have, which is what you see here, Postgres Unicode and number 5. We are in the development section. We have default and database line. In the test section, we have default and database line. And lastly, in the production section at the very bottom, we have default and then database My Production and password is the environment password. Having made these changes in our YAML file for database YAML, we need to now put everything in a Git repository, which is very, very simply in our folder we have, oops, in our folder we have, which is here. These steps we have to go and follow. So what we need to do is in our listing that we see the files that we have, we need to make a repository here. We don't have a Git repository in this folder, so I'll create one right now, initialize one right here right now. So I initialize it, then I add everything I have, Git add everything I have into the Git repository, and then Git commit, initial commit, and that makes a commit. Now if I check my Git status, I see that my working directory is clean, my listing is here, and I have my entire repository in my Git commit. Now if I check Git remote, I don't have any remote establishment connections. That means this Git repository doesn't know that there are other machines I need to maybe be able to remote connect and maybe do a push or a pull or something like that. It doesn't know because there is no remote connection. It's just local to me right here, nothing else. So now I need to establish a connection between this Git repository and Heroku. So I'll say Heroku, create a place for me, for my app, create a place for my app on Heroku. So now we have Heroku here somewhere on one of the browser windows, but we don't even need to go to the browser. We just say Heroku create, and what it does, it creates a place for my app in the Heroku platform as a service, simply creates a place. So then I can push my app and it will run it there. So let's go, create a place. As soon as I create a place, it tells me a URL. That's the URL. And so I can just use it. Here, that's the URL. This is the browser URL, that's the Git URL. So there are two URLs given. Now we'll go check our remotes again. So Git remote, and it tells me that it has given a connection to Heroku for fetching the Git URL and for pushing this Git URL. So you have those two URLs already as a part of your Git remotes, and all you need to do now is to just push, and you want to push it to Heroku. So you say, okay, push to Heroku. And what you will do now, as you see, is that the thing is running on Heroku. Let's go see it live. So let's go first of all push. So when you push it, you will have the same action that we did here on our laptop. Heroku will do the same exact setup steps, and you will see those setup steps happening right here in my terminal right here, but they're happening on Heroku in somewhere in Amazon Cloud. Apparently, Heroku runs in the Amazon Infrastructure as a Service EC2 Cloud. But we don't need to know about that because we don't care where they run, as long as they run, as long as I push like this, which I just did, and the whole repository is getting pushed over to Heroku, and they are... The error says, error occurred while installing Ruby through 3.1. This version of Ruby is not available in Heroku. I thought you just told me it is available, and there it is. Ruby is now available, and now you tell me it is not. Very interesting. Okay, how do you overcome this problem? This is just silliness on part of Heroku. They should tell me that it does not support when I ask for it, but let's go find out what the resolution to this will be. What I need to do is just read into detail about what they are telling me is to go here on this link and find out what are the supported run times. We'll copy the link address, go to the browser window here, and say, okay, what are your supported run times? That is Ruby version. Supported run times are... Here are our supported Ruby run times. You just changed it on me without telling me. Very nice. It also means that you can see technical server 245 apparently is what we need to install or something like that. That's what we need to get, 245, which is what we just have to deal with. That's okay. I will show you how to deal with these situations. Thankfully, what we have in our application, in our command line, is we have the ability to run multiple versions of Ruby language and multiple versions of multiple languages at the same time. Let's go see what languages do we have, and what versions we already have installed, so R, B, E, and V versions. Let's see what versions of Ruby are already here. Only one version of Ruby 2.3.1. What these guys want is these versions, 245, 251, 261. Let's see what Ruby language versions are available publicly, and those versions are 261, 260 as the latest version. What about older versions? Older versions are 253, 245. What does Ruby Heroku says? Heroku says 245, and this is 245, so that is released. We should use 245 then. This is common publicly available. That's what Ruby is using in Heroku. We should just switch to 245. How do you do that? 245, you just say R, B, E, and V, install 245. That should do it. It's not found, so we have to go to R, B, E, and V. They're telling you how to do it. Version is missing, so you go to this section. Copy and paste. That is a critical action. It'll update R, B, E, and V itself. You can install whatever latest version of Ruby that you need. It is installing 245 version. Then we need to check our gem file, which says 231. We need to make it 245. That will be done as soon as this Ruby language installation finishes. We'll switch over to that and do a bundle install, and then modify our gem file and push. Again, that push this time should succeed because it is matching the supported version from the Heroku platform, which tells me in one page that it is supported 231, which I checked before I ran. But now it says, no, it is not, which is crazy. Crazy, but I guess that's how you deal with in real life, so that's okay. We'll just close this window, close this, close this, close this, close this, and go here and focus on what we want is 245. That is this version 245, which is getting installed. In the meanwhile, what I'll do is open my atom editor in the gem file. I will modify and make it 245, like that, 245, and save and close. I need to re-delete the gem file.lock and run a bundle again. Just remember these steps, they're not written down here. You need to remove the lock file, move to trash. It will automatically generate a new file based on the new updated gem file we have, which is using 245, which is what our Heroku guys are mandating. We'll follow. We'll follow whatever they tell us because we want to run there. Otherwise, we'll run it ourselves. This is something that I think we can actually very, very diligently avoid. I honestly don't like using platforms as a service, but I'm just going through these motions to help you understand. Honestly, the better approach is to not use these platforms, but instead build your own platform using Docker and Kubernetes. That's a recommended approach these days. I don't like the idea of getting tied down with what they tell you to do, because this is too much. Actually, this is too much to ask to dictate. You know what? Use my version of Ruby. What if I want my own version? It is my application after all, not you dictating me what to do. Therefore, I don't like it. I'm being philosophical right now, but I want to remain in control of what I want. I want to run the way things I want, not what you tell me. I pay you money, so you better shut up and do what I want. But that doesn't seem to work that way, and that is something that we can avoid. I'll tell you how to avoid those things. You can avoid it by using containers and Kubernetes, and you control your own destiny, and you build your own platform. That is a better approach, no doubt in my mind. We will just finish off this exercise, and we'll switch to that idea very, very quickly. You will see me do those a whole lot more than getting tied up like this, which I honestly hate. Somebody telling me, hey, you don't use that version. You use this version. I mean, why? Why would I listen to you? You have to have a logic. You have to have a reason. And maybe there is a reason that I don't understand right now, but at least I control. I think that's what I want. So tomorrow I want to change to 2.4.5. I should be able to, but not because you told me, but only because I want to. And that's how I think. But I just told you how I think, which is up to you as to how you think, because it is important for you to decide what you want. But my goal is to tell you how to do things the way you want, as opposed to getting dictated like I am currently getting dictated to switch to your Ruby version 2.4.5. I'm complaining about it, but that doesn't help anybody. So go the Docker route. Go to the container route, and we'll take you there soon, as soon as we finish with this, we'll switch to Chef, Ansible, Docker, and it finished. So now the last step is to cross-check our gem file here. So cat, cat gem file, and there it is 2.4.5 right there, here. So we'll do a git add and a git, sorry, where are we, git status, git add dot, what is it telling me? Oh, I need to, okay, let me reset my git, git reset. I have deleted the log file before, git reset hard, and then edit my gem file one more time to make it 2.4.5 again, 2.4.5, save, close. Now let us see if we can get git add, and it did. Now we have git commit minus am, and then I modified to Ruby 2.4.5. And then I have my git status showing up, and my git remote showing connection to Heroku. So I'll say git push Heroku master, and this should send my new application using 2.4.5 Ruby to Heroku. So let's go push. So it is pushing, and now it seems to be building something. Okay, so I told you Ruby version 2.4.5, and now you're telling me what? I have my gem file says 2.4.5, what are you telling me? Okay, let's go bundle again, bundle update, and one more git, one more. Oh, I see. So I installed 2.4.5, but apparently my current Ruby is still 2.3.1. That's the issue. So I need to switch to that Ruby version by saying rbenv, that's what's going on, rbenv, and then globally use the version 2.4.5, and now my Ruby version should be 2.4.5. Okay, now I say bundle update, bundle not found. So it is gem install bundler to update the bundler software, then install the bundle to update the gem file, the new gem file at 2.4.5 version, update the bundle, do one more git commit and then push. And now more errors. Okay, the error here is it's actually very easy to resolve these errors. The gem file requires a different version of bundler, so the bundler gem needs to match. The Rails requires this. Okay. Hold on. We need to read this carefully and understand what's going on. It says bundler could not find compatible version for gem bundler. The version of gem we have is 2.0.1. And in gem file, we have Rails was resolved to 4.2.0, which depends on bundler less than 2 or more than 1.3.0. And what we have is 2.0.1. So we need to install an older version of gem bundler, not this 2.0.1. So we have to get an older version of gem. So first of all, gem uninstall this bundler, uninstall bundler, and then install the other version of gem, the older gem from install older gem. Let's go see how do you install a specific version of gem and you install it like this. So we have to say gem install bundler, but with the older version. The older versions are you have to go find it from RubyGems. This can be a little confusing because I'm going completely off track because they have thrown me off. So we're going to go bundler gem version available. The available is 2.0.1. The older versions are 1.17.3. That's what I want. We'll grab that like this, gem install bundler-v and then the version number, older version, which will bring an older version of gem. And now if I say gem, sorry, bundle update, that should reduce the error. Bundle update should resolve the error. And it is installing all the gems with the version that 245Ruby has and that will build a new gem file lock, which will commit it and push it, and that should drive it to the resolution. This happens occasionally when you run into crazy situations like I just ran into, which is Heroku tells me 231 is okay, but then later on say no, that happens. That's life as usual. Nothing ordinary here. I mean, yeah, it's very common. It happens all the time. You just have to know how to handle it. So watch this portion of video again if you're interested. And you will find how I actually resolved through this problem, which I hope will actually resolve. So waiting for that to finish, and then we'll do a git commit, sorry, git add, git commit, and then git push. Then we should be completing with this exercise. So that's what I'm waiting for, these gems to install. And come on, yeah, it finished. So now git status should show us a new gem file lock. So we'll add it, git add dot, and then git commit dash am, updated gem bundler, and then we added that, and we have the git remote. We have the remote connection to Heroku already. So we say git push Heroku master, and that should this time not create a new error, I hope. We'll see. We'll see how it goes. And it is sending our app. Looks like it is working. Sweet. So this is installing the same exact step like I did locally here. And so I need to now modify my instructions. I need to tell this new step that I incorporated. And so you can see that the application is currently going live. And this should be 2, 4, 5. And the bundler should be right there. So you can see on the other window that Heroku is actually installing the application on their cloud. And that should be ready in a matter of a few minutes. I think it is done. It should be live. So let me just go there and see our new app. So what I did was updated the instructions on the live website. And the instructions are going live right now as I updated them. So the website should refresh itself. However, Heroku has told me that it is live. It deploys done. So it is already working at that link. You can open the link right here on any browser. So we just copy it, go to our Slack chat, paste it there. You can also see it. I can see it. We just click on it and see what happens. So we see that it tells me that the application is currently functional, which is beautiful. So it worked. All we did is I shouldn't simplify. All we did is quite a bit of a nightmare. But think about it again. Think about it again. What we did is this was not easy. No way. But let's review what we did so that you will understand. Let's get to Heroku first. Where is the Heroku exercise? That one. So here we began with a tool bed installation. I think a white sheet of paper will help. By the way, the app is running here. And you can see that that's what we wrote. So the time is whatever time is. Having said, let's go review. So recap of what we did. We began with a version of Ruby that was 2, 3, 1. We checked with Heroku that 2, 3, 1 is OK. And it told us that 2, 3, 1 is fine. Where is that? Somewhere. You saw it. And let me close out unnecessary things here. You saw that we checked with Heroku and they told us that 2, 3, 1 is OK. But they did not tell us correctly. So we began with 2, 3, 1 Ruby. And we followed through the exercise in creating an app. So create an app. But before that, we need to have Rails installed. So we say gem install Rails. And then it installed the Rails application. We created a new app. We understood our model view controller idea. We modified our view and put this view that we see here in place. Then we modified. That's our view, by the way, that view that whatever you see here. Then we modified our route and said, you know, the route, whenever anybody goes to the front page of the website, which is this front page, that you should show them this view. This view that you see here. That route modification we did. And then we did some database changes to make sure that there are agnostic to the application name chosen, like my app name chosen, the user name associated with that. I got rid of that. And then we put everything in a git commit and say push. The push should have taken us to this place. But then we ran into an error. So when the error came, what we did is we read the error. The error told us very clearly what the problem was. So we did this action, Rails install action. But then I added this new action right now. This is a statement that I just inserted into the website right now as we spoke as we did this because this is a required step. The new required step because we are forcing ourselves to using two, four, five Ruby. And this version of Rails and this version of Bundler is the requirement combination for this Ruby. That's the interdependency lock. So we are able to accomplish that by focusing our efforts on this version of Bundler with this version of Rails and this version of Ruby. That's how we're able to break the deadlock and get to a working situation. If you don't understand this detail, it will be difficult for any application to run unless you resolve the deadlock. The dependencies need to be met correctly, otherwise it will not work out. Having said, we proceeded with two, four, five Ruby this time. We had to install that version of Ruby we did not have to begin with. So I did that. I said R, B, E, and B install. Then I ran through the entire steps again. Subsequently, when I noticed that I built an app, then I undiscussed MVC. Then we customized our app a little bit. And then we put our app in a Git repository with this line in our gem file added, which you saw. This line basically helped us eventually resolve. Then we also updated our bundle. And then we store the app in a Git repository and check our remotes, created a place for it in Heroku. And then a remote check again and then pushed. This time it ran. It just ran. You can see this running on your local machine by Heroku open or just read the reference that you will see at the end of the run. Successful run will give you a link like this that you see here. That's how you see it. Now, if you go to the Heroku website, you can, by the way, do these things on the website also. You can see some of the references on heroku.com when you log in that you should be able to see your newly created app that I just have here somewhere. One of these apps, I have so many apps. One of these apps is called Polar Plains 23659. Let's go look for Polar Plains. Where is the Polar Plains? Right there. You can see this Polar Plains app is the one that I have with me that I'm running right now. And this was deployed today at 6 44 p.m. And you see that it failed two times. This is a failure log here. There's another failure here. And then this succeeded. You can actually go back and see the failures. The failure happened because it tells you 231 not supported, not available. That's one failure. Let's go back. Look at the other failure. This failure happened because it again detected 231 because we did not actually change the version and did not update the bundle in our in our local computer. Then next one, it succeeded. The success log actually tells you the location where the application went live. And that was this location polarplains.number.herokuapp.com. And so that is the location where it is running right now. You can see it. But having said this idea of running an app like this with Polar Plains doesn't make sense. Does not make sense for a business. Nobody can remember what Polar Plains was or whatever that number is. So there is another idea to go with this. And that idea is simply using a canonical name. CNAME. So what you need to do is is go back to here and make a CNAME record somewhere here in your website. You should be able to go to the settings section and identify where can you set a CNAME. And so, yeah, there it is. So apparently this is a paid upgrade. So you can point your custom DNS. You have to pay for it. So this DNS name that you have Polar Plains. You can go to your own www.yourdomain.com provided you pay. And you don't have to pay. There's no need for you to spend money for this. But only thing that I ask you to is to understand that you can. You have your own www.whateverdomainname.com that you have. You just create a canonical name record in your DNS and you pay these guys money. And then associate this name to this longish Polar Plains name. And then you don't have to use this name at all. You can just use this name and you add the domain that you have, whatever name you have here. And you pay them money and you have your site functioning. That's the idea behind platform as a service. It puts you sometimes in a tight corner. You have to follow exactly what they want you to do and then you're okay. You have to pay for their machines. They call them dinos in Heroku. You pay I think some $33 per month for a dino. Maybe I have a world pricing. I have no idea what the pricing is. But the point is it is not free. It is not free because it makes it easy. Apparently easy. It actually makes it difficult for me because I like to retain my control as to exactly how I want. Not listen to any of these guys saying you don't do this or do that. That's not how I operate. So I actually don't like using platforms as a service. Show it to you. This is how you can work if you like. It might be actually easy for a corporate scenario to build your own platforms as your own internal service and not use these guys. I mean, this is just one example. I'll tell you some examples of how you can construct your own internal platforms as a service for your own company and not have to rely on these guys. That's a better solution. Actually. So let's go see some examples of that. And you can actually if you're interested, we'll go in the if you're interested, we'll go in the routes that I am going to give you some examples right now. Just naming them right now. But if you want, we'll do exercises with them. Unless if you don't ask for it, I will not do it. Just telling you right now. So there is a simple product they can play with is to build your own platform as a service. So that will be called one of the biggest names that I think in this domain is already available in the open source. It's called Cloud Foundry. And I think the Boeing Company uses this already. Now, this thing is an open source platform as a service that you can run internally in your company. You don't have to go to Heroku. And I think you're running it already. I think you have it. Now, I've never seen it from yours inside perspective. But I think you hire these guys pivotal, which is EMC, basically EMC, Dell EMC. They own it. And so the company installed this thing for you in your company. So you have it. And this Cloud Foundry thing operates just like Heroku. Just basically a clone of Heroku. Heroku started first. These guys created pretty much like Heroku. And so you have it. So you can use it internally. It's available to you. It basically operates just like Heroku does. So pretty much similar to Git Push and whatever your internal name for this thing is Cloud Foundry Master. And it will take your applications live in your internal cloud, which I don't know where it is. But you have it. You have Cloud Foundry in your company. So use it. That's the one you should be using. I cannot demonstrate that to you because I've never seen it and I don't have access to it. So I gave you a Heroku example. But this thing, you have it in your company. You should be able to use it just like I did Heroku. There's virtually no difference. There is practically absolutely everything is different about it. But conceptually, it's the same thing. You should be able to just build your apps and push it to Cloud Foundry in your company and enjoy. You don't even have to pay them because it's your own internal. Maybe you do intercompany payments. So you pay your IT services and something like that. Funny money. Funny money. You know what funny money is? Funny money. Is when you take money from one pocket and put it in your other pocket. That's funny money transfer. That's you one team in one company transferring money to another team in the same company. That's funny money. That's what you can do to use this internal deploy tool just like I showed you Heroku. Heroku runs here. You run it in your internal location. It's your choice. I would recommend that you use the Cloud Foundry thing. This is what you should be using. Now, having given this one example, it's fairly complex to set up Cloud Foundry on your own as a person doing in a session in a live video conference. I cannot do it in one session, one sitting. Not possible. So what I can do is show you a simpler version of a platform as a service that I think you can get through this exercise. If you ask me, I can do it for you. This is a open source product that gives you a Docker powered platform as a service and it works out beautifully. If you want, we can do this exercise. But again, I would rather use direct Docker itself as opposed to using a tool like this, which is another layer of abstraction. I would rather control my infrastructure and my underlying things under my application that I run end to end in my control and put all of that in one Git repository and get it to run the way I want. As opposed to having other people dictate, I want this, I want that. No, these guys, they work for me. They are my service providers. So I need to control what I want for my users because I work for my users. I create my application for my customers and my service providers cannot dictate what I want to do, what I need to do with my applications. So I don't like all these things under the hood. I would rather create my own, all from scratch, from ground zero, bare metal, all the way, build everything on top and put that in a Git repository. And yes, you will put machines in a Git repository, hardware in a Git repository, network in a Git repository, storage in a Git repository. Everything goes in a Git repository. This thing, this thing, this what I just showed you, this site, even the content, even the database is in a Git repository. This is like extreme examples I'm showing you right now. Anything that I store in the content library here, whatever you see here, they are in a Git repository. You saw me do these things live and I make an edit here. So like I modified this line here. You can see that this actually is a change I just made and you can see the change in a Git repository that's opening up right now for you. Here it is. And you can see the changes that I made. I have not committed them, but you can see the changes already that I made here. I made these changes just as I was talking to you. You can see that I modified the 15 number file platform as a service hands on. I made a green item here, which is the Rails bundler edition. I don't know why I have it. That is written wrong. It should be bundler. It should not be Rails. Then I have modified this gedit to atom. I modified gedit to atom and I have modified 251 to 245. That's a change I made. It was 251. I made it 231 and then go back to 245. That's what I have made. I will make a few more changes. For example, this Rails is wrong here in line number 73. I should go back and say that this is not actually Rails, but bundler to match Rails requirement. Then you can see the changes are showing up in Git. I made that change here. I will push this change right from my command line to the live database. I'm doing that. It goes. It is going right now. Come on, show me it's done. Yeah, it's done. Which means I can go back to the browser and go to that section where I have the platform as a service exercise. I can see that I made the changes and they will all pop up right here. I'm making these live changes in the database. You can see this. I just wrote this line two seconds ago. That change showed up. Every single thing that I do is in a Git repository including the database. This is extreme. Very few people do this, but it's not always possible, by the way. People just use databases to store databases and they cannot track changes in the database, but I am doing that. I think this is a better practice because you then control exactly what you have in database and you don't even have to go and update the database itself, which you can, by the way. By the way, you go to the database, you connect to the underlying database and then you look at it and then you see that you have these data structures that you see the collections. This is, by the way, the Mongo database. You can see the lessons that you have and then you can see the lessons inside. This is a very difficult way to make a change. I'm looking at a live database and you can see me hack the database if you like. Here's the database that I can look at the steps and go to the step number one or maybe number two. It's so hard to find. That's not recommended to edit the database like this. You can see the same database, but manage it much better if you do it in Git repository. That is what I just showed you. This is a recommended practice. You should actually use your own internal platform as a service called Cloud Foundry and not use Heroku, which doesn't. I don't like Heroku very much anymore. I used it a few years ago, but I think Docker solutions are much better. If you have a solution internally, use that one. It's a much better idea. This works identically to Heroku, by the way. Having said, we are going to pause recording. I'm still here for questions and I will now begin next time. We'll talk about DevOps, which is using tools like Chef, Ansible, Docker, and taking a real life example of an application, take it live to a cloud of your choice with no limitations. We will not put ourselves in any kind of constraints like we just got this 2, 4, 5 Ruby constraint put on me. We will not tolerate such things going forward. Having said, I will now stop recording. I'm still here.