OSD600 Lab 1 - Working with a partner to review an ssg

For my first lab in my open-source course, I was tasked with working with a partner to review each other's implementations of our first project. The project was to create a static site generator which takes text files and converts them to html files.

I decided to use Rust for my ssg and communicated with my other people in my course using slack to find my partner, Artem, who had decided to use Go for their ssg.

I had never used Go or reviewed someone else's code, so I was a bit confused on where to begin. Apart from reviewing documentation, I decided that the best thing to do would be to test the features of the program and then try to find ways to break things (which was quite enjoyable). I found a few minor issues with their code, mostly related to how error messages were handled:

• Missing information in Readme file
  The program had a help message (if run with the -h flag), which had useful information about the usage options. However, this option was missing from the Readme file.

• Program deleted previous output files if the program was run with an non txt file
  This happened when the user used the -i flag and specified a file which wasn't a text(.txt) file. This caused the previously generated files to get deleted.

• Help message did not account for all terminals
  The documentation mentioned running the program using the ssgo [OPTION] command. I found that if the user is using powershell or git bash, this would fail. They would have to run it like this instead: ./ssgo [OPTION].

• Inconsistent help messages
  I found that if an invalid flag such as ./ssgo -test was used, it would print out a different help message than what would be printed with the help flag ./ssgo --help.

• Certain invalid flags would pass as valid flags
  Flags starting with '-i' such as ./ssgo -info which is clearly invalid would not be marked as invalid. Instead, this would result in the program thinking that the flag was '-i' and the input path was 'nfo'.

• Minor code formatting issues
  I found a few redundant blank lines and missing spaces in the code, which made it slightly harder to read.

I was quite used to having someone review my code as I had completed a few internships in the past. Though I was surprised to find that I had missed a major bug in my program. The following issues were filed on my repo:

• Missing feature information in readme
  I had not included information about the features of the app, such as the fact that it automatically adds <p> tags to the html file based on blank lines in the text file.

• Missing logging info
  While running my ssg, there would be no indication of what is happening. The user cannot know what stage of generation the ssg is currently on.

• Html generation fails if program is run from another directory
  This is the major bug that I missed. I have a html template file which get read to generate the final html file. However, if the current directory from which the program is run is anything other than the program's directory, it can't find the html file and aborts.

• Adding optional features
  For our project, we are tasked to add two optional features out of a list of features. I have not yet implemented these features.

• Displaying static data from a variable
  I print out a string when displaying the version of the ssg. It would be better to use a variable to store this data. That would make it easier to modify the version if it is repeated in multiple places in the project.

As of writing this post, I have not yet fixed these issues. Since I had never used Rust before, it took me longer than I expected to get a basic working version of my ssg finished. Therefore, I am planning on tackling the issues in next couple of days.

Throughout this process of testing and reviewing, I learned the importance of collaboration and review. I learned a bit about Go, which I had not used before. I also discovered a major bug in my program early in the development. It was also fun to try to find ways to break a program.