For lab 2, we were tasked with upgrading another student's Static Site Generator, while having other students work on upgrading our own Static Site Generator.
I actually had the benefit of having two fellow students working on my project, and in total they were able to add 3 additional features to my project!
Thanks to @neilan99 and @genne23v, my project now has the capability to parse Markdown files (as well as plain text files), and perform the proper markdown-to-html conversion on H1 headings, H2 headings, and embedded links.
For my updates, I updated @neilan99's project to also be able to parse Markdown files, as well as being able to convert Markdown bolded text (double asterisks enclosing a block of text) into HTML bolded tax (block of text surrounded by <strong>...</strong> tags).
The respective links are given below:
Neil's Pull Request For My Repo
Wonkeun's Pull Request For My Repo
In updating Neil's project for adding support for parsing bolded markdown text, I actually ran into a few issues.
At first, I wasn't sure how to determine if there was a valid line in the markdown file that had bolded text. I knew I had to utilize RegEx, however my RegEx skills are a little weak. Thankfully, I was able to find a StackOverflow post (here), which aided me in formulating my RegEx pattern. This I think is another benefit of the open source community, in that you can find how someone solved a similar issue to yours, and implement that solution to your specific problem.
I also learned how to find the string index values of where the match was found and ended, to be able to replace the asterisks with the <strong> HTML tags. However, what I didn't realize at first is that I would have to take into consideration that as I make replacements, I would have to compensate for the added string length with the index values. I was able to quickly rectify this by adding 13 (the additional characters added to the string by adding the <strong><\strong> tags, and removing the '**' characters), to each of the index positions as I made the replacements.
On my first PR, Neil brought up a good point that my documentation was a little lacking in explaining what the RegEx portion of my code was doing, so I was able to quickly add in my explanation, and have my first PR succeed!
As for the pull requests that I received for my project, I first reviewed Neil's pull request. I thought he did a really good job in adding Markdown support, and the ability to parse H1 headings. My only suggestion was a small one, in which he could shorten the code by removing duplicated sections. He quickly updated the PR to reflect this, and I was able to merge his changes into my main branch.
For Wonkeun's PR, I felt bad because I made him do a little work. As I merged Neil's changes into my repo, it caused conflicts with Wonkeun's changes, so I required him to update his code to be able to workaround the newly added changes (as he was originally working on my base code - before markdown support was added). He was also quickly able to make the changes, and I was able to successfully test his code and merge his changes into my main branch.
Testing and merging other people's code into my main branch really gave me the opportunity to learn more about how git branches work, as I was a little nervous about pulling changes onto my local machine. Thankfully, GitHub makes this easy, and provides you with the exact lines of commands that you need to be able to 1) Create a new branch to test the changes and 2) Merge the changes to the main branch once it has been confirmed to work.
Overall, I thought this lab was a great experience in learning how collaboration works with git. One question that I do have remaining is that as I saw in my case (when Wonkeun's code encountered conflicts due to Neil's changes), I wonder if there is a proper procedure for multiple people making changes to the same codebase at the same time, or if conflicts like these are inevitable.
Top comments (1)
Your code structure is well organized and easy to understand. I could work with joy!