We are officially in the thick of Unit 2. In two short weeks, we LC101 students have gone from building a static webpage (I made this one!) to a responsive web application (a web page that can do stuff).
I personally loved the front-end stuff we were doing. I’ve gotten some training-wheels practice with CSS through this very blog, but it was fun designing a page from scratch.
We did a quick pivot this week to back-end skills (specifically learning Flask), which – ugh. Back we go to mathy tech land. We were warned by our teachers that the transition to Unit 2 could be rough, and I think this is why: a lot of it is snore-inducingly boring. (Though maybe just to me!)
Because the back-end does less than inspire me, I wrote this study guide to make me learn this stuff and also gift myself a cheat sheet. Maybe it’ll help you get through Unit 2 as well.
Selecting elements within elements (within classes within ids)
You don’t need to be designing a very complicated website at all (witness mine above) before you realize you need to be able to target sub-elements in your HTML (and sometimes sub-elements of your sub-elements).
There are a lot of different ways to specify elements in your CSS and many of them look similar, which makes the rules hard to remember. Plus, I haven’t found a cheat sheet I really like. Even these aren’t great. So, I used CodePen to make my own. Find it here.
Add, commit, push
LaunchCode’s materials do a good job of walking us through version control using Git (they had us read big chunks of this awesome online book). But I still haven’t memorized a lot of the commands yet (again, they’re all pretty similar to each other) and whenever I forget how to commit, I have to go hunting through the homework for the instructions. So, all in one place, here are the basic Git commands and workflow (for static web pages, not responsive applications).
1. Before we can start a project, we need to make it a place to live. A lil’ directory home. Making one is easy, but I always forget to then navigate into that folder, which is important:
“lc101” appears before my commands because I had already navigated into my lc101 folder, which is where we’ve been doing our schoolwork.
2. Now, create a file within your folder using the “touch” command:
3. Before I can write any fancy HTML stuff in my fancy folder, I should create a local git repository for the fancy project:
Now I have a directory where I can “commit” (more on that later) changes I make in my code — but they’re all saved locally, aka on my own computer. For even more security, I need to make an online repository as well. Which requires…
4. Making a Github account! All the cool kids have one. Here’s mine. Making a new repository in it looks like this:
Now it’s just a matter of linking up your local repository with the online one. Copy the link Github gives you after creating the online repo and head back to Terminal:
Before I wrote all these steps out, I didn’t realize just how much housekeeping there is to do before you can get to…
3. The good stuff! Write some sophisticated code, like this:
4. When you’ve completed “a chunk” (the computer scientist’s official unit of progress), save it in your editor. (Back we go to version control housekeeping.)
5. Check the status of your project’s “version” in Terminal (or whatever the heck it’s called in Microsoft), to make sure your changes are reflected (they’re in red):
6. Git Add. This puts your changes in a queue or a clipboard or something. This is called “staging.” Why is staging necessary? Here’s the best explanation I could find. Basically, it’s because you may not want to commit all your files. It also allows you to keep changes in separate commits if you want. (Maybe you want to write one commit message for the changes you made to your HTML and a separate one for CSS changes).
7. Git commit. (If only we could use this command on boyfriends – ladies, amiriiiiiiight). This updates the version of your project in your local git repository. Write a handy dandy message to explain what you’ve changed since your last commit:
8. Git push. This final step makes sure all the changes in your local commit are included in your Github repository.
Make a virtual environment
You’ll need to start doing your work within a virtual environment when you move into making web applications (in our case, by using Flask).
I couldn’t tell you what a virtual environment is because I probably skimmed that reading assignment. But I can tell you that, from what I gather, it’s important to use a virtual environment — the poetic venv — because if you don’t you might break your computer so completely that it’s not even salvageable for metal scrap. (Or, maybe it’ll just cause problems between different versions of Python when you install Flask. Something like this.)
You don’t need to know the nitty gritty on venvs to know how to make one. It’s actually pretty simple.
So, in LC101 we use Conda to create virtual environments, though I gather there are several other environment management systems you can use. Conda’s commands are straightforward:
And to activate the fancy venv:
You know it worked if the name of you fancy environment appears in parentheses at the start of the line. It’s just as easy to deactivate the environment:
The bare bones internet/HTTP stuff
We are assigned a lot of reading on how the internet works. It’s drier than a bad web development joke: Why did the web developer drown? She didn’t know if she should float:left or float:right.
Glad that’s done.
Let’s make the executive decision that we don’t need to remember that URL stands for Uniform Resource Locator and get to the meaty stuff.
Here’s a basic diagram of a URL:
When there’s a “?” on the end of the URL, that’s a query parameter. When you see it, you know that the site has sent a GET request to a server (more on that later). After the question mark you get a name, an equals sign, and a value (and sometimes several of each of those).
You can also have a fragment, which is denoted with a “#.” It usually references a specific part of a page, and has nothing to do with the server. It comes after queries:
Here’s the idea of HTTP:
Hyper Text Transfer Protocol tells your computer what path it should take to get information from a server. And, as Forrest Gump says, that’s all I’ll say…about that.
GET and POST requests
GET is the most common method browsers (aka clients) use for getting information from a server. Examples include your computer making a GET request for a certain Forrest Gump gif.
POST is the second most common method, typically used to send information to a server. It’s also used to protect sensitive data: if you POST a credit card number, you don’t want it showing up as a query parameter in your URL bar for anyone to see. POST requests aren’t cached and don’t remain in your history.
If you want to read more about HTTP methods, this article we were assigned is nice and straightforward.
And to see this stuff in action, here’s a snippet of one of the projects we’ve done in class:
Conclusion
It wasn’t until I started writing all of this out that I realize the sheer volume of ground we’ve covered in two weeks. It is a bit of a shock to the system. The good thing about doing both front and back-end in such a short span is that there’s something to keep everyone interested.
I’ll probably come back to this post and spruce it up when I have a bit of a better handle on everything — especially those GET and POST requests and how to write them…I’m definitely still learning.
Onwards and upwards, I suppose.
Andie from KC 