Week 1 10/04/2015
In the first week of Dev Bootcamp, we were introduced to using the command line interface for communicating with our computers. We were also introduced to version control using git and hosting our projects on GitHub. I want to explain what I learned this week.
Why learn the command line interface?
If you have never used a computer before the 1990s, then the command line interface (cli) will appear to be an anachronism. Most computers come with a GUI (graphical user interface) that gives you a nice visualization of your file/directory structure. If you want to move a file from one directory to another, you usually just drag and drop. Similarly, if you want to rename a file, you just right-click and type in a new name. Why would you want to type in 'mv new-directory/ file-name'? The answer is that you can accomplish this with one line of text, whereas for dragging and dropping, you have to (i) right click on the file and hold it while (ii) dragging it to the new folder (and hope you don't release the right mouse button) until (iii) you reach the destination folder (which may be off-screen) when you may release the right mouse button. Compare typing one line of text, with three mouse-actions. If you are a casual user of your computer, then it probably doesn't matter. Do what's more convenient. However, if you are a developer or a data scientist who has to deal with many (hundreds of) files, then using your mouse to manipulate each file is not feasible. This is where the cli becomes your new best friend. You can use the cli to write scripts that will automate tasks such as the ones described. A few other advantages of the cli over GUIs include: searching through files using regular expressions (as opposed to having to open and inspect files), redirecting output of programs into files (as opposed to only seeing out on your screen), and not having to learn a new cli when switching computers or operating systems (whereas each new version of an operating system may come with a new GUI that initially takes some getting used to). There are other advantages, but I am still new to this environment so I have not learned enough to appreciate them yet.
Why learn Git?
We learn Git to enable version control. Imagine that you are a conscientious programmer. You have a program that works as intended, but want to add some enhancements. As a conscientious programmer, you would make a backup copy of the current file and then proceed to change the working copy. Suppose, you've made an enhancement and it works as intended. Great! Go ahead and make a new backup copy of your file and add another enhancement. Keep doing this until you're done. You have exerted a lot of energy devoted to keeping your file intact. Now suppose your program has a catastrophic bug due to one of these modifications. Did you cleverly name each new file so that you know exactly which file to revert back to, to undo this bug (or better yet, were you disciplined enough to maintain a README file detailing the changes made in each updated file)? This where Git can help.
With Git, you can easily save multiple versions of your file (by 'adding' and 'committing'). One of the benefits of committing is that you include a short message describing any changes you've made. These 'commits' are kept in a git log. If you need to restore an earlier version of the file, you can do so with a simple command - no need to take time to create backup copies of your files. Another benefit of the log, is that you can track changes made to the file without having to maintain a separate README file.
Why use GitHub to store your code?
Imagine that you are collaborating on a project with several other developers. What happens if you and someone else have made changes to (copies of) the same file. How do you reconcile the conflicting changes? How do you merge these into one clean file? This where GitHub comes too the rescue. GitHub is a site that hosts your project files. You and your collaborators can 'clone' a copy of the 'master' project (stored on GitHub) to your local machine. Once there, you may freely experiment with and modify the project code without fear of damaging the working 'master' copy stored on GitHub. When you are ready, you 'commit' your revisions to GitHub. If there are any conflicts between your files and another collaborator's, you can compare the differences and come to an agreement as to how to merge the files. These then can be merged into the master project.