Homework for 6A

← 5B Home Slides 6B →

Review

Topics Covered: How the internet works, Rails scaffold

Office hours Exit tickets

Exercises

This morning's exercises will be a bit more conceptual in nature, and review some of the topics we covered last week. They also present a way to practice git, and get use set up for code reviews, which will help others give you feedback on your code.

E1: Git Research

Make the directory d6 in ixperience. In there, create a file called d6_answers.txt. Using Google and your brain, ponder the following questions and write your answers down. The questions build off of what we've already learned in class, and you will be submitting your responses—not so teachers can grade you, but so they can gauge how clearly they are introducing the material.

  1. What does the git init command do?
  2. What does git add do? How is it different from git commit?
  3. What is the difference between staged and committed (or versioned) files?
  4. What's the shortcut for adding all files and commiting them?
  5. How do you unstage a staged file? How do you go back to an old version of a committed file?
  6. Why are commit messages very important?
  7. How do I revert to a previous commit (i.e. go back to an earlier "draft")?
  8. How do you exit out of vi? (Also called vim.)

Hover for answer

1. Starts a new git repository. Specifically, it creates a `.git` folder (which is hidden by default so you can't see it in Finder) that stores all your git data. 2. `git add` _stages_ the specified files. `git commit` _commits_ those files (add all the staged files to the repo). This gives you flexibility so you don't have to add all the files in your working tree to the reposity—though in the vast majority of cases, that's what you'll do. 3. Staged files are ready to be committed, but aren't in the repository yet. Committing actually adds it to the repo. You might stage something if you've worked on it for a bit, but aren't sure enough of your changes to commit quite yet. **You will rarely stage something without committing it**. 4. `git commit -am "Your commit message"`—a **very** useful command. 5. To unstage, use `git reset`. To revert to an earlier version, use `git checkout`. 6. They describe what was done in the commit—having good messages makes it easy to go back to a particular "draft" of your app. 7. First use `git log` to get the **commit hash** for the commit you want to get back to. The output of `git log` should look something like: commit 2f10cb58b852b4b2fe6b6f22a4e24594cf1faafd Author: Rafi Khan Date: Thu Jun 12 14:53:28 2014 +0200 undo git rebase typo fix commit 0d3751aeded09576b3a58174d84870313aa27840 Author: Rafi Khan Date: Thu Jun 12 14:52:57 2014 +0200 git rebase typo fix The commit hash is that long `2f10cb58b852b4b2fe6b6f22a4e24594cf1faafd` thing after the word "commit". Then you would run `git revert 2f10cb58b852b4b2fe6b6f22a4e24594cf1faafd`. 8. Hold shift and press 'Z' twice, or type colon, then w, then q.

E2: GitHub Research

  1. What's the difference between GitHub and git? Could git exist without GitHub? Could GitHub exist without git?
  2. Why is GitHub a cool company?
  3. What does git push do?
  4. What does git pull do? How is it different from/same as git fetch and git merge?

Hover for answer

1. Git is the version control system that you have installed on your local computer. GitHub is a website that makes collaborating with git very easy, in particular looking at the code other programmers have written. Git could exist without GitHub, but not the other way around. 2. They let you put all your code online, for free! But letting people share code so easily, they make solving common problems _super_ easy, as well as pushing forward the open-source community. 3. Sends your code to the **remote** you specify. For our purposes, our remote is always called **origin**, and lives on GitHub. 4. `git pull` brings code in from the remote you specify, and merges it into your working tree automatically. `git fetch` brings in the code from the remote, but doesn't merge. `git merge` then allows you to merge manually. **Usually, you'll just use git pull**.

E3: Push Push Push!

Now that you know how to create Github repos, the next step is to add all of your homeworks so far to your Github repository. Follow these instructions:

  1. Go to github.com and create a new repository. Call it <first name>.<lastname>.<github username>. For example, Rafi Khan would create Rafi.Khan.khanotations.
  2. cd into your ixperience directory—this is where you have the folders exercises and projects. Don't worry if your folders are not structured properly, just make sure to be in the directory that contains all of your work so far.
  3. git init, git add . and git commit -m with a meaningful commit message.
  4. Add a remote for the repo you just created. For the example above, the command would be git remote add origin https://github.com/khanotations/Rafi.Khan.khanotations.git
  5. git push origin master
  6. Verify that all your code is in the Github repo you just created. Email the link to rafi@ixperience.co.za and salman@ixperience.co.za with the subject "Exercises repo for <first name> <last name> (<Github username>)"

E4: What's the Internet again?

Write down, step by step, what happens between the time you press enter in the URL bar in your browser and before you see a page on your screen. In particular, make sure you cover these questions in your steps (but you should have many steps in addition to the answers to these questions).

  1. What is a request?
  2. What is making the request?
  3. Where does the request go (like physically, on Earth, as well as conceptually, on the internet)? What's its "address"?
  4. What happens to the request when it gets "there"?
  5. What comes back? What is it? What data does it contain?
  6. What happens when it comes back?

Hover for answer

1. A request is some data sent over the internet from one computer to another to **ask for data**. When using the internet, most of your requests ask for HTML. But sometimes, like when using APIs, it might ask for other types of data, like JSON. 2. The client, or web browser (Chrome, Safari, Firefox, etc) makes the request. 3. The address is its IP address (something that looks like 185.31.18.133). That gets decoded, much like a street address, and the internet knows where that computer is. How? That's pretty complicated—if you're curious, you can do some Googling! 4. The request is processed by the server, which runs some code and returns data. 5. A _response_ is what comes back. The response usually contains HTML, but sometimes some other kinds of data (JSON, images, stylesheets, fonts...) 6. The browser processes it and renders it on your screen.

E5: Ruby Rocks

Go to iexperience.github.io/exercises/ruby_rocks. (This is not a valid URL, try it anyway!)

  1. What shows up on the screen?
  2. What does it mean?
  3. Why is the error it displays that particular number?
  4. Does this in fact mean that Ruby does not rock?

You may have to do some Googling.

Hover for answer

A big "This page does not exist" screen shows up, with the number 404\. 404 corresponds to a particular [_HTTP status code_](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). There are many, and each one tells the browser whether the request succeeded, failed, went to the wrong place, etc.

E6: Rails personal

Make your personal page render with Ruby on Rails. Your steps might be something like:

$ cd ixperience/exercises/d6
$ rails new personal
...move files into the 'right' places
$ rails server # verify it works by visiting localhost:3000

If you did your website in Dash, then create a simple index.html and style.css and make the page show up—no need to recreate your entire website.

← 5B Home Slides 6B →