Grit

A couple of years ago I read a book called Grit by Angela Duckworth. I usually recall important lessons that I learned from the book when facing difficulties in learning something new. Grit is passion and perseverance for achieving long-term goals. It is about playing the long game in a world where our attention span is shrinking. Passion is remaining interested in one thing for years and perseverance is pushing through the plateaus in progress or setbacks. Passion is commonly found but endurance is rare. This is easier said than done, of course. But it is something I remind myself of all the time.

Now, why am I saying this? This week was a particularly difficult one for me. I had 4 big projects due – an Android mobile app, part of a microservice I am building for a cloud computing class, open-source development course projects, 30% completion of a browser-based cybersecurity game, and a robotics class exam. But then I reminded myself of grit. I reminded myself of the importance of consistent effort even when things seem difficult or when things get boring.

The Task

To add a new feature to palpatine which is an awesome static site generator written in C++ by Batuhan, I started by filing an issue. While I worked on his repo for adding this new feature, he worked on mine to add the same feature. Here are the detailed instructions for this week's lab.
Batuhan also worked on my repo for adding the –config feature for my static site generator, rwar, written in Python. These are awesome repos to check out!

This new feature was a particularly challenging one and required way longer than I ever imagined. In the process of adding the –config file I messed up the code many times. The CMake configurations were broken in the process and the dreaded yellow and red warning lines filled up my terminal. So, I reached out to the repo owner for collaboration and for help. Batuhan was kind enough to guide me through the process of importing the nlohmann/json library and helped me fix what I broke in CMake configurations. I, then, had to read a whole lot of documentation about the argparse module to come up with an idea on how to support the –config feature.

Learning Something New

After writing a little bit of code, I created a draft pull request. I continually pushed all my changes to the draft pull request until it was ready for review by the repo owner.

Reviewing and Testing Code via Remote

I got to learn about another interesting feature of GitHub today: Remotes.
It took me some time to get used to working with remotes. Initially, I was getting errors while trying to git add remote because I was not using the right branch names or repo URL. But I have made the mistake enough times, hopefully, to not repeat it.

When we are reviewing and testing a pull request, we often need to read the code and test the functionality locally. So, how can we work with a different repo without cloning it? Well, we can add a git remote. If our repo is being worked on by another person, we can get the name of their fork and the name of the branch they are working on. Next, we can add them as a remote to our local repo:

git remote add <name-of-remote> <https://git-url-of-other-person-fork.git>

The https://...git URL is the same one we use to clone this repo. We can name the remote anything we want.

Next, I did a git fetch.

$ git fetch <name-of-remote>

This downloaded all the commits and branches in the remote repo to my local repo but did not merge anything. Everything they had in their repo is now copied to my git repo.

Next, I set up a tracking branch in my local repo, so I could track the work on their branch.

$ git checkout -b <branch-name> <name-of-remote>/<branch-name>

Final Step

After I reviewed my partner's code and my partner reviewed mine, we merged the pull requests. We were both satisfied with the final implementation. Yes, there were some hiccups on my end while implementing the feature but I learned a lot in the process. Communication throughout the implementation of the code was key to making this work.

Useful Links