Andela Bootcamp: Git and a few other things

“If you do not know the purpose of a thing. Then abuse is inevitable.”

Today, classes began with an overview of Andela’s mission and its expectations from us throughout the course of the camp. This could be summarized as passion, excellence, integrity, and collaboration. We were also reminded that the primary purpose of bootcamp was for selection and training and its aim was to solidify programming experience. Thus, Andela expects that we put in our best. During this talk, my approach changed from one who has come to take in from a teacher to one who would be proactive to learn as much as possible independently from resources, students and intructors. I intend to make use of all those smart brains located in one place.

Then we discussed the assignment of the previous day: How do we share code? I gleaned a lot from just listening to students share their knowledge. So basically, in a project requiring multiple programmers to work together, there is a need to share code just as university researchers share their papers. This way, higher quality code is shipped. However, problems arise when programmers work together on the same code. Someone could add a new feature and inadvertently damage the codebase. Solution to this problem came in the form of Version Control System (VCS).

VCS allows programmers to keep track of multiple versions of code based on time or user. VCS has three major type:

  1. Central — changes are tracked in a centralized server
  2. Localized — changes are tracked locally
  3. Distributed — changes are tracked locally and remotely

Distributed Version Control Systems (DVCS) are the most popularly used and are necessary because maintaining integrity in a code base among multiple programmers with different personalities could be challenging otherwise. DVCS make rolling back changes to data to an earlier time possible. Multiple branches separated from the main branch of the code could be created, worked on and only added to the main branch upon completion and testing. DVCS could also automate updating changes to server and enable continous integration (being able to test code before deployment).

Git was introduced as the most popular DVCS and the flavour we would be using at the bootcamp. We created accounts on Github: free code repository built on top of Git. Then we went on to use a free service for learning git operations — A fellow bootcamper shared — a simple guide to using git. I practiced with popular git operations such as:git init, git status, git add <filename>, git log, git commit -m “<comments>”, git reset, git checkout, git diff HEAD and git push.

When you create a local repository, you have nothing in it. Git checks the working directory to see if there are files that aren’t currently being monitored. These files you can view with git status command. To add a file to the staging area also known as index, you type in the git add <filename> command. The HEAD points to the last commit made and you need to type in the git commit -m “some comment “ command to move files from index to HEAD. Pushing files from HEAD to remote repository requires entering git push. This is after you have defined a remote repository for your data.

A lot more could be said about Git but this post is becoming too long. IF and ELSE statements and WHILE loops were introduced and examples shown. Since, I already knew the points treated, I would skip those for this post. Then we had a series of exercises given to us. That got the class excited since they could finally get their hands dirty. We were asked to write the popular fizzbuzz program, an is_prime function, print_str function, print_vowel function and a print consonants function. Then a challenge to write a program that calculates the largest prime factor of 600851475143 was given.

Finally, Object Oriented Programming was introduced to the class. It is a programming paradigm where data are represented as objects with attributes and behaviours. It’s key benefit is abstraction as it allows a user to easily use a program without understanding the underlying implementation. Programs following this approach typically provide interfaces for users to interact with. OOP approach is used in APIs, Interfaces, Sockets etc. The job of a Software Engineer is to model data and OOP provides an intuitive way to do it — akin to how we classify things in the real world.

There’s still much to write as I learnt a lot today. But I will stop here for now. Thank you for reading through.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.