After last week's contribution lab, this week, we are back to working on our own projects!

We were asked to implement two features, either from a select list or ones we come up with ourselves.

For my first feature, I chose to ensure proper exit codes are added in OptimizeIt and to print appropriate error messages to stderr whenever applicable.

For my second feature, I came up with the idea myself. While I’m proud of what I’ve created so far — optimizing any source code file provided — currently, files must be supplied one by one, which can be inconvenient. So, I decided to add a feature that allows OptimizeIt to parse an entire directory and optimize all the source code files it finds.

First Feature

This issue required me to review my code and identify where errors could be thrown. I focused on where I could provide proper error messages and exit with a status code of 1, indicating that an error has occurred. While many of these cases were already accounted for, I discovered several that were not!

I made sure to include try/catch blocks where necessary and print error messages to stderr whenever appropriate. I also realized that I should print Unable to process file to stderr since it is an error message and not normal output.

Second Feature

When I started working on this issue, I anticipated writing quite a bit of code to extract all file names from a directory, parse them one by one, and return an array of objects where each object would have a fileName and a Data property.

However, I realized that I had already structured my code in such a way that this wasn't necessary at all. Since each fileName was already being processed individually, this made my task much easier!

I only needed to add support for two new flags: -d and --dir, and create a single function to return all filenames in the given directory.

From there, my existing code took care of the rest! It was really satisfying to see that, when the code is structured well, adding features that might otherwise seem complex can actually be quite straightforward.

Merging

The goals of this week's lab were to practice merging, handle merge conflicts, identify commits on GitHub, and work on multiple code changes in parallel across separate branches.

Once I finished both of the issues mentioned above, I checked out the main branch and merged the branch for the first issue into main, which posed no problems at all.

Afterward, I merged the branch for the second issue into main, and surprisingly, there were no merge conflicts!

This is where I encountered my first hurdle. When I attempted to git push origin main, I was prompted to provide my GitHub Username and Password. However, this did not work. I double-checked my password, updated it, and re-entered it, but still, no luck.

Then, I noticed the following error:

remote: Support for password authentication was removed on August 13, 2021.

remote: Please see https://docs.github.com/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.

I Googled the error and learned that this old form of authentication has been deprecated. The new method is to use something called a Personal Access Token (PAT). This is a token that any GitHub user can generate with certain permissions. The token is used in place of the password in the password field!

So, I generated my token, used it in the password field, and voilà! I was able to push to main.

However, this led to another issue. The final task in the lab was to link the merge commits from each branch into main when closing the respective issues.

I realized that my first merge into main from the first issue's branch did not create a commit!

I raised this issue in the course's Slack channel and had a very insightful discussion with Professor Humphrey. Apparently, fast-forward merges don’t produce a merge commit; they simply update the branch to the new commit’s position. In contrast, 3-way merges leave the old branches and commits intact and create a third commit that links them.

After identifying the problem, I decided to close the first issue with the last commit to that branch, and the second issue with the merge commit to main!

Conclusion

This week's lab went much more smoothly than I expected. The only thing I would do differently next time is to carefully re-read my code and identify how a new feature might fit before I assume it will require a lot of work. That’s exactly what happened with my second issue — I thought it would be difficult, but it turned out to be much easier than I anticipated!