Makers Pre-Course — Week 1

A slightly dull, but comprehensive Learning Diary for Makers.

Day 1 — Monday 26th October

Feeling beginning of day: Excited/Nervous

Learnt within day:

• Familiarity with Makers online learning environment
• Got a sense of the workload and syllabus for pre-course
• Complete Dev Environment setup: Essential Tools (xcode, Homebrew, RVM & Ruby, Pry, Heroku) and Useful Tools (iTerm, atom, Vim, Chrome, gitbook)
• Introduction to problem solving

Feeling at end of day: satisfied/calm

Day 2 — Tuesday 27th October

Feeling at beginning of day: Happy

Learnt within day:

Command Line — Beginner

• Directory Navigation: print working directory (pwd), list files and directories (ls)
• Making directories (mkdir), deleting directories (rmdir)
• Making files (touch), copying files (cp), deleting files (rm)
• Moving and renaming files (mv)
• Creating larger.txt files in atom
• reading output of files within the terminal (cat, head, tail)

Command Line — Intermediate

• Streams: standard input (stdin), standard output (stdout), standard error (stderr)
• Piping of outputs to inputs (|)
• Regular expression search (grep)
• Reviewing output of files within the terminal (less)
• Word count (wc)
• Manual for command line (man)
• Permissions in files and folders: three classes; “user” (u), “group” (g), “other” (o) [and “all” (a)], with three permissions; “read” (r), “write” (w), “execute” (x).
• Changing permissions (chmod)

Feeling at end of day: Tired.

Day 3 — Wednesday 28th October

Feeling at beginning of day: unfocused

Learnt within day: Command Line — Advanced

• shebang! importance of defining the location of the correct interpreter for the script (#! /usr/bin/env ruby)
• Super User Mode: name of super user is “root”. Super user mode us very powerful as it overrides all permissions. Danger! (sudo)
• Environment: Environment variables or “env var” describe current terminal session (env). Each is a key value pair and can be interrogated from the terminal (echo $key)
• Path: path is a colon separated list of of directories the shell searches for programme files e.g. (echo $PATH)
• Setting Environment Variables: storing user created variables in the environment (export). e.g. for password storage.
• Profile variables: environment variables only last as long as the terminal session. Profile variables can be established that will re-created at every instance of a terminal session. (e.g. echo “export SEASON=winter” >> ~/.bash_profile)
• Processes: processes are programmes which are not yet complete. Terminal processes can be observed (ps) and whole system process can also be observed (ps x)
• Vim: graphical text editors, such as atom, may not always be appropriate or available. Vim is a native text editor accessible through the command line (vim). There are a whole array of commands to be able to be able to edit via insert mode.

UNIX

• Unix is an operating system => suite of programmes that make a computer work for servers, desktops and laptops.
• Variations: sun golaris, GNU/Linux, MacOSx
• 3 elements: kernel, shell and programmes.
• Kernel is the hub of the operating system allocates time, memory, handles filestore, and communications in response to system calls.
• Shell acts as an interface between the Kernel and the user. The shell is a command line interpreter.
• Programmes: everything in UNIX is either a file or a process. A process is an executing programme identified by the unique PID process identifier.
• Little additional nuggets: cd by itself returns to home directory. home is not the same as root. All command line inputs start with a command, not a file (hence the requirement for the < input operator). ^Z to suspend a foreground operation. ^C to kill a foreground operation. Can push a foreground operation to the background if it is taking a long time (bg).

Feeling at end of day: accomplished, but tired again.

Day 4 — Thursday 29th October

Feeling at beginning of day: determined

Learnt within day: Git & GitHub, met fellow students

• Version Control Introduction: version control supports both series and parallel working with the ability to “roll back”.
• Git — Setting Up: git comes as part of the Heroku toolbelt. establish basic configurations and settings (config)
• First Git Repository: git repositories need to be initialised (git init) and within the working directory. Any files in the working directory can be added to ‘staging’ (git add), and these stages can be committed (git commit -m “message”) to the repository (.git).
• Initialising a Git repository: git uses the .git file to track changes to the files in working directory. (for reference a git repository can be removed (rm -rf .git).
• Checking Status of git repository: good practice to get into the habit of running git status before and after any staging or commits (git status).
• Viewing log of changes: a log of commits is recorded and can be displayed in the terminal (git log)
• Removing files: git repo needs to be informed of deleted files as well as new or amend files (git rm filename).
• Going back in history: previous commits can be recovered if necessary (git checkout ##### with first 5 characters of unique hash). Imagine this as a branch, the latest commit is still the master. It is possible to return to the master (git checkout master) or merge (git merge)into the master.

GitHub

• GitHub: Github does three things: displays git repos visually, is a common place for open source projects, set of developer tools.
• Bootstrap and jQuery are examples of GitHub projects

You Are Your GitHub Profile! https://github.com/chriswhitehouse

• Use git and GitHub every project. Every time.
• Using GitHub: to use GitHub, a connection between the local git account and GitHub needs to be established through an SSH key and authentication with a passphrase.
• A ‘remote’ is a record of one local repository linked to distributed repository. [Q: Not clear if you need to establish a separate named remote for every project or not?]
• Git Workflow: 1. created a folder for a new project. 2. initialise a repository inside of it. 3. create some files 4. add them to the staging area. 5. commit them. 6. create a repo in GitHub. 7. create a remote pointing to GitHub. 8. pushed code to remote.
• Pulling Code from GitHub: if edits are made in GitHub, or pushed from another developer (git push), it possible to download these to your local git repo. (git pull)
• Version Control Best Practice: “Commit Early, Commit Often”. Bundle local commits for pushing to GitHub.
• File Organisation: seperate directory initialised as a git repo for every project. Within a ‘Projects’ folder.
• Cloning GitHub repositories: it’s possible to clone whole GitHub repositories (git clone url)

Check-in with Ara, Chris, Ollie, AJ, Will, Javi, Lisa, Chathal, Sarah, Luke, Natasha, Will, Simon, Irina, Sujeevanm, Kiki => collectively cohort November2020!

Feeling at end of day: a bit frazzled. And a few questions still to resolve.

Day 5 — Friday 30th October

Feeling at the beginning of the day: slightly anxious

Learnt within day: Murder Mystery Challenge

Who done it?

Bringing it all together for week one, was the first challenge; a murder mystery. Using GitHub, git and the command line to interrogate files, record findings, and ultimately found out who done it.

Very entertaining, and rewarding challenge. Started to build fluency, motor memory, and confidence with the command line in particular.

Specific learning points:

• Q from yesterday around remotes. Every local and remote repository pair will require a remote connection. It is convention for all the first remotes within a project to be named ‘origin’.
• git push -u origin master needs to be undertaken on each repo independently.
• .md is markdown file in plaintext
• shift-command-F5 for mac snippet tool
• using head and tail together to isolate one line is cool
• similarly chaining grep to filter multiple times.
• comparing commits (git diff)
• Need to spend more time with VIM.

Feeling at the end of the day: tired by satisfied to have completed the first challenge!