Behind already

It’s finally week 1 of the PreCourse (click here to find out more about the PreCourse).  Good news is that I made it back to my London flat late Thursday evening.  Bad news is that it was the Friday of that same week (i.e. the day after I landed back in the UK) before I could get to work (as I didn’t take my MacBook backpacking in Nepal for fear of losing it).  That meant I was already mahoosively behind schedule before I’d even begun! Eeek!

Becoming a slacker

First things first.  The cohort were all invited to sign up to Slack and join the Makers Academy channels.  For those not in the know, Slack is a communications platform for co-working and collaboration.  It’s very popular in the tech world and the main mode of communication between Makers Academy students and between them and Makers Academy.  If you’ve not heard of it before, imagine what would happen if your work replaced email with Whatsapp and you’ve kinda understood it.

20150210005716!Slack_Icon.png

Strangely enough I randomly started using Slack prior to the PreCourse to organise the making of a short film for the Sci-Fi London Film Festival‘s 48 hour film challenge that I co-produced and starred in… well I had a Hitchcockian cameo but I did co-produce!

Parker’s Son: In case you’re curious, here’s the link to our entry, “Parker’s Son“, and its IMdB page.

Anyway… Slack has proven to be a great tool for sharing suggestions on how to tackle the challenges set for us in week 1 of the PreCourse.  It’s also been great for arranging to meet up to pair program or share screens remotely using Screenhero, which incidentally is now part and parcel with Slack.

b76636cb-6f61-4cb9-886e-325c1f88bf5a

Week 1, Part 1: Command Line 101

What I learnt:

  1. What the command line is: it’s how we interact with the underlying code of our computer directly.  It’s the scary green/white text on black background you sometimes see IT support using at work to fix your computer.  It’s also what you will have inevitably and anxiously used when trying to fix your wi-fi by running an ipconfig command.79a33ab83a8700c7e9fbebccbe50327c6e2833234cdb8285257af0209ef86e93.jpg
  2. Navigation: how to navigate throughout your computer’s directories using PWD to show the current directory, LS to show the files and subdirectories in that directory, CD and CD.. to navigate to a specific directory or the parent directory respectively, together with some more complex commands and additional parameters (basically additional instructions to filter or find certain types of files and/or folders) to reveal specific or hidden files and folders etc.
  3. Brahma, Vishnu and Shiva: commands to create, operate destroy files and folders such as mkdir, rmdir and those to move/copy files and folders, such as mv.
  4. CATs not kittens: using CAT to open and concatenate (geek speak for “combine”) files, together with less and tail to select the start and end of files.
  5. Vimto: using VIM to edit files via Command Line command vi.  Essentially a super unsexy version of text editor.68747470733a2f2f646368746d36723437316d75692e636c6f756466726f6e742e6e65742f6861636b7061642e636f6d5f6f3657326f6751593858635f702e35323536375f313338313136313634343635315f53637265656e25323053686f74253230323031332d31302d3037253230617425323031372e.png
  6. Wild thing: integrating wildcards to search for all files fitting a certain pattern, e.g. ls *.txt will list all files ending with a .txt extension in the current directory – handy eh?
  7. Getting to greps with it: deploying grep commands to find information inside files (unlike find and wildcards, which help us display certain files but not their contents).  I quickly learnt that grep, when combined with || (known as “pipes”) can be super useful as it allows you to pipe (i.e. redirect) the output of one command to another.  For instance, you can search for all files fitting a certain description and pipe their contents into a new file – handy if you’re trying to solve a murder mystery… more of that later!

Week 1, Part 2: Git, Github and Version Control

The second part of week 1 is about getting to know Git and Github, two super useful tools that help you track, manage, collaborate and contribute to different versions of code.  If you want to check out my Github and follow my coding progress, click here.

We covered all the essentials, including but not limited to:

  1. Git set-up: how to set up and initialise Git via the command line.  It makes sure it’s all set up on your machine and ready to go.
  2. Creating our first repository: using command line to create a local git repository, i.e. somewhere on the computer to store the tracked changes of code files.
  3. Staging: this is the process of telling the computer which files we want it to make a mental note of in case we want to come back to them later.
  4. Commiting: this is the actual commit to memory, i.e. the step where we say “OK computer, those files I told you to remember, well you need to make sure you remember them.  Got that? Ok, great”.
  5. Git Status: nowhere near as self-involved as your Facebook status, this simply checks what files you’ve modified, what ones you’ve told the compute to remember (i.e. those files you staged) and those already committed to memory.
  6. Git Push: this is the final step whereby we push the files to our Github repository, basically a cloud based version of what we have stored on our machine locally.
  7. Time travelling: learning how to travel back and forth in time between different versions of files using git and command line.  I’ve also learnt how to remove and/or revise commits and Pull Requests on GitHub. back-to-the-future-delorean.jpg
  8. Github: as noted above, Github is essentially a cloud based storage platform for code.  It allows people to remotely save, share and collaborate with code.  It’s also your CV – it can be used to show off your coding abilities by hosting your best code.
  9. Pulling: no, not the kind you do on a night out with the lads… sadly this is less sexy but nonetheless critical to a developer.  It’s how you get code back from Github, e.g. if the stuff on your local machine goes wrong you can pull the equivalent code from Github (provided you previously pushed it to Github of course!) so you have it again to work with on your local machine.
  10. Pull Requests: again, nothing to do with asking out members of the opposite sex.  It’s simply how you submit your work on a particular code project to those managing the overall codebase.  Those persons can assess your code and decide whether or not to incorporate, or merge, it into the master version.

Here’s a handy diagram summarising how Git and Github version control works:

git_everthing_is_local.png

Week 1: Challenge – The Command Line Murder Mystery

At the end of week 1 there was a MURDER.  No, it wasn’t one of my cohort.  Jeez, who do you think Makers Academy admits? The murder was part of an interactive exercise we were asked to complete using only the command line.

tumblr_inline_mvjdmlENBM1rzl7da.png


Step 1

First we had to use our Git/Github skills to fork a repo to our Github page (see mine here), clone the repo (i.e. save a local version) to our computers and begin investigating the files via the command line.


Step 2

Next we had to get down and dirty and flex our command line skills.  To begin we had to navigate to and open the instructions, then the constituent files for each step in the mystery.

Each of those files contained clues and instructions as to what we needed to look for.  For instance, we had to inspect a certain directory of files then find a way of using command line commands to search for “clues” and output those clues to a new file.  Using the results of that exercise we had clues to further our search for witnesses.

Continuing the theme, further commands were needed to extricate witness information and narrow down the search to a couple of witnesses and then, by extension, potential suspects.


Step 3

At the end of each step (there were 9 in total) we had to add (i.e. stage), commit and push our clues files, evidence, witnesses and suspects etc to github.  This was an exercise in itself and reinforced what we’d learnt through the Makers Academy materials on git and github.


Solving my first murder mystery

Eventually I found the murderer, ran a final command which checked my suspect’s name against the answer and returned the reassuring message below. All in all I enjoyed this exercise rather too much.

GREAT WORK, GUMSHOE.

Stacking it

The Command Line Murder Mystery was also involved my first foray into StackOverflow.  StackOverflow is a hugely helpful online portal for questions and answers relating to code and computing.  so-logo.png

Basically you post a specific question and other users post answers.  Better answers get voted up and worse ones get voted down.  The end result ensures better pairing of answers to questions.  It proved invaluable for researching how best to combine commands to quickly and efficiently complete each step in the Command Line Murder Mystery.

How I felt at the end of week 1

The end result of week 1 of the PreCourse was something like the below.  I literally felt like Neo from The Matrix: the very guy who had inspired my passion for tech all those years ago when I was a chubby little pseudo goth-geek.

64225164.jpg

Advertisements