Let's talk about toolchains.
Software, like a car, is not made by a single person or in a single place. They are comprised of many pieces & brands you've probably heard of. Mysql, Michelin, php, Honda. What you may be less familiar with are the brands behind the building process. Abb Ltd., git, Adept Technology Inc., Heroku. I'd like to take a minute to introduce you to the "behind the scenes" and eventually get to a little intro challenge.
For the moment, let's focus on the web side of things. You go to a URL and get a page. There's a backing server, some protocols, and maybe a database in there. The user doesn't particularly care how that's set up, but as a (new) developer, you will. Choices must be made, trade-offs considered. First:
How do I publish to my slice of the web?
There are several providers in this space. While you could go out and buy a domain, get a server, etc, that's expensive and not what we need. We want a place to write some code and test. We want easy. I'm going to steer you to Heroku or OpenShift. Both provide free, basic/low scale services that are easy to get started with. Which one you pick may be influenced by the technologies you want to learn. Heroku lends itself to ruby & rails, OpenShift lens itself to a MEAN stack. But more on that later.
K, so... how do I post stuff?
I'm going to ask you to create a "Hello, World!" application in a bit. You're going to write a little code, and it's not going to work. Your going to modify it a bit, and be excited that it does work. You're going to try something cooler, break everything, and not be able to get back to where you were. Luckily, we have tools for this. Enter Git. Git is a (source management/source control) system to track your changes. In addition to saving your files like normal, git lets you create "snapshots" of a directory. Work a bit, snapshot, work some more. You'll have an accurate history of what you did. Even better, it allows for tangents (we'll call that a "branch" of work). If it works out, you can merge that back into your main line of work. If it doesn't, you can abandon it. And you can switch between these tangents freely.
Git is actually even more powerful than that. Not only does it let you keep snapshots on your computer, it lets you distribute them. Keep them on other computers, in the cloud, whatever. And you can tell it where your other copies are. If you don't have one, you're probably going to want to sign up for a github account now. Go ahead. I'll wait.
Okay, so remember what I said about multiple copies? That's actually how we're going to tell your provider (Heroku or OpenStack) what to deploy. Once you've created a project (probably on github, then on your machine by cloning it down), you're going to want to see it run. You can test locally (sometimes tough depending on your home setup), or push it to the cloud. Each provider has a guide on how to "add a git remote" to represent their server, then issue a "git push" command that connects, uploads, and starts your app. Hopefully those keywords are enough that you can google-fu your way to a successful app launch.
But what language do I pick?
It's going to turn out that it doesn't matter. I don't care. A lot of front-end development is going to a MEAN stack (MongoDB, Express JS, Angular JS, and NodeJS), though there are still some tried-and-true apps running on the LAMP (Linux, apache, Mysql, and PHP) stack. Pick your poison. Because the exposed bits will be accessed from HTTP, we can define our application to look the same on the outside, despite having different technologies backing it up.
The Challenge
At this point, it's time to try. Getting all of this tooling up and running is a significant hurdle in the project process. And you'll learn lots. Actually, I'd encourage you, after getting a successful "hello world" in one system, to do it on the other. You might be surprised at how much conceptual overlap there is. Again, at this point, it doesn't matter what stack you pick. And you definitely won't use all of the pieces (no database is required for a simple "hello world" to display on your page).
Thinking ahead
If we think a second on how we deployed to the web (via a git push command), it's obvious that we could push to other locations with a similar command. Once the app gets more complex, you may want to do that so that you can add new features in a "sandbox" while having your live system running. Those essentially "test" and "prod" environments. And if you start working with other people, those will become critical as a means to add new features & collaborate without risking production system stability. Yeah... I think we're on to something...
For the moment, let's focus on the web side of things. You go to a URL and get a page. There's a backing server, some protocols, and maybe a database in there. The user doesn't particularly care how that's set up, but as a (new) developer, you will. Choices must be made, trade-offs considered. First:
How do I publish to my slice of the web?
There are several providers in this space. While you could go out and buy a domain, get a server, etc, that's expensive and not what we need. We want a place to write some code and test. We want easy. I'm going to steer you to Heroku or OpenShift. Both provide free, basic/low scale services that are easy to get started with. Which one you pick may be influenced by the technologies you want to learn. Heroku lends itself to ruby & rails, OpenShift lens itself to a MEAN stack. But more on that later.
K, so... how do I post stuff?
I'm going to ask you to create a "Hello, World!" application in a bit. You're going to write a little code, and it's not going to work. Your going to modify it a bit, and be excited that it does work. You're going to try something cooler, break everything, and not be able to get back to where you were. Luckily, we have tools for this. Enter Git. Git is a (source management/source control) system to track your changes. In addition to saving your files like normal, git lets you create "snapshots" of a directory. Work a bit, snapshot, work some more. You'll have an accurate history of what you did. Even better, it allows for tangents (we'll call that a "branch" of work). If it works out, you can merge that back into your main line of work. If it doesn't, you can abandon it. And you can switch between these tangents freely.
Git is actually even more powerful than that. Not only does it let you keep snapshots on your computer, it lets you distribute them. Keep them on other computers, in the cloud, whatever. And you can tell it where your other copies are. If you don't have one, you're probably going to want to sign up for a github account now. Go ahead. I'll wait.
Okay, so remember what I said about multiple copies? That's actually how we're going to tell your provider (Heroku or OpenStack) what to deploy. Once you've created a project (probably on github, then on your machine by cloning it down), you're going to want to see it run. You can test locally (sometimes tough depending on your home setup), or push it to the cloud. Each provider has a guide on how to "add a git remote" to represent their server, then issue a "git push" command that connects, uploads, and starts your app. Hopefully those keywords are enough that you can google-fu your way to a successful app launch.
But what language do I pick?
It's going to turn out that it doesn't matter. I don't care. A lot of front-end development is going to a MEAN stack (MongoDB, Express JS, Angular JS, and NodeJS), though there are still some tried-and-true apps running on the LAMP (Linux, apache, Mysql, and PHP) stack. Pick your poison. Because the exposed bits will be accessed from HTTP, we can define our application to look the same on the outside, despite having different technologies backing it up.
The Challenge
At this point, it's time to try. Getting all of this tooling up and running is a significant hurdle in the project process. And you'll learn lots. Actually, I'd encourage you, after getting a successful "hello world" in one system, to do it on the other. You might be surprised at how much conceptual overlap there is. Again, at this point, it doesn't matter what stack you pick. And you definitely won't use all of the pieces (no database is required for a simple "hello world" to display on your page).
Thinking ahead
If we think a second on how we deployed to the web (via a git push command), it's obvious that we could push to other locations with a similar command. Once the app gets more complex, you may want to do that so that you can add new features in a "sandbox" while having your live system running. Those essentially "test" and "prod" environments. And if you start working with other people, those will become critical as a means to add new features & collaborate without risking production system stability. Yeah... I think we're on to something...
