Planet CDOT (Telescope)

Sunday, September 19, 2021

Duc Bui Manh

Code Review time

Lab 1 is a great chance to collaborate with others, review people’s code, and let people find bugs in your program.

My partner for this lab is Gerardo as I was looking for someone writing the project in Rust.

Issues in my project

My partner issued 5 issues which I fixed 4 soon after.

  • Cannot run project with ts-node: I fixed this issue by adding an instruction on how to set the environment in which the program runs.
  • Unclear error message when entering nonexistent file name: Gerardo suggested better error messages like No such file or directory would be clearer than 'fileName' is either a file or directory.
  • Title and h1 empty when title in input file is not found: My approach to title parsing is to look for the content before the first 2 blank lines and would render <title></title> if the title is not found. As it turned out, an empty <title> tag is not valid HTML. To fix this, I changed it to not include the title tag if it’s not found.
  • ‘false’ is inserted despite input file being valid: I mixed up this with React syntax, in React, if something is only rendered conditionally, we can write condition && <element>. However, in my program, if I do a string interpolation expression with the same syntax: `title && `<h1>${title}</h1>`, that would be evaluated to false because false (empty string) and true (not empty string) is false which results in ‘false’ string being inserted in the HTML. I fix this by changing the interpolation expression `title ?`<h1>${title}</h1> : ''`
  • Unfriendly error message when file does not have ‘read’ permissions: I think the error threw by JS if the file in not readable is already clear, so I wouldn’t want to handle that case specially.

Issues in partner’s project.

Gerardo hasn’t finished his project for release 0.1 when I reviewed his program, but I was able to find 3 issues.

  • Inconsistent spacing, and comma: When first opened Gerardo’s project, I immediately noticed some formatting issues related to spacing and coma. I went ahead and did a refactor with the help of VSCode’s Rust extension. I also suggested Gerardo to do the same but turned out he is running Emacs editor and he would use rustfmt and clippy to format the file.
  • Potential improvement: I found some areas in the code which could be improved, such as not including <br> at the end of every line, running one loop on the file list to achieve the same result.
  • Non-.txt files are also processed: I found out the project doesn’t handle the case where the input file is not a valid readable UTF-8 stream.


I have always loved fixing bugs. Going from finding what cause the bug and how to fix it is a good feeling. Thanks to Gerardo for finding bugs in my program that I didn’t know existed. I am also happy to help my partner find some issues to improve his project.

by Duc Bui Manh at Sun Sep 19 2021 07:05:46 GMT+0000 (Coordinated Universal Time)

James Mai

Surviving week 2: Mix feeling

Lab 2

I have an honor to work with Quiwen Yu for this week's lab. You guys can come an check out her amazing work at QuiwenTextHTMLPress. My impression when I was looking for a partner to review an open source project was very welcoming and enjoyable to be honest. The only problem will be finding people who using or known the programming language that you use for your project, such people would be able to tell you more about what you can improve on for your project. Otherwise finding a person to work and contribute into an open source project would have been the easiest thing for release 0.1.

It is not easy at all to review code in python. Luckily, I did have a chance to learn a bit basic about python and was surprising on how clear and straight forward python could be to do the same task. Qiwen also give me a clear direction on how to set up and install the dependencies needed for the project to run smoothly.

Issue 1: I found our that Qiwen did not handle the spaces correctly so leading to a small bug which treating the tittle the same way they would treat the rest of the content.

Issue 2: This is not a big issue but something will help the project as we move on. A link to the project will help the user have a quick look of the project and might discover some bug right away without having to take a look at the code

My repo's issue: Qiwen on the opposite did suggest me to improve my file to be more clear and give useful instruction on how to set up my project on other dev's computer. I did make a few change to my file and hope it become less vague to the contributor.

My project did post a challenge which I could not seem make it to process a folder that have space in the name. I would take a note on this and improve it as we move on. I did learn to communicate with other dev which a very crucial skill to improve on. Also, getting used to the testing and debugging procedure will help me to level up my game a lot.

My feeling

As the previous blog post, I did mention that I leave the deadline and did not start it 24 hours before the due date. I really did learn to work under pressure but I come to realize that my goal for now will not be working under pressure but try to learn and enhance my skills set as much as possible. To be honest, I feel lost and doubting myself for taking this program and this course for the whole period working on release 0.1 . But by the end of the day, I know that I'M the one to be flamed . I did not try to learn new skill during the summer and trying hard enough chasing this career. I will need to straighten myself starting next week.

I did have a chance to finish all the lecture this week and feeling like a git master already. My fear for git command line disappear and I actually have a really good understanding about git now and did not afraid to use the command line anymore.

From my own experience, good thing usually start off roughly but the result is deserving. LOOKING FORWARD TO PUSH MYSELF MORE !

by James Mai at Sun Sep 19 2021 05:15:55 GMT+0000 (Coordinated Universal Time)

Saturday, September 18, 2021

Gerardo Enrique Arriaga Rendon

Participating in Open Source

This is the first time that I have ever worked with open source tools to participate in and contribute to projects outside of my own.

This small assignment was being worked on simultaneously with the 0.1 release of our SSG tool. The assignment, in basic terms, asked us to let somebody review our code and file issues or PRs to the repo, and we should also do the same with that person's project, also hosted on GitHub.

Setting up

My professor helped us to sort ourselves out. I found my partner thanks to the professor's suggestion, as I was not looking for any particular project style.

My partner developed his SSG on TypeScript. This meant that I had to install Nodejs on my Linux laptop, which is not a big deal to do with a package manager. However, my package manager references to an old version of Nodejs, specifically Nodejs version 10. Of course, I had to install the precompiled binaries from the Nodejs website with the most updated version, which was a little bit of hassle.

After setting the project and installing TypeScript globally, I was set to test my partner's code. I went to his GitHub README, use his command and run it... only to have an error because the ts-node command cannot be found.

This was an error on my part. While I had installed the typescript compiler, I did not install the program that helps me to run typescript without having to transpile to JavaScript beforehand.

After that, I got on testing, which took more time than I thought it would. I had to write detailed enough issues on his GitHub repo so that he could reproduce the error on his part.

Filing Issues

I managed to file 5 issues:

  • Cannot run project with ts-node: this was the only issue that surprised me, since I did not know what ts-node was, and I was not sure if it was an issue with my environment or the project's. Turns out it was an error on my end, but the project maintainer updated the README to improve the documentation regarding ts-node being used as a command.
  • Unclear error message when entering nonexistent file name: this was an issue related to user experience. I wanted to try whether the program would detect that a file name did not reference an existent file, and, while it did, it did not display a proper message. After a while, though, my partner promptly changed it to a more understandable message.
  • Title and h1 empty when title in input file is not found: this issue was related to the option title feature that our professor prepared for us. When I entered a file without a title (that is, the first line is not followed by two lines), the project would display empty

    and elements. Since this was considered an invalid HTML file, my partner tweaked the implementation to not add such elements to the file in the case they were empty.
  • 'false' is inserted despite input file being valid: this issue was related to a mysterious 'false' string being added to the generated files. My partner fixed it soon after.
  • Unfriendly error message when file does not have 'read' permissions: this issue was somewhat tricky. Since you'd need to have a file that does not have permissions to read, it might be considered far-fetched to have such a situation at all. Thus, my partner disregarded it as unimportant for now.

Issues on my project

My partner also filed some issues:

  • Incosistent spacing, and comma: Some formatting issues related to my files. For some reason, my text editor's extension was not formatting my code properly, so I ended up formatting the file in a really inconsistent way. At the end, I filed an issue on my own to remind myself to add a pre-commit hook that would run a formatter and linter.
  • Potential improvement: Some discussion regarding the use of iterators. I would have to admit, iterators in Rust are very fitting in the unpredictable performance department. I have answered some of my partner's concerns, but I have not closed the issue yet, since I would like to research more on the iterator deal.
  • Non-.txt files are also processed: this issue was related to a bug I had where I was not filtering the files by their extension, and thus processing files that may or may not have a textual format.

While I could not fix all of the issues, I feel very accomplished with the progress I have made so far with only 4 issues filed in. I am very pleased that I could fix the issue with the filtering of the text files, although it took a while to fix since I was also implementing a feature for the project.

I learned that testing is super hard, and writing automated tests that could test for most of your features are indispensable. I also learned that productivity can increase if the tools that we work with can help us to be more organized and keep track of the progress we have.

by Gerardo Enrique Arriaga Rendon at Sat Sep 18 2021 07:11:16 GMT+0000 (Coordinated Universal Time)

Yassgy, release 0.1!

I am proud to announce the release of Yassgy, version 0.1!

I was working on this project for a week now, and after reading back and forth between the Rust official documentation, and community posts regarding Rust, I have finally developed a program that does more than print "Hello World!" on the screen!

Yassgy stands for "Yet Another Static Site Generator". This project was announced by my OSD600 professor, David Humphrey (@humphd on GitHub).

Right now, yassgy is deprived of features. It can do the least necessary to generate static files for a website, but it is much simpler than a Markdown parser.


Yassgy accepts as input a text file, and will output an HTML file, where it contains the text found in the original file. You may run it like this:

yassgy --input test.txt

Each group of lines found in the text file that are right after each other is considered a paragraph, and yassgy will consider them as such, thus, generating paragraph elements placed in the HTML file.

Also, yassgy accepts a path to a directory, which will be read for several other text files. See the following example command:

yassgy --input files/

Any other file type is ignored. Yassgy can also deep dive into a nested directory if there is any found inside, and keep the original directory hierarchy when outputting the generated files.

Yassgy will output all generated files and directories into a dist directory in the current directory. If there is already a dist directory, yassgy will delete it without warning, so beware!

Future Releases

Yassgy will still be receiving features. There are several other features that I could not implement due to time constraints or because I am not that knowledgeable in Rust.

Some features that I would like to implement are:

  • Markdown parser. Adding more formatting options with Markdown would be perfect to make the static site pages more interesting than simple paragraphs.
  • Default stylesheet. While the site is functional, it might be considered boring or even ugly using the agent stylesheet from your browser, so I would like to improve the look even for default sites by offering an opt-out default stylesheet.
  • Accepting stylesheets. Another interesting feature would be to let the user enter stylesheet link, whether they may be remotely linked or locally linked.


Even though yassgy is written Rust, performance is not given by default. While yassgy is moderately fast, I believe that it can be enhanced to be more efficient both processing and memory wise.

I will research more on this aspect, especially the memory usage aspect (imagine if the input file was around the GBs!), to improve yassgy's performance. I may rewrite some of its implementation, but as long as the behaviour is the same, it shall be fine.


That's pretty much yassgy's introduction to the real world! While it is not the best program in various aspects, I believe this is a big step for a first-timer like me, both in the Open Source world and in the Rust Language world.

by Gerardo Enrique Arriaga Rendon at Sat Sep 18 2021 05:31:58 GMT+0000 (Coordinated Universal Time)

Jiyun Jung

My First Open-Source Project With SSG


What is SSG? It is a acronym of Static Site Generator. It simply creates a static site that doesn't really need to be updated. So, I built a program that generates a html file that is created with a text file. Here is how it works.

How to run

  1. git clone [git address]
  2. redirect to a1-gss and enter "npm i"
  3. Open any terminal and Enter "npm i" and "node . -i [filename]" You'll see the new "dist" folder and a new HTML file that has a same name as the text file.
  4. Now, let's try the folder. Enter "node . -i [foldername]" You can also try other flags like -v, -h.


  • Commend-line flag
  • Identify title and content in a text file
  • Identify input weather if it is a file or folder
  • Generate HTML file(s) with a folder where new HTML file(s) is.


The first assignment of the open-source class is done! This task was about generating HTML file(s) from a text file(s). Unlike previous assignments, where instructions were mainly specific, I was slightly confused because I am not so used to this concept of assignment that is pretty flexible. I was lost at first in what language to choose and where to start. However, through this assignment, I spent a lot of time looking at many open sources and thinking about combining them with my code. In addition, by using a new library related to the command line, I felt that I was developing the skills I really needed in the working environment and taking a step closer to this field rather than doing a set school task.



My Github Repo

by Jiyun Jung at Sat Sep 18 2021 05:27:09 GMT+0000 (Coordinated Universal Time)

Diana Belokon

Breaking Code and Letting Others Break My Code

After I built the Glazed Donut, I had a wonderful opportunity to explore a similar project shinny-ssg by doing some testing and reviewing and get my glazed-donut tested as well.

Finding a partner:

I used Slack as a tool for communication to find a partner to review each other’s projects. I made a post asking if anyone was doing the project in the same language as me and one person replied. After that, I DMed Emily and yeah, we became partners.

Testing and Reviewing Code

This was my first time testing someone’s code and letting someone test my code from GitHub in public.

My Partner's Code

When I started testing the code, I felt like I was a hacker, trying to break someone else's code. I wanted to do whatever it takes to crash it. While trying to break it, I was also thinking about all the possible things to create chaos, but also sweating about my own project. Tons of thoughts have crossed my mind: “what if someone else will try to do the same to my code? Like an actual hacker? Will it break? How am I gonna approach it?”

Difficulties While Testing

When I was testing my partner’s code, it took me a while to understand whether the -i command was working or not, because it kept printing that the file name was invalid but at the same time on the line below it said that the result was in the ./dist folder. I went to the project folder but I didn’t see any folder named dist. It took me about 50 minutes to figure out where it was located. I almost gave up on trying to test it. I had to check all the folders before I could find it. So I suggested my partner to display helpful messages and maybe a full path to the dist folder, so the person knows exactly where to find the generated HTML files. Or maybe somehow place it in the project folder or something. It will improve the user experience a lot.

My Code Surviving My Partner

Knowing that someone will test my code, I just felt like I had this inner peace, that everything is going to be okay, and if not, someone is going to find the bug and you can fix it. It felt safe and relieving. There were some small bugs that I didn’t notice while testing my program by myself, so it was really nice that someone could point them out.


I Broke It:

While I was testing my partner’s code, there were a few small bugs that I found:

  1. Issue 1
  2. Issue 2
  3. Issue 3
  4. Issue 4

I would like to discuss a couple of them.

The first one was about invalid HTML markup. It was really surprising to me when I found this bug, because when I was testing the program, it did generate working HTML files and everything looked fine. Turns out it was actually missing <!DOCTYPE html> element and had a duplicate

element. You can read more about it here.

The second issue wasn’t a bug, it was more of a refactoring issue, but I still felt the need to file it.

The issue was that all the methods and some variables didn't follow C# naming conventions. For example, the methods were following camel casing:

void doSomething()
    //do something

Instead of pascal casing:

void DoSomething()
    //do something

While the program will still work even if you give it terrible variable names, it will affect a lot in the long run when it comes to maintainability and understanding the code. More details here.

First Issues Found On My Project

My partner managed to break my program to:D

  1. Issue 1
  2. Issue 2
  3. Issue 3

One of the issues was that I had some typos in my file. I just quickly fixed it and committed the changes.

Another issue was that I was forcing a break after each line in the paragraph, but instead I had to put a white space. It wasn’t hard to fix, just had to slightly change the value of the htmlBody.


htmlBody += $"

{p.Replace("\n", " ")}



htmlBody += $"<p>{p.Replace("\n", "<br/>")}</p>\n";

The last issue found by my partner was very witty and touching😆
Thank you, Emily🥰


I think that testing someone’s code is a good exercise to become a good Software Developer, because at that point, you become the most evil person in the world. You think about everything, even the things like putting a space between variables, name conventions, a typo - all sorts of nitpicks. I would intentionally forget something or use the command in the wrong way, just to see if I can break it. The thing is that only few people would perform this kind of torturing to their own code. Once something works, they stop trying. From this, I learned that if something works, it doesn't mean it is unbreakable. When developing your software, you should think of all possible ways to destroy it. Don’t stop the moment it starts working the way you intended it to.

Final Words

Overall, it was cool to be able experience this real open source life. I have experienced so much just with one project: creating a project, fixing bugs, getting a friend, testing code, filing issues, using git and GitHub, etc😎. I am so grateful to Emily for helping me so much in testing and reviewing<3 Without her my project wouldn't be as complete. I was so happy when she replied to me in Slack because we have shared some classes and I always had a good impression from her but we never got a chance to get to know each other. Albeit, this project made it happen:D. It was challenging and fun at the same time to explore each other's code!

by Diana Belokon at Sat Sep 18 2021 04:56:21 GMT+0000 (Coordinated Universal Time)

Glazed Donut: Release 0.1

Yay!! I finally have my own open source project😋🙈

Here is some intro to it:

Glazed Donut is a static website generator. Basically what it does it that it generates HTML files from text files.

You can view the project here.

Currently, it has the following features:

  1. It allows you to specify a URL to a CSS stylesheet of your choice that will be used to style the generated HTML files.
  2. You can specify a destination folder where you want your HTML files to be stored. By default, it will store it in the dist folder.
  3. Accepts a text file that will be converted to a static HTML page.
  4. Can convert multiple text files into HTML files at once if you provide a path to a folder with text files that you want to use.
  5. You can check program's version by typing -v or --version in the terminal.
  6. Displays a help message with the command usage instructions if you type -h or --help.

How to use it:

It is very easy to use it. You just have to follow the installation process provided in the

Then, you can do start playing around!

Example 1:

Firstly, you probably want to know what commands it supports.

go to the terminal and type this:




Once you've done it, you will see all the commands that are supported and their definitions, copyright, name and version of the software:

Example 2:

Scenario 1

Let's say you have a text file named page1.txt that's located in the C:\Users\You\Dir1 and you want to convert into an HTML page.

  1. Go to the terminal and type:

-i C:\Users\You\Dir1\page1.txt


--input C:\Users\You\Dir1\page1.txt

You will get a page1.html file generated in the dist folder (full path: C:\Users\UserName\glazed-donut\glazed-donut\bin\Debug\netcoreapp3.1\dist)

Scenario 2

What if you decided to go crazy and convert a bunch of files at once? You have now 4 text files you want to convert into HTML pages (page1.txt, page2.txt, page3.txt, page4.txt) that are located in the C:\Users\You\Dir2 folder. Suddenly, you want to also have them placed in the C:\Users\You\MyWebsite folder.

Here is how you can do it:

-i C:\Users\You\Dir2 -o C:\Users\You\MyWebsite


--input C:\Users\You\Dir2 --output C:\Users\You\MyWebsite

Now, you can find the generated HTML files (page1.html, page2.html, page3.html, page4.html) inside the MyWebsite Folder.

Example 3

You can also combine all the commands like -i, -o, and -s.

Imagine you have a Data folder with page1.txt and page2.txt and you want them to be styled with this stylesheet: and then placed under the StaticWebsite folder.

You would do the following:

-i C:\Users\You\Data -o C:\Users\StaticWebsite -s

Here you go, you now have 3 HTML files inside the StaticWebsite folder, styled with this CSS stylesheet.

Lastly, thanks to this awesome open source project, I didn't have to worry too much about implementing the command line parser😁

You are welcome to fork my project and use it or give any feedback! It is still in the process of development, so expect to have more exciting features coming up soon😊

by Diana Belokon at Sat Sep 18 2021 03:34:07 GMT+0000 (Coordinated Universal Time)

Amasia Nalbandian

Reviews, Issues, and Tissues.

This week in my open source class we had the opportunity to review classmates source code.

I did really well at not peaking and seeing other classmates code for the release0.1. However, this proved to be a weaker strategy. I ran into more issues by not reading about the issues and difficulties my peers faced. For example, I approached the CLI options completely differently than everyone else. Had I put myself forward and opened a discussion - i believe I would have saved much more time, and created better code to support the feature.

Reviewing my peers code was very interesting. There were similarities and differences in how we approached the task, coded, and used logic. Some of the issues with the program were already shared with me by the author. This made me realize that my peer had already tested their program thoroughly and were working towards fixing their issues. I went ahead and forked, cloned, and ran the program anyways.

I reviewed the code and noticed a lot of commented code - similar to mine. The comments were mainly console.logs to save the date and provide actual feedback to what was happening.

I went ahead and made an issue about this. I also submitted one about the readme which had some typos and could be refined. They can be found here:

I got reviewed by the same peer, and I had actually only posted a skeleton of my work. As you will see from my other blog... I had difficulties deciding an approach. Therefore many of the issues were actually resolved.

The whole process of reviewing was fairly fun as I was able to analyze and provide feedback where my code had strengths, but I also got feedback on where my code had weaknesses. This was a nice because there were some things that I actually did not take notice of. For a while I forgot to implement the output of an actual html file. I got worked up on the additional features - so seeing the issue there that there was no actual output reminded me!

by Amasia Nalbandian at Sat Sep 18 2021 04:01:10 GMT+0000 (Coordinated Universal Time)


Where do I start?

What I should have been asking myself was "WHEN do I start?"

Release0.1 has ensured that my summer vacation daze is over and that reality is setting back in... specifically the reality that programming takes more time than I think.

Approaching this project I have never made a CLI tool. I was sure this would be simple. However that's where I want to paste the following quote:
"Simplicity is the most difficult thing to secure in this world; it is the last limit of experience and the last effort of genius."

My first approach was to create a node file and use scripts to control what functions to run. Then I went to bash. Then I went back to nodejs. Then I was fed up half way and decided to do C++. I don't even finish looking up how to read a file before I say "Let's try Golang". Then I realize all of this is a horrible idea and go back to Nodejs. I see ONE typo that was crashing the whole program. I fix it. I work for 2 hours and get a lot done - I can do this. Suddenly everything starts going wrong...

This guide I was following to help me get started... It's not doing what I need it to. What?

I start to look through my project and I realize this was a horrible idea. Let's find the guide on "fs" and use that to write the code.

OK! Nice! It's working. Let's do the two implementations.

Uh-Oh! The command line options were not actually working this whole time.

The amount of sadness I felt was massive. I have to start all over... I take 10 minutes and I realize this is what It's going to be. I did not allocate enough time to test and ensure it's good. I start submitting the files on GitHub...

I look at some peers source codes to compare the methods we used. I realize there is a lot I understand now... There's so much I can do with the project once I fix the options feature. There's actually A LOT I can do.

I learned so much just by seeing some of the code from my peers. I think as a complete introvert, I will be stubborn when it comes time to collaborate, but we should have had more discussions. I should have made the time to open conversation. Why was I so stubborn?

by Amasia Nalbandian at Sat Sep 18 2021 03:44:47 GMT+0000 (Coordinated Universal Time)

Luigi Zaccagnini

Contributing to The Open Source Community!

Before I start this blog post I would like to thank the Dev team for shouting me out on Twitter! It meant a lot and I truly appreciate it! Now, welcome to my blog post about me contributing to another developers open source project and how you can possibly find a fun project to work on as well!

Finding a Project to Work on

I found this open source project by networking through my classes Slack to look for a partner. I ended up finding @drew5494 who was also writing a static site generator in C++. If you are looking for a project to work on, you should try finding one on GitHub Trending or you can try commenting your favourite open source project for others to find! I was a little nervous to test and review a project in a language that I don't program in very often but, nothing wrong with broadening your horizon! Open source should be filled with learning and fun so don’t be afraid to try new things.

Testing and Reviewing Code

To start, I had to do a little review of C++ so I could get a stronger understanding of the code. Once I had a grasp of the code I conducted some tests to see if the features would work or break under certain situations. I noticed that I found bugs/problems a lot faster than I usually would in my own code. This experience really showed me that not only is it important to have your code reviewed but, having a fresh brain while reviewing projects makes debugging and testing one million times easier! Best advice I have read within the tech community was “If you are stuck, go for a walk and try again” it will save you the ten hours of staring at a screen because of a typo.

Some problems I found while reviewing were:
*README didn’t contain tool features or examples
*The input flag did not work with directories
*The input flag work with text files only in the same directory of the executable

The Review On Octo

Getting my code reviewed was very scary at first. Putting your code out in the open can be daunting but, will help you improve your skills as a developer. The one issue that surprised me the most was the version flag not working. It surprised me not because of why it did not work but, why did it work on my machine? The problem was I had a string in my version variable in my package.json. I was able to fix it by just removing the string and creating a custom yargs statement. The only other issue reported on my project was adding liquid tag support to the tool. That feature was recommended on my previous blog post by @pandademic . Thanks a lot for the recommendation!


In the end, I have learned that testing and reviewing is imperative for the growth of a developer. Testing and reviewing helps developers learn new things, understand how to work with other developers and allows developers to try new things! What are some of your first issues you worked on in an open source project?

Here are the links to both repository issues:

by Luigi Zaccagnini at Sat Sep 18 2021 03:59:24 GMT+0000 (Coordinated Universal Time)

Antonio Bennett

Rust Static Site Generator (RSSG Release 0.1.0)

This assignment was assigned to us with the task of creating a static site generator using any language of choice. The tool converts files from txt format to html files. For this assignment I used Rust :)



By using the -v or --version flag the user is able to see the version of rssg


By using the -h or --help flag user is able to see help information


The program accepts inputs from the user using the -i or --input flag. Acceptable inputs are files and or folders


Output is stored in a current directory in folder named dist

Formated HTML

Paragraphs are outputted in a formatted and clean way

Title Substitution

By having the first line as title with 2 empty lines following. A title tag and h1 is generated automatically in the html output


is converted to



by Antonio Bennett at Sat Sep 18 2021 03:58:52 GMT+0000 (Coordinated Universal Time)

Jun Song

My first experience co-operate with other student in programming

Met Alex

During the SSG development through Release 0.1 in the OSD600 class, the professor gave me the role of working with one of my classmates and reviewing each other's code.

I checked Slack a little late, and while I was looking for a classmate to work with, I was kindly offered to work with Alex Romanova. As I am using the same language, Nodejs, I was very curious and happy, so I had high expectations.

Co-operate each other

Alex's api is called NODESSG, and it is very strongly appealing to itself what function and what language it operates in, and I was curious because it was very similar to my api.

The code brought me another unfamiliarity with my code, and it was a series of amazing experiences. But, very sadly, when both me and Alex ran each other's code, we found a bug where the html content was all in the h1 tag.

This was the biggest challenge for us among many other issues. This is because other problems can be quickly identified and solutions can be applied, but the problem is not easily solved. But, fortunately, my great colleague Alex gave us a clear answer to the problem, and fortunately we went beyond that and can focus on improving the task at hand.


In fact, I had a very arrogant thought that if I didn't find out, other students would probably not know, because I had never collaborated with other people before this class, so I had a very arrogant thought. However, through this collaboration, I felt the value of collaboration and the efficiency through collaboration of other collaborators. There is a lot to learn from others. But, unfortunately, I failed to understand and master all the code of my very good collaborator Alex. Because I've seldom done anything like that. However, this is also a valuable experience, so through continuous practice, I will further improve my skills in looking at other people's code and finding things to learn.

As a result, the collaboration was successful and I can say that Alex and I had an enjoyable and informative experience
(Alex right? (๑˃̵ᴗ˂̵)و).

by Jun Song at Sat Sep 18 2021 03:57:47 GMT+0000 (Coordinated Universal Time)

SSG for generating html

OSD600 feels like a subject that composes a program (?) on a specific topic by mobilizing everything that has been learned so far. In the first week, instructions were released to create release 0.1, and I tried to tailor the code as best as possible to the requirements of that list.

When creating the api, I chose node js, which I was most confident and used the most.

After that, I created a repository in Git and named it "jun-ssg" after me. :)

The SSG for text file!

Open Source Project 0.1

jun-ssg is a simple html generator. You can extract your file contents and put them as HTML content.

How to use?

Before start to use
After downloaded files delete the package-lock.json
run "npm install" at terminal
You can dowload and run the repository files -node src/app.js


can run by npm

npm i -g

Example statements

-i, --input Input a file or a directory [string] [required]

-o, --output Specify the output directory [string]

-s, --stylesheet Import css URL [string]

-v, --version Show version number [boolean]

-h, --help Show usage information [boolean]

Examples: After install my package, jun-ssg -i 'Silver Blaze.txt'


  1. Cloning my repository
  2. After complete the cloning terminal should show like this
  3. Change the dir location to the cloned folder
  4. Run "npm install" to use pre-set npm modules

  5. Try to run "node src/app.js" if everything is fine the terminal should show how to use this api.

  6. Type any command which is set, but in this case will run -input option type "node src/app.js -i 'Sherlock-Holmes-Selected-Stories'".

  7. You can check generated htmls.

  8. Also, you can apply any css stylesheet like this way.

  9. Then, you can see the htmls with nice design :)

  10. Text file what you wished.

My Github Repo

View the repo on Github.

by Jun Song at Sat Sep 18 2021 03:17:09 GMT+0000 (Coordinated Universal Time)

Emily Phan

Working together in Open Source Projects

The start

After finishing the features of my command line application tool shinny-ssg, I was working with Diana to cross-check the source code of our projects. In general, we have to check for bugs, suggest improvement, and file issues on Github.
We both use C# and .NetCore 3.1 to create the projects and therefore, the experience was quite exciting and I definitely learned a lot.
It is just a pleasure to work with Diana. I have known her previously from my database and web classese and knew that she is such a hard working and bright girl. In addition, Diana worked at the company which I am now doing the internship at. She has used C# for a long time and have great knowledge about it. This was very evident from her code.

The Process

I tested her application glazed-donut with all test cases and her code nailed it. All the features worked as expected and it generated appropriate messages to the users when there were any errors/exception. The only problem I could find about it is in generateHTML method , which she should have replaced the with white space. Other than that, just a few minor typos on the read me file, but nothing major.
When she reviewed my code and tested my app, I appreciated that she really spent the time to check every detail, giving me very sound advice and helped me file bugs which I did not find before.
First, she mentioned the naming convention in C# and explained in details the good practices in the industry. Second, she found a bug in my Page class which created an extra tag. Third, my exception handling was not good enough and she guided me to make it better.
In the end, I am able to fix most of the issues but I need more time to improve the code and make it flawless.

Final Thought

I really appreciated Diana for reviewing my code so thoroughly. I found that testing and reviewing code is great way to learn and improve your knowledge/code design.
Thank you :)

by Emily Phan at Sat Sep 18 2021 03:43:13 GMT+0000 (Coordinated Universal Time)

Shinny-ssg CLI Tool

This week, I have a chance to create a command line tool to generate an .html file or folder from .txt file. My tool's name is shinny-ssg and it was built with C#, .Net Core 3.1 and Command Line Utils.


  • generate .html files from .txt files with title
  • accept folder as input path to generate .html files in the destination folder which will has the same structure as original folder
  • give user the options to specify destination folder and/or stylesheet URL link


How to use

  • Download or clone the shinny-ssg folder to your local machine
  • Use command prompt navigate to the folder netcoreapp3.1 in the shinny-ssg folder ( path shinny-ssg\bin\Debug\netcoreapp3.1)
  • In the command prompt, run shinny-ssg.exe -h to see the options
  • The file will be generated in the shinny-ssg\bin\Debug\netcoreapp3.1\dist folder by default or in the destination folder if specified by user.


Source folder:

shinny-ssg.exe -i C:\Users\khoit\Desktop\OSD600\Sherlock-Holmes-Selected-Stories -o ../../Destination -s

Destination folder

File HTML is generated with Css style

Source Code

You can find my source code in this repo:

shinny-ssg Version 0.1 - CLI Tool to generate HTML File


  • generate .html files from .txt files
  • accept folder as input path to generate .html files in the destionation folder which will has the same structure as the original folder
  • give user the options to specify destination folder and/or stylesheet url link

How to use

  • Download or clone the shinny-ssg folder to your local machine
  • Use command prompt to navigate to the folder netcoreapp3.1 in the shinny-ssg folder ( path shinny-ssg\bin\Debug\netcoreapp3.1)
  • In the command prompt run shinny-ssg.exe -h to see the options
  • The file will be generated in the shinny-ssg\bin\Debug\netcoreapp3.1\dist folder by default or in the destination folder if specified by user


shinny-ssg.exe -h

shinny-ssg.exe -i

shinny-ssg.exe -i -o -s

Option Function

OPTION Function
-v --version Name and version
-h --help Information
-s --stylesheet <'link-to-css-stylesheet'>
-i --input specifies an input file or

by Emily Phan at Sat Sep 18 2021 00:10:33 GMT+0000 (Coordinated Universal Time)

Tue Nguyen

Doing code review

After finishing my static site generation program, I partnered up with Oliver Pham so that we could both review each other's code.

Issues with my code:

A list of issues can be viewed here.

My program was not perfect in many ways, I expected it to have some flaws which turned out to be true.

The issues weren't severed, the program still functioned fine, but the HTML files generated had quite a few HTML markdown errors and the help command didn't print enough information. After some discussions, Oliver managed to fixed those issues easily, he also caused a bug but quickly patched it up.

My contribution to my partner's code

You can take a look at its issues here

I was excited to look at his Python code for the same program which is a language I haven't tried. Luckily, Python is not a hard language to jump into and his code was readable.

The first by I found was that his program couldn't open files encoded in utf-8 because Windows' default is Windows-1252.

The second bug was caused by the input path having the current path, ex: ./file.txt, the program couldn't parse the title from such file path.

Lastly, one of his functions that parses title from the text file(s) was a bit confusing so I shortened it using some regular expressions.


This activity actually gave me more joy and more experience collaborating, I thought it was gonna hard as I was giving away my code for another person to criticize.

In the end, it motivated me to test his program with a view to returning his help finding fault in my program, I wouldn't have this experience doing solo. Also, getting to actually use Github, making pull requests, talking to other devs, learning more about Python are valuable lessons to me.

by Tue Nguyen at Sat Sep 18 2021 03:30:45 GMT+0000 (Coordinated Universal Time)

Qiwen Yu

Static Site Generator - TextHTMLPress

This week, to create a static site generator is the goal. I named my generator as TextHTMLPress, and it is a command-line static site generator for generating a complete HTML web site from raw data and files. This tool is written in Python.

To write a tool like this is a challenge to me. I spent time on understanding the idea, reviewing other similar projects' source code. Pelican is one of the open source project I referred to in this project.

My school has a quite large open source community on Slack for the students to connect and communicate with each other like a professional software developer would do. I found a partner on the Slack, and his project is written in Typescript.

I found it quite interesting to work with someone who is writing the similar project as you but in a totally different way. We reviewed each other's repo on Github, and provided issues to improve our projects. I think one important thing to work with others is to check your notifications more often.

The biggest challenge to review other's code is that we wrote in different languages. I used modules in Python, and he used packages in Typescript. If we want to understand each other's code, we need to search for the proper usage for those modules and libraries. Of course, the syntax also matters. I rarely use Typescript. so when I just started to review his source code, I found it is a little bit weird for me to understand every steps.

When I was reviewing his code, I found his README file is a little bit simple for the person who has few experience with the Typescript. So I filed an issue to his repo, and to suggest him to improve his README file. Enhancement

He also filed me an issue, which is my tool has a conflict between the title and the first paragraph. My title will be treated as a paragraph. To fix this, I need to remove several lines in my code.
Title/Paragraph Conflict

After this whole process, I think the ability to review others' source code efficiently could be a really important part when doing the open source project. We need to understand others' thoughts and their way to implement the project.

I think the next step of improving my project is to make my HTML look nicer and responsive. Making proper fonts and style for the HTML.

by Qiwen Yu at Sat Sep 18 2021 03:26:59 GMT+0000 (Coordinated Universal Time)

Ritik Bheda

Learnings from release 0.1

Hi all, I am back and this week I have my experience and learnings to share on a project I worked this week. The project was to release version 0.0.1 of a Static Site Generator tool I am making for my course at Seneca College. The tool can take commandline input of text files or folders and generate html files for the same. More information about the tool and its uses can found in this post.


It was a really great experience working on this project as I got a profound understanding on commandline tools, npm and Node.js development. The process also gave me a better experience using git and GitHub. Later, I found an amazing(luckily) partner Tuan Tan who is highly skilled at backend development and to be more specific, Node.js development. We met on our class Slack channel where he posted that he is looking for a partner and then I approached him for the same. We both helped each other by reviewing and testing each others code and finding possible areas of improvement on each others project.

Improvising Tuan's Code

Well, it was very new for me to test review someone’s code as I was doing it for the first time, but I found myself comfortable and confident enough to test his work after reading this post in which he explains how to use his tool. The tool documentation being so good, it was easy for me to install, run and test in my local machine. Well, everything worked perfectly and according to the requirements, and that did not surprise me, but the surprising part was it was done so amazingly that it gave a hard time to find 3 issues in the code!
The 2 of the 3 issues I found were related to commandline options and the third one was related to version. The options part had an issue that the output on the terminal was not align which I according to me, if improvised can give a better look of using the whole tools. The second issue regarding options was that the tool was using commandline arguments as program variables instead of options. Improving this can make the work easier for the developer and can also make the work more organized. The final issue was related to the tool version. The program was not able to pick the package.json file which gave an error when I tried seeing the version number through the commandline.

Issues in my Code

He also helped me in reviewing and testing my code. I was eager for him creating issues so that I can work on them and improve my tool. His issues did not surprise me as I was sure I might have made a few mistakes during the development.
He was able to find 3 issues in my code as well! He found issues of a typo, picking version from the file and program giving errors in special cases. I had a typing mistake in my code where I misspelled ‘successfully’ to ‘successfullly’. The issue can be found here. The second issue was versioning related as he suggested me to pick the program version from package.json which could reduce programmers work manually updating it in every file that uses it. And the last issue he found was input file/folder related in which he entered a file which did not exist. Instead of my program warning the user, it created an empty folder which was never expected. I later worked on all the 3 issues and resolved them ASAP.

My takeaways

I learned that everyone has different thinking style and approach to a problem. I learned how my thinking style affects the problem I am working on. I also learned from his experience on the projects testing and reviewing about Node.js development.


You may find the project and lab related these links helpful:

by Ritik Bheda at Sat Sep 18 2021 03:20:03 GMT+0000 (Coordinated Universal Time)

Andrew Nguyen

Building a Static Site Generator (SSG) with Rust

Recently, I have been interested in learning Rust, which is much different from my comfortable bed of TypeScript. I was curios why so many developer like it. Therefore, I'll build an actual program with it to see for myself.

Table of Contents

  1. About the projects

  2. Code separation

    1. mod cli
    2. mod file_parser

About the projects

Read more about installation and examples here

The main feature of paper is parsing text files (such as .txt or .docx) into their corresponding html version.

The tools recursively goes through the source directory, and generate a dist dir that keeps the same folder structure as the source file.

It also generate an index.html which indexes all the links to .html files inside dist.

$ cargo run -- --help

    paper.exe [OPTIONS]

    -h, --help       Print help information
    -V, --version    Print version information

    -i, --input ...             Path to file(s)
    -o, --output                Path to output file
    -s, --stylesheet     Link to stylesheet

Code separation

What I love about this project so much is the ease of introducing new features. Let's look at the project' structure.

  +-- src
      +-- cli
      |   +--
      |   +--
      |   +--
      +-- file_parser
      |   +-- asset
      |   |   +-- template.html
      |   +--
      |   +--
      |   +--

There are two modules represent the two main features:

  • cli has all the logic for working with parsing and caching CLI arguments, as well as running the program

  • file_parser has all the logic for working with reading and parsing the content of file_parser

mod cli

  +-- src
      +-- cli
      |   +--
      |   +--
      |   +--

The cli includes Generator and ArgsParser.

ArgsParser has a single responsibility: to parse the arguments from the CLI and cache it.

Generator acts as a coordinator, controling the flow of the program. It sends out users' input to modules and generate the corresponding results.

ArgsParser is injected into Generator. Currently, ArgsParser is a wrapper on top of, but it can be easily switched to another library. As long as the parser provides parsed arguments, Generator is happy.

mod file_parser

  +-- src
      +-- file_parser
      |   +-- asset
      |   |   +-- template.html
      |   +--
      |   +--
      |   +--

file_parser includes SourceFile and Template

SourceFile represents the parsed text file (raw data). It has all the logic to parse and store the read content.

Template represents the html file (dist file). The destination where it should be is separated from the class to keep its single reposibility of converting text to html. In the future, if there's a need for parsing more than just paragraphs (e.g. anchor, image, etc.), they will also be inside Template.

by Andrew Nguyen at Sat Sep 18 2021 03:00:00 GMT+0000 (Coordinated Universal Time)

[OSD600 Series] Collaborating on projects

Table of Contents

  1. Networking
  2. Testing & Code Reviews
  3. Fixing
  4. Revising
  5. Additional Resources


Rust is not as common as other languages like JavaScript and TypeScript, so it was a bit harder to find a partner who was willing to do a code review with me. Eventually, Antonio, who was also interested in learning Rust, contacted me and we started collaborating.

Testing & Code Reviews

Reading someone else code when I just learned the language was both eye-opening and confusing at the same time. There were syntax or language mechanics that Antonio knew but I didn't, and vice versa. It was also nice to see a different approach to the same problem.

I was impressed that Antonio write the logic for parsing CLI's arguments from scratch. I was trying to do that at first, but there was so many edge cases so I was discouraged and just used an existing crate instead.

There were some issues with Antonio's program:

  • The program allow empty value for --input, and created an empty dist #1

  • Code should be separated into modules for readability #2

  • When passing a file as --input, the program exited #3

Antonio also found some bugs on my program:

  • Handled error should exit with code 0 #15

  • dist is generated in the current directory of running the command #14

  • The program crashed when not running from the root directory #13


I wasn't able to fix issue #14 due to the lack of means to get the path to root crate in Rust. From what I have researched, after the program is compiled, Rust does not aware of the file system anymore, so there is no tale where the root of the cwd is.


Testing the code on my own is never enough. Getting my code tested from a different run-time environment and perspective exposes more bugs and potential improvement.

Additional Resources

Read how the SSG paper is built.

by Andrew Nguyen at Sat Sep 18 2021 03:00:00 GMT+0000 (Coordinated Universal Time)

Andrei Batomunkuev

New Experiences in Open Source

Photo by Mohammad Rahmani on Unsplash

Since I have released my Open Source project — Static Site Generator (SSG), new experiences have come to me: networking, reviewing code of the colleague, finding bugs, resolving issues found by my colleague. It was a great and fun experience for me.


The first task was to find a partner to review each other’s code. I have ended up finding a partner on the last day of lab submission. I am glad I found my classmate Roxanne. We have found each other through Slack. We then moved to Discord to talk about our projects.

Same tool, different implementations

We have the same project task (building SSG tool), our implementations are so different. I have used Python, whereas Roxanne has used JavaScript & Node.JS. I have written my project on Linux (Mac OS) Machine, whereas Roxanne has done on Windows Machine.

We have reviewed our code and got a lot of ideas on how to accomplish a task in different ways: different languages, different platforms. I am in the process of gaining 3 main components in Open Source, which I have defined in my first story

Code review & finding first bugs

It was a really fun experience for me trying to run as well as crash Roxanne’s code. As we were on Discord call, we were discussing and demonstrating the process of reviewing and finding the first bugs. At the same time, not only we were finding bugs in our CLI tools, but also discussing, brainstorming ideas to solve those bugs. We were both open to suggestions and ideas.

Filing issues in GitHub & resolving those issues

Issues that I have found in my partner’s code:

When I were filing issues, I tried to provide clear issue by attaching images. The issues that I have found were minor, so, Roxanne did a great job resolving the issues quickly.

Issues found by Roxanne:

Most of the issues were caused by the fact that I have done the work on Mac Machine and have not tested the tool on Windows Machine. So, it is important to test your application on several platforms. Roxanne not only found the issues in my program but also suggested possible solutions, which I have taken into consideration to resolve the issues.

Main takeaways

  • There are multiple different approaches to implement the same program, tool.
  • It is great having your code reviewed and also review other people’s code to make the tool better. Sometimes, your colleague finds a bug that you haven’t seen.
  • It is important to test your tool, software application on different platforms since it can behave differently.
  • It is an interesting process of doing a code review, discussing, and fixing bugs.
  • By doing this lab, I got a glimpse of the work of an open-source contributor.

I am excited to see the new tasks in Open Source Development course!

by Andrei Batomunkuev at Sat Sep 18 2021 02:34:05 GMT+0000 (Coordinated Universal Time)

Suhhee Kim

After peer testing and review _ Lab01

This time I had difficulties with finding a partner for this release. I tried to find a partner on slack to exchange codes and review each other's codes. And I found one to work together. However, the one who promised to review my code is disappear and did not read my messages. So, I found another partner. He was also Korean like me!

My partner was using C# and I know C# but am not an expert of the language and I didn't have C# on my personal laptop. So, it took some time to download tools for C# on visual studio, review, and run his code. It surprised me because compare to Node.js what I used, there are lots of folders to run a simple program.

I am a person who feels so shy to get code reviews from my friends. After he reviewed my code, I was quite surprised by his feedback. There is some part that I didn't notice that is a defect but it was a defect and it fails my program. For my program, there was a problem that My code does not accept the files with spaces. ( Also, there was some problem reading the whole file in a folder. (

And as I also reviewed my partner's codes. I found some issues, such as all the text file information goes into one "h1" tag, not into "p" tags.(, The same Style sheet is included in the head tag twice() and files in the dist folder are not deleted before creating new HTML.()

After both of us reviewed each other's code. I revied his issues on my codes and try to fix them. I was able to fix both of the issues by just adding a few more lines.
With this testing and reviewing process, I think it is quite an important process in creating a program. Because one person can find all the issues that exist in the program. Especially, if the program is written by themselves. I think I will keep this procedure for my future codes and programs to make it better.

by Suhhee Kim at Sat Sep 18 2021 01:33:08 GMT+0000 (Coordinated Universal Time)

Reza Poursafa

Code Review — OSD600

Code Review — OSD600

One of the requirements of my open-source course was to review a friend’s code and post issues on their github.

I found Amasia through our class chat on slack. I was expecting to really struggle to understand her code but I could understand most of her code up reviewing.

At the time of my review, Amasia’s work was complete yet, but seeing her work, I’m sure the end result would be amazing!

When reviewing her code, One of the problems I faced, which I’m sure will be resolved in the final version, is that the installation instructions were a bit vague. I had a hard time finding out how to run the code and what custom command to use instead of node.

The other issue I found was that the messages or the console.logs were not displaying the proper message when creating the text files and there are unnecessary console.logs that can be confusing to the user.

Finally the last issue that I could find was that while the messages showed that the file was created and the process was successful, no HTML files was actually being created to any of the files in the directory.

I’m sure that all of these problems will be fixed in the final version and other than these, the code is very well-written and I enjoyed reviewing her code.

She was able to find some issues with my code which surprisingly I had missed. I am going to work to resolve these issues.

by Reza Poursafa at Sat Sep 18 2021 01:13:15 GMT+0000 (Coordinated Universal Time)

Tengzhen Zhao

Release 0.1

The first assignment required us to create a static site generator. I choose Python to write a simple Static Site Generator tool named Magic-SSG is, and it can help user to generate .html from . txt files.


So far, this tool has the following functions:

  • Allows the user to specify an input file or folder to open a .txt file and generate a .html file.
  • Automatically identify titles and content.
  • Specify a different output directory using --output or -o.
  • Allow the input to be a deep tree of files and folders.
  • Allow user to check the tool's version.


Make sure you have installed Python version 3.8.5 or above.

How to use

  1. Generate a .html file from a file or folder:

    python -i/--input

  2. Specify a different output directory using --output or -o.

    python --input --output

  3. Check the tool's version

    python –v/--version

  4. Display how to use the tool

    python –h


Full list of features:

input file:

output file:


Link to my github repo from here

by Tengzhen Zhao at Sat Sep 18 2021 00:26:20 GMT+0000 (Coordinated Universal Time)

Review Lab 1

I find my partner- Le Minh Pham - through Slack and we both prefer Python. I just started learning Python, but he should be an expert. I learned some new libraries and methods after testing and reviewing Le’s code. I am surprised at the beautiful structure of his code. My partner helped me solve a big problem of finding folders, so I’m lucky to have such a partner.

Reviewing and testing code is an exciting and painful thing for me. I'm excited because I can learn a lot of skills from my partner. For example, the original code only has one file, but after optimization, it has four files, and many auxiliary functions are added, and the structure is clearer.

The pain is because as a new language, it takes me a long time to review and test it. Especially, my partner is very diligent. His code changes a lot every few days. Based on my level, it’s hard to find issues about his constantly improving code. Despite all this, I can still find problems and put forward what needs to be improved. For example, the issue “--input folder command line isn't working”. I also give some [suggestion]. (

There are 2 main issues about my code. issue1, issue2 Le give me lots of suggestion to fix the bugs, and I am fixing them.
This lab is very important for me, because a lot of basic knowledge needs to be learned, and it also help me to recall the knowledge I learned before. I am confident to complete the future project

by Tengzhen Zhao at Sat Sep 18 2021 00:07:08 GMT+0000 (Coordinated Universal Time)

Roxanne Lee

Lab 1

Networking, debugs, and fixes

Finding a Partner

For Lab 1 we had to find a classmate to help debug our release 0.1.0, and also help a classmate debug theirs. It ended up with most people working in pairs. As I started kind of late, and still slightly shy about looking for a partner out in the open, I was worried if I’d ever find a partner for the lab. But, I ended up reaching out on Slack to fellow classmate Andrei, and we partnered up.

A Fun Experience

Debugging each other’s code turned out to be a really fun learning experience, and not as stressful as I originally thought it would be. We ended up going on a call together to review each other’s code. Whether I was the reviewer, or the one being reviewed, I learned a lot through the whole process.

We had a lot of differences in our codes. Just to name a couple, Andrei’s was in Python, while mine was in Node.js; and he wrote his code on iOS while mine was on Windows. It was really neat in seeing how two different codes came up with similar results. At the same time, we also had many similarities, mostly in the logic of our code. Many of the issues I was concerned with in my project were the ones I used to debug his, and vice versa.

Issues I Reviewed

A lot of the issues I could find in Andrei’s code were very minor. Here’s a list with links to the issues I found.

As the reader can see, half of the issues were generated because we worked on different operating systems, and Windows seems to works differently when it comes to Unicode. If we didn’t happen to be on different systems, we would never have known about these possible issues.

Issues With My Code

Similarly, the issues Andrei found for my code were small as well.

The first problem in particular was simply a typo in the Readme file, but would have been devastating if Andrei had not pointed it out. Despite all these issues being minor fixes, it was so easy for me to overlook them all. I would not have found them if I didn’t have someone else review the code for me.


I was able to fix all my current issues, and so did Andrei. Yay!

We both had a lot of fun during the process, and also learned a lot through looking at each other’s code logic, and trading ideas on finding bugs in our code. Biggest thing I learned through this experience is how easy it is for a programmer to overlook even the smallest details. I’m also really surprised how much I learnt just through reviewing someone else’ code, and the anticipation of being reviewed. I can definitely say that this lab has got me slightly more confident in this course, and I look forward to what our future labs may bring.

by Roxanne Lee at Sat Sep 18 2021 00:10:31 GMT+0000 (Coordinated Universal Time)

Mizuho Okimoto

Open Source: Test & Review a Static Site Generator(SSG)

Being new to open source, testing SSG can be difficult. My first open source project was creating a static site generator. Honestly, I didn't even know what SSG was, and it took me longer than I expected to complete this project.

I used Node.js to generate HTML file(s) from text file(s), and my partner Anatoliy Serputov also used it. We met on Slack and decided to collaborate to test and review each other's projects. Even though we used the same language, his way was different from mine: such as using different methods, NPMs, markdown, and the way to generate HTML file from templates. Moreover, after he tested my project and gave me reviews in a nice way, it was a really good experience that someone checked my code carefully and suggested many things for me to improve my project.

Test & Review

Anatoliy found a very simple and efficient way to generate HTML files using methods and techniques I didn't know. His project successfully generates HTML files, but also I found 5 small issues and posted them on GitHub repository. (URL: I would like to summarize them in the following 3 points.

1.User interface

When the program run, there was no message on the command line if the program run properly. He commented out the console.log('File is created successfully.'), so I suggested him to keep the console. Also, even though HTML files were generated correctly, there was a warning, "(node:16300) ExperimentalWarning: The ESM module loader is experimental.". I'm still not sure why it displays, so I would like to figure out how to get rid of it.

3.Basic Function

I have the same problem: if spaces includes the name of the text file, the program can't open the file. Therefore, he made it possible to read a text file and generate an HTML file by storing the text file in the specified folder.


When I run -v or --version flag, only --version worked, and -v didn't work, so I told him, and he already fixed it. In addition, I used Prettier to format the HTML files, so I recommended it to him, and he implemented it too.

Fix my issues

Issues on GitHub:
These are the issues that Anatoliy reviewed. I will try to fix my issues to make it better and useful! Stay tuned for the update!


As students, we're not supposed to see other students' code, so testing and reviewing was a new experience. Testing and reviewing another person's project was complex, but I learned many things from his code, and I will fix my issues from his review.
It was our first project, but very complicated, so I couldn't see how to achieve it at first. However, after my classmate and partner helped me through our Slack community, it became clearer in which direction I should move forward.

by Mizuho Okimoto at Sat Sep 18 2021 00:02:22 GMT+0000 (Coordinated Universal Time)

Friday, September 17, 2021

Roxanne Lee

Release 0.1.0

Of my static site generator

Second week of OSD, and we were asked to finish a Release 0.1.0 for a static site generator. We needed to create a command line tool that held certain options and features.

I wrote the code with node.js, and while it may still be in baby mode, but I’m quite happy with how it turned out.


Link to my github repo for this release can be found here.


Here are some of the features of my tool

  • (Required) Allows the user to specify an input file or folder to be processed.
  • Allows the input to be a deep tree of files and folders, all .txt files in the tree of folders are recursively parsed.
  • Parsed titles (if any) from input files. Titles are identified with the first line followed by two blank lines.
  • Allows specification of a different output directory.
  • Allows specification of a stylesheet through linking a stylesheet URL
  • Automatically generates an index.html file with relative links to each of the generated .html files if an input folder is specified.

Tool Options

-v, --version                           Displays tool name and
                                        current version
-i, --input     Designate an input file or
-o, --output            Designate an output 
                                        directory, default ./dist
-s, --stylesheet        Link a stylesheet URL to the 
                                        html files
-h, --help                              Lists all available options

How it works.


For starters, the code hasn’t been published on npm yet. Therefore, to use the tool as a console command, users will have to head to the working directory of the tool and write npm install -g in the console.

Option Examples

Once that has all been setup, users can call the tool name directly in the console to make it act like a command line tool.


sitegen -v or sitegen --version will display the tool name and current version.


sitegen -h or sitegen --help will list the tool options as listed above.


sitegen -i filename
sitegen --input "directory name"
sitegen -i relative-or-absolute-path-to-file-or-directory

File or directory path must be passed as an argument directly behind the input option for the tool to correctly identify the file(s) needed to be processed.

In the case of spaces in file or directory names, quotation marks “” can be used to wrap around the name.

Output and Stylesheet

sitegen -i filename -o relative-or-absolute-path-directory
sitegen -i filename -s "stylesheet url"
sitegen -i filename -o directory -s "stylesheet url"
sitegen -s "stylesheet url" -i filename -o directory

The above are some examples of using stylesheet and output options. The order for using options doesn’t matter as long as an input option exists and there is a valid input file/directory in the command.

File/Directory path or url path will have to directly follow the specified option for the tool to work correctly.

In the case that an output directory isn’t specified or isn’t valid, the tool will generate all files in a default “dist” folder in the current working directory.


I started the project a little later than I had planned, mostly cause I was hesitant on the language to write it in. I ended up choosing node.js with JavaScript, as its something I am most comfortable with.

I didn’t install any packages for my current project, as for now its easy enough that I can just write the code from scratch. But moving onwards, learning to make use of available packages should be something I should experiment with.

There are still many issues with my code. For one, I need to work on formatting and making things look cleaner. I also need to learn more about formatting readme files and making it look nice. But overall, it was a fun week, I had learned a lot, and I’m quite happy with how this release has turned out so far.

by Roxanne Lee at Fri Sep 17 2021 23:15:09 GMT+0000 (Coordinated Universal Time)

Gus McCallum

Lab 1

This week I worked with Joshua Li on each other's SSGs. We both wanted to work in C++ so that narrowed down the options quite a bit, I was surprised at how few people wanted to try in C++.

The hardest part of testing/reviewing Joshua's code was finding anything to critique, it was that good. Like when a prof gives you code to work on, logically organized, concise and without mistakes. His code wouldn't compile using g++ originally, but after ignoring the warnings that came up it compiled fine. I think it was just a case of the compiler being finicky, it wasn't liking the multiple declarations of having prototypes earlier in the file but it ran fine after I ignored those. He also included an executable so it wouldn't have made much of a difference regardless.

The other issues I logged were more just nitpicks to get to the minimum allowed issue number, I think you'd agree if you took a look at his repo.

My code had a lot of issues when he looked at it yesterday, for example not creating a ./dist/ folder for output. I've never used _mkdir before so that was something I hadn't yet implemented.

Another issue was not iterating through a whole folder. I think this one was actually due to an issue naming the output so the files were getting overwritten to a single .html file.

I don't think I learned much from the testing and reviewing. Maybe I passed it off too soon but I was pretty aware of the work that had to be done, I just hadn't had time to get it all worked out yet. It was cool having someone to talk to and bounce ideas off of though. I got stuck at one point because my visual studio solution was using the wrong C++ standard, and I quickly got advice from Joshua on how to fix it without having to spend the time troubleshooting and googling fixes. I don't think that's far off from my usual school experience, but maybe that's why an academic environment lends itself so well to open source development. Being in a setting with peers working on the same projects naturally means you're inclined to help each other break through those roadblocks and learn better for it.

by Gus McCallum at Fri Sep 17 2021 22:17:59 GMT+0000 (Coordinated Universal Time)


This week I wrote a Static Site Generator in C++ that takes a text file or folder structure and generates HTML files based on any text files found within. It's been 8 months since I've written any code so it was a big undertaking getting back into it, but it felt good to code in C++ again. There's a lot I could've written more efficiently, some code duplication etc. but it gets the job done and got me working with classmates to solve some problems open source style.

The SSG comes in .cpp form and should be compiled using C++17 to support the recursive file system searching feature from . It accepts command line arguments -i or --input to specify an input file or folder structure, -h or --help for info on the commands to use, and -v or --version for version information.

If there's a title with 2 blank lines following it, GAS will make this the title of the page. This line will also be be made an


The blocks of text are split up into

tags if a blank line is found between them. That's about all there is to it, you can check out the repo here and a sample HTML page generated here.

by Gus McCallum at Fri Sep 17 2021 21:43:45 GMT+0000 (Coordinated Universal Time)

Le Minh Pham

My first open-source collaboration

After finishing and publishing my cool_ssg_generator on GitHub, I started looking for collaborations from my classmates using our Slack channel. I was able to get Jia and Tengzhen to review and test my code.

Jia’s program is written in Node.js, which is a language I used a lot in my previous courses, so it was not too difficult for me to read their program. I did learn some interesting features from his code that I had not tried with Node.js before, such as dealing with command-line arguments, or scanning a directory for files. The first bug I was able to notice was that the HTML files generated from Jia’s program used the entire file content as the page’s title, and wrap the entire thing in <h1> tag, regardless of if the input file has a title or not (link to issue). Jia was able to identify the code snippet that led to this error and fixed it. Turns out it was a problem with newline characters, which are represented differently on different systems (for example, newline on Unix and Unix-like systems is \n , while on Windows is \r\n , more information can be found here). This seems like a small difference, but it’s definitely a pain to work with.

Another interesting bug I found in Jia’s program is that when I used a directory tree with multiple levels deep like this one:

The program gave an error:

[Error: EISDIR: illegal operation on a directory, read] {
  errno: -4068,
  code: 'EISDIR',
  syscall: 'read'

It looks like that the program was trying to treat deeper dir subfolder as a file, and was trying to read it as it would read a file. After examining Jia’s code a bit more, I noticed they used fs.readdir() to read the input directory, and then called fs.readFile() on the values returned by fs.readdir(). However, it seems that fs.readdir() also returns the names of the subfolders alongside the files, so when they are processed by fs.readFile(), the program will give errors. This theory became more convincing to me when I looked into the index.html file generated and saw that one of the <a> tags has href="deeper dir.html", even though deeper dir is a folder. To fix this bug, I believe Jia has to implement a way to recursively call fs.readdir() to identify all the files in the whole folder hierarchy before passing them to fs.readFile(). Link to the issue can be found here.

I also reviewed Tengzhen’s SSG program, which is also written in Python, same as mine. We are both beginners in Python, so this is a great opportunity for us to learn from each other. They wrote the entire program in one file, which is interesting to me since I’m still unfamiliar with how a normal Python project should be structured. Meanwhile, due to being used to class/component-based file structure from C++ and React/Angular programming, I split my code into two. I’m still unsure which one is the better practice, since this is a fairly small program.

An issue I found in Tengzhen’s program was that when I tried using folder input, for example ./sample/ , the program tried to open this file ./sample/sample/test.txt , instead of ./sample/test.txt , which is the right location of the file. After taking a look at their code, it seems that they appended the folder name twice before opening the file to read, hence the error. I believe this can be fixed by removing the line that appends the input folder and the file path a second time (link to issue).

Another error that I got with Tengzhen’s code was a file writing error, where the code tried to create HTML files in a non-existing folder. I had this exact same error earlier, and my lifesaver was the os.makedirs() command, which lets you create any folders in the file path that are missing in one function call, without having to create each one recursively. For example, let’s say you want to save a file to dist/subfolder1/subfolder2/index.html , while the dist folder is currently empty, os.makedirs("dist/subfolder1/subfolder2/") will create both subfolder1 and subfolder1/subfolder2 for you. You then simply create the HTML file and write to it. I made the same suggestion to Tengzhen in the issue’s comment section (link to issue).

Now, moving on to my program. The first issue that Jia found was that my command-line options are not mutually exclusive, even when they should. For example, using command-line options like -vh or -vi should give errors, as it doesn’t make sense for both options to be run together. However, in my program, using -vh or -vi only prints the program’s version, while -hv gives the --help manual. This is an interesting issue for me, as I never thought about using them together before. After a while of googling, it seems that the library that I’m using for dealing with command-line arguments, called argsparse, doesn’t really support this kind of grouping command-line arguments. The library does have a function for creating mutually exclusive arguments group, but that method forces all arguments to be mutually exclusive, which is not what I want, since I still want to use --input with --output or --stylesheet. I have seen workarounds by using subparser, but haven't been able to get it to work with my program. While this is not an urgent issue, it’s something that should be worked on to improve usability for the users. I might also consider changing to a different command-line argument parsing library. This issue can be found here.

Tengzhen found an error with my program when using error input, as the program could not create the output folder. I realized it was a problem with dealing with forward slash / versus backward slash \ in folder path (which, again, thanks to the inconsistency between the operating systems, backward slash is used as a default on Windows and forward slash is used on pretty much every other system). My program mixed up the two when creating folders, and therefore led to the error. I fixed this by using string.replace() to replace any backward slash to forward slash in the folder’s path, since Windows can also understand forward slash. This seems to works as folder input is now working as expected. This issue is now closed, though you can go here to read more about it.

The second issue that Tengzhen filed is about my documentation on setting up a virtual environment with the environment.yml file I created in my repo using Anaconda. Virtual environment is useful when you want to have all the dependencies installed in an isolated environment without creating conflicts with other packages installed in your system. I have been thinking a lot about whether or not I should remove that section entirely from my , since my program does not require any dependencies at the moment other than Python, so as long as you have Python installed, you will be able to run the program. However, I also believe it will be useful in the future for those who want to have their environment quickly set up, when my program may have more dependencies. For this reason, I decided not to close this issue just yet. I did add extra notes stating that setting up virtual environment is entirely optional, and I also added a link to Anaconda’s documentation websites for those who need more info on it. This issue can be found here.

Overall, this has been a fun experience, as my partners helped me see errors in my program that I couldn’t see myself. I’ve also enjoyed communicating with them and assisting them with their own issues. Looking forward to collaborating with everyone!


by Le Minh Pham at Fri Sep 17 2021 22:12:23 GMT+0000 (Coordinated Universal Time)

Leyang Yu

Jellybean - A static site generator created in Node.js


From one small program, you can create an entire website. Jellybean is a static site generator created in Node.js that lets you easily convert your text files into HTML files.

Main Features

  1. A single .txt file or folder containing multiple files can be converted into HTML pages.
  2. The title of the page, which is the first line of a file if followed by two blank lines, will be automatically generated.
  3. Generated files are stored in the 'dist' folder and style is provided by 'style.css' by default. Custom folders and styles can be specified using optional flags (see below).


  1. Clone this repository
  2. Download Node.js
  3. Run the following commands
cd jellybean
npm install

Running the Program

node index.js --input <file>
node index.js --input <folder>
node index.js -i <file>
node index.js -i <folder>

Optional Flags

Flag Description
--output/-o Path to an output directory where generated pages will be stored
--stylesheet/-s Stylesheet URL to be used to style the generated pages

Getting Help

node index.js --help
node index.js -h

Getting the Version

node index.js --version
node index.js -v

Example Using a File

node index.js -i Sherlock-Holmes-Selected-Stories/The Adventure of the Six Napoleans.txt -o customoutput -s

Original File:

Sherlock-Holmes-Selected-Stories/The Adventure of the Six Napoleans.txt


It was no very unusual thing for Mr. Lestrade, of Scotland Yard,
to look in upon us of an evening, and his visits were welcome to
Sherlock Holmes, for they enabled him to keep in touch with all
that was going on at the police headquarters. In return for the
news which Lestrade would bring, Holmes was always ready to
listen with attention to the details of any case upon which the
detective was engaged, and was able occasionally, without any
active interference, to give some hint or suggestion drawn from
his own vast knowledge and experience.

Generated File:

customoutput/The Adventure of the Six Napoleans.html

<!doctype html>
<html lang="en">

    <link rel="stylesheet" href="">
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">

            <li><a href='./index.html'>Home</a></li>
            <li><a href='./The Adventure of the Six Napoleans.html'>The Adventure of the Six Napoleans</a></li>
        It was no very unusual thing for Mr. Lestrade, of Scotland Yard,
        to look in upon us of an evening, and his visits were welcome to
        Sherlock Holmes, for they enabled him to keep in touch with all
        that was going on at the police headquarters. In return for the
        news which Lestrade would bring, Holmes was always ready to
        listen with attention to the details of any case upon which the
        detective was engaged, and was able occasionally, without any
        active interference, to give some hint or suggestion drawn from
        his own vast knowledge and experience.



Example Using a Folder

node index.js -i Sherlock-Holmes-Selected-Stories

In the Sherlock-Holmes-Selected-Stories folder, if you have the files:

  • notatextfile.js
  • Silver Blaze.txt
  • The Adventure of the Six Napoleans.txt

In the dist folder, the following files will be generated:

  • index.html
  • Silver Blaze.html
  • style.css
  • The Adventure of the Six Napoleons.html

Live Demo




Leyang Yu



by Leyang Yu at Fri Sep 17 2021 21:50:32 GMT+0000 (Coordinated Universal Time)

Creating an SSG and working with others

This week, I created a static site generator for my open source course. The task seemed very daunting at first, but as I started to write my program, I realized it was actually quite straightforward. However, sometimes an unexpected input would cause my program to break or behave in ways I didn't expect. Therefore, I was very glad that I was able to collaborate with my classmate, Luke Nguyen, in testing the program and finding any issues.

Finding a partner for code review

I was able to find Luke using Slack as he was also looking for a code reviewer at the same time. I was excited to work with a fellow web developer and although I initially wanted to review a program written in a different language, reviewing another person's JavaScript code helped me see problems in my own and learn new things about something I was already familiar with. We continued to use Slack to communicate which was really convenient.

Reviewing the code

It was a really great experience reviewing someone else's code and seeing how they did things differently. I learned so much from reviewing Luke's code. For example, whereas I used an HTML template, Luke generated the HTML in his JavaScript code which seemed very efficient and was something I had not considered. Thanks to his detailed README and code comments, testing his program was a pretty straightforward process.

Having my own code reviewed

I always get nervous when someone else reviews my code and finds all sorts of problems with it. At the same time, it's really nice having an extra set of eyes look over the code, test it for any problems, and suggest new things. For example, I initially forgot to test my code using a directory that contained non-.txt files, but Luke did so and noticed a bug. In addition, I usually comment my code by using //, but Luke actually suggested a different format, which I decided to use as it was very clear and easy to understand.

Issues in partner's code

In testing Luke's code, I found that the --version flag did not correctly print the program name. In addition, his program was not able to correctly read file names that contained spaces. Finally, I noticed a formatting issue in the generated HTML code. Although the output was correct, the formatting of the HTML was messy and could be difficult to read (such as incorrect indentation or a lack of spacing between paragraphs). Luke used a library called create-html, which made generating the HTML very simple, but the formatting of the output could be improved.

Issues in my code

Luke noticed several issues in my code. We actually had several problems in common. For example, my program also couldn't correctly read inputs if they contained spaces. We both used yargs to read command line inputs so I had the same problem where the --version flag didn't print the program name. I also had a bug where non-.txt files in a directory were included in the navigation when they should be ignored. Luke also provided some comments on how to improve my documentation (such as my README and code comments). I was able to fix all of these issues and improve the quality of my documentation thanks to Luke's testing and clearly written issues.

What I learned

Overall, I think it was a great experience being able to work with a partner in testing an application. I learned about how the same problem could be approached in a different way and I was also able to make suggestions to improve someone else's code. I think collaborating with others will help me improve as a programmer over time.

by Leyang Yu at Fri Sep 17 2021 18:22:59 GMT+0000 (Coordinated Universal Time)

Roman Rezinkin


RomanStaticSG is a static site generator. It is simple to use, yet very effective.

About RomanStaticSG

RomanStaticSG is made in python. It is a simple static site generator. It accepts an input file, or input folder. The program will then take the accepted files and create basic html webpages, as well as an index.html file. The script also allows you to input a custom output directory, so that the files could be saved in a custom location.

Currently only .txt files work

What is a Static Site Generator (SSG)

A static site generator is a tool that generates full blown static HTML websites from raw data and some templates. The point of a static site generator is to quickly convert a document file or a text file into a working webpage, that is filled with content.

How to Use RomanStaticSG

Python 3.9+ Required

To use RomanStaticSG simply type

python --help

Some Commands in RomanStaticSG

Help Screen

python --help  |  python -h  

Version Check

python --version  |   python -v

Input Command

To run the input command specify the file name without the extension

python --input=example    |   python -i=example   

When running the input command and not specifying the output command, a local folder named "dist" will be created in the directory of the existing file.

Output Command

To run the output command specify the custom directory location

For Unix/Linux

python --output=./someFolder   |   python -o=./someFolder

For Windows

python --output="C:\Users\Roman Rezinkin\Desktop"    |   python -o="C:\Users\Roman Rezinkin\Desktop"


Although the task seemed taunting at first, I was able to quickly understand what I had to do. As a relatively new developer with Python, I had to make some academic searches for syntax and general knowledge on Python. This challenge only made the development of this tool that more entertaining.

Github Repository:
Sample Output Website:

by Roman Rezinkin at Fri Sep 17 2021 21:33:50 GMT+0000 (Coordinated Universal Time)

Suhhee Kim



This is an html generator from text file to html.

Technology used

  • Node.js

License Used

  • MIT License

Created by

  • Suhhee Kim

Github Repo


Before Use You need to do

  1. Download or clone the code.
  2. Download node, if you dont have it.
  3. Add environment variable on your laptop(C:\Program Files\nodejs)
  4. Open the codes.
  5. Locate yourself to create-ssg (cd create-ssg).
  6. Open cmd, type npm i and wait for download.

Main Features

  1. Run by Commands, such as help, version and input(Please look at the HElP for details!)
  2. It will convert your text file to Static HTML file with some styles!

Optional Features

  1. It has built in Fancy styled css!
  2. Also able to add your external css with the command -styledInput(-s) with link(Details and example is in HELP!)


  1. create-ssg --version(-v) : it will show you application name and version
  $ create-ssg  --version
  $ create-ssg  -v 
  1. create-ssg --help(-h) : it will give you all the instruction that you need to use this application.
  $ create-ssg  --help
  $ create-ssg  -h 
  1. create-ssg --input filename/foldername : it will automatically create website for you using file that you put in command line or if you put folder name then it will automatically get all the txt files from the folder and create website for you.
  $ create-ssg  --input [filename/foldername]
  $ create-ssg  -i[filename/foldername] 
  1. create-ssg --styledInput [filename/foldername] external css link: it will automatically generate website \n \t with beautful external css"
  $ create-ssg  --steyledInput [filename/foldername] [external css link]
$ create-ssg -s [filename/foldername] [external css link]&lt;br&gt;

by Suhhee Kim at Fri Sep 17 2021 21:14:50 GMT+0000 (Coordinated Universal Time)

Jia Hua Zou

SSG 0.1V code review

For my lab 1, I have to network through slack to find someone to review each other’s code. Le Minh Pham had kindly reach out to me to be a partner. We gave each other our repo and started testing.

Le Minh Pham’s SSG 0.1v

When I tested his SSG program it was nicely done. The code was easy to read and understand. There was a bug related to the option command. If the option input is followed up by incorrect characters, the program will still accept it. Issue

Over all the program is done very nicely.

My SSG 0.1v

When my code was tested. There was a lot of bugs. Issue 1. My title detection was detecting the whole file as a title. Instead of taking just the title encased in <h1>…</h1>, it would just take the entire text as the title. The reason why this bug happen is due to the wrong regex expression being used. Le minh had gave details to the problems and came up with some solution. It was a big help. Issue 2. There was an issue with my package.json file. When npm install is run, it would fail because it had the wrong version. At first I change the default version to “0.1v” in the package.json. I had to change it back to the original version in order to fix this problem.

In the end, fixing the bugs didn’t took too long thanks to Le minh’s feeback. It would have took me a while to find the bugs if I haven’t ask someone in Slack for a code review. I will know there are more bugs that will show up as I add more features to this project.

My github SSG repo:

Le Minh’s SSG repo:

by Jia Hua Zou at Fri Sep 17 2021 21:01:50 GMT+0000 (Coordinated Universal Time)

Gustavo Tavares

Reviewing Someone's Code! - OSD600 - Lab 01


This time I want to talk about my first experience reviewing someone else’s code. My friend for this adventure was Andre Willomitzer. I found him not through our slack channel, but he contacted me personally as we know each other for some semesters already.

This lab was really interesting, because we used the same language I though our code would be similar but instead we had a lot of different logics and different optional features implemented.

What I found checking Andre’s Code:


“npm install” not working.
His json packages were not working properly, to make it work I had to install yargs manually.

Check if -i input is present. If not, handle the error.
In his program, when running it without -i arguments like: ”node textToHTML_V2.js -i ”, the program was breaking.

His program was accepting only one argument as input.
While in the release 0.1 note step 9, it says that “your tool should generate one .html output file for each input file.”. If I entered as input two .txt files, only one was generated. He claimed this was a feature, but in my opinion, it didn’t meet the release 0.1 step 9.

Feature -o accept only folders on the project folder. Folders in another directory are not working.
The -o option only worked for directories inside the root folder, if outside like in the Desktop, then the program would break.

Check if -i input exist. If not, handle the error.
If I use an inexistent file as input for his program, the program will break.

What Andre found on my code:


On his end, while review my project he also found some bugs on my program:
I had an unused variable on my code.
The title of my files was coming from the first line of the txt file instead of the file name.

He also suggested an improvement on my -o feature, to create an output directory in case it didn’t exist, besides not being a bug, I decided to implement it while correcting the other bugs.


This lab was really interesting, seeing how other people use different logic for the same problem is makes programing even more interesting. How many ways there was to make a program like this?

Besides some bugs, Andre’s program was transforming a single .txt file in HTML file with paragraphs inside

tags as intended and when working with a single directory, it would do the same with each file as intended. Options like -v for version and -h for help also were working fine.

Thank you for reading again!

by Gustavo Tavares at Fri Sep 17 2021 20:07:42 GMT+0000 (Coordinated Universal Time)

Oliver Pham

My First Baby Steps in Open Source

After building my first prototype of a static site generator (SSG), I asked the open source contributors in a Slack channel to test my program. I was taken aback by what happened after that.

The first issue

After sharing a link to my repo in the channel, a kind developer accepted to review and test my code. I also took the opportunity to test his work in progress. Although I've already exposed my code to the public for a while, I was extremely nervous since it was the first time [someone on the Internet tested my prototype].

Not long after he started, the first issue was found. As expected, all I could say was:

To my surprise, neither a heated argument nor "code shaming" occurred. In fact, we worked together to figure out the cause instantly: I forgot to set the file encoding when opening text files. "How can it work on your machine?", you may ask. Well, I'd only tested the prototype on MacOS, whose default file encoding happened to be correct, but that's not the case for Windows. Therefore, having a fellow developer test my software and review my code is absolutely invaluable.

My first contribution

It didn't take me a lot of time to fix the issue, so I decided, in return for his help, to test his program, which was also a SSG written in Javascript.

Despite having worked with a large codebase before, I feared that it would take me a lot of time and effort to understand his code & architecture. Fortunately, I was wrong. In fact, his code was pretty well written and documented. All the core features worked as expected.

Everything looked good until I checked the static file on Some syntax was found invalid, so I opened an issue and described my recommended solutions as detailed as possible.

"Maybe I can do something more that that", I thought to myself. After getting familiar with his code, I managed to write a patch for the issue and make my first pull request for the project.

Thanks to my previous experience of collaboration on GitHub, the workflow (opening an issue, submitting a pull request, etc.) wasn't a big problem for me. Nevertheless, I learnt something truly precious from this experience: testing and reviewing code with a partner/team/community gives me more insight and motivation than I'd ever gain by coding alone.

🎉 Let's get more involved in open source contribution.

by Oliver Pham at Fri Sep 17 2021 20:03:33 GMT+0000 (Coordinated Universal Time)

Thanh Van

My very first collaboration - Lab 1

At the beginning of the course, I was introduced to Slack, which was a great app to communicate with other students in IT field. And I found Kien writes his program in another language, which is C++ and different from my program. I end up with asking him to be my partner for this lab.

I am very interested in testing and reviewing someone's code, it is totally a new experience for me. I have a chance to know how he does his code, thoughts, logic, etc. I review his code and I come up with some issues he has. When I try to run his program based on his instruction, it takes a while because he gives improper syntax. We already discuss about how we could get rid of it. The reason why it happens is because he initially puts pgprogram fname instead of ./pgprogram fname, the machine does not know where to execute the command.

Additionally, he uses Visual Studio to do his code, so when I clone his code to my machine and open it in Visual Code, I have to install C/C++ extension, but he does not mention it in his instruction. Other than that, his code is short and explained, which is easy for me to catch what is happening in this program.
Kien also comes up with some issues I have in my program. Initially, I put all the text file into a single paragraph tag, I fix this one by correcting regex in my function, I mix up [] and () in my program.

Overall, this is my first time reviewing and testing my peer's code, which is an interesting experience for me and I think for Kien as well.

by Thanh Van at Fri Sep 17 2021 19:37:40 GMT+0000 (Coordinated Universal Time)

Minsu Kim

Process and Outcomes from Release 0.1

I have chance to work with partner, Suhhee Kim. It is very impressive that all the students create their SSG application with various programming languages. Before Suhhee and me test and review code each other, we have faced the environment setting issues. This is because we are using different Integrated Development Tool (IDE), different library, and programming language. It is very surprise me that even we create same purpose application, the code is completely different.

The good things about someone else review my code are whether my application operates well on different device or not and finding a bug and an error that I could not find. The SSG application that I made operates well as expected. However, even though, her testing environment is identical as my testing environment. The result is different. She found the errors that did not show on my testing environment. This is very important because my app should run other environment or testing environment without error. Before I have testing with my partner Suhhee, I pretended my application indefective. However, she found various error that I could not found it that she helps me to make better application.

The issues that came up while I was testing with my partner are h1 tag wrap around whole paragraph in the text file, duplicate style tag in head tag, suggest adding more intuitive explanation when user wants to see the options, and dist folder including html files supposed to be deleted not overriding the files and folder. I found the error that her application could not the text file argument that has space between the file name. The most errors can be resolved. It is very simple mistakes. Glad my partner found the issues.

Our professor, David Humphrey said the developing software is never ends. Now I realized what the meaning of what he said. I pretended my application is indefective. But there must be hidden errors that I could not found. Be sure code meticulous and review and test by others.

by Minsu Kim at Fri Sep 17 2021 17:37:37 GMT+0000 (Coordinated Universal Time)

Kunwarvir Dhillon

Open-source: collaborating with others


A big part of open-source is working with others, and I wanted to gain experience with projects created by others and also wanted to get feedback on the open source project I had created earlier (cli-ssg). Looking for someone to peer review with, I ended up connecting with DerekJxy who had created My-First-SSG. Similar to the tool I created, he had also built a SSG using JavaScript. Since his tool used the same programming language, the code review process went quite smoothly for me.

Reviewing My-First-SSG

I started off by installing the tool after going through the documentation. I then tried running the tool to test its functionality and I ended up finding quite a few problems. I used the Issues tab in his GitHub repo to file a total of 5 issues highlighting these problems:

Unable to use files as input using -i

As per the repo readme, node server.js -i '.\Silver Blaze.txt' should produce aSilver Blaze.htmlin./dist`. However when I ran it, the tool failed to generate HTML and logged errors in the console.

Html is generated in the default location even if an output directory is specified

The repo readme as well as --help for the tool highlighted an option to use -o or –output to specify an output directory. However, the tool kept using the default ./dist even if I supplied an output directory.

Errors in console when directories are present in the input path

Everything in the input path was being directly passed to readFile and thus, if the input directory contained directories, it would spit errors in console.

Non .txt files are not ignored/skipped

The tool even generated HTML for non .txt files such as .json, .md etc

Generated files fail HTML5 validator

The generated HTML files failed the validator at

Going through Issues filed in my repo

As a part of the peer review process, DerekJxy also tested and reviewed cli-ssg. He filed 4 issues on the repo, of which I found one to be useful (fixed and closed!):

Unused variables

One issue highlighted that I had 2 imports in one of my files that were not needed. It seemed like these had lingered on when I had just started, so I ended up removing these 2 lines based on this feedback.

Issue 3 and Issue 4

Two of the issues were about code improvement. However I did not see the suggestions offering any improvement, one(#3) of them would rather hinder upgradability if more functionality in parsing the input file is added.

Unnecessary Statement

The last issue suggested that a part of code should be removed because the output directory would always have a default. However, that code was crucial in validating the output path set by the user and it wasn’t related to the default path.


Overall, I ended up merging a pull-request to remove the 2 imports which closed the first issue. For the remaining 3, I highlighted why the suggestion was not useful and ended up closing them. Thus, I was able to close all the issues filed on my repo after acting upon the feedback.

My repo:
Repo I reviewed:

by Kunwarvir Dhillon at Fri Sep 17 2021 16:59:33 GMT+0000 (Coordinated Universal Time)

cli-ssg 0.0.1: Node.js based static site generator

As a part of my open source journey, this week I created cli-ssg, an open source static site generator using Node.js. It is a command line tool to generate .html files from a given set of input .txt files.


✅ Parse title from the input files
✅ Ability to provide a custom output directory
✅ Ability to provide stylesheet URL
✅ Recursively parses input nested directories and files
✅ Automatically generates index.html if multiple txt files are present in input directory


npm i
npm i -g .
npm link


cli-ssg -i "sample_file.txt"

This processes text from sample_file.txt and generates sample_file.html

cli-ssg -i "sample_file.txt" -s "./stylesheet.css"

Same as above, however sample_file.html now uses ./stylesheet.css

cli-ssg -i "sample_dir" -o "output_dir"

This processes all the .txt files in sample_dir and generates .html files for each of them. It also creates an index.html with relative links to each page, storing all these files in output_dir.


  -h, --help        Show help                                          [boolean]
  -v, --version     Show version number                                [boolean]
  -i, --input       Input file/folder to be processed        [string] [required]
  -o, --output      Output directory                [string] [default: "./dist"]
  -s, --stylesheet  CSS Stylesheet for the website                      [string]


Simple Example:

cli-ssg -i ".\sample_input.txt" -o "custom_dir" -s ""


Sample title                   //<---first line followed by 2 empty lines treated as title

This is the first paragraph.
                               //<--- blank spaces treated as paragraph limits
This is the second paragraph.

This is the third paragraph


<!doctype html>
    <html lang="en">
      <meta charset="utf-8">
      <title>Sample title</title>
      <meta name="viewport" content="width=device-width, initial-scale=1">
      <link href="" rel="stylesheet">
      <h1>Sample title</h1>
      <p>This is the first paragraph.</p><p>This is the second paragraph.</p>

Complex Example:

Using multiple text files in the input directory, the following website was created with an auto-generated index.html having links to each individual page:

View it on GitHub:

by Kunwarvir Dhillon at Fri Sep 17 2021 15:42:53 GMT+0000 (Coordinated Universal Time)

Andre Willomitzer

The Gustavo Experiment - partners in Open Source.

Lab 1 in OSD600 open source class focused on reviewing and testing the Static Site Generator Github repository of another student. My partner for this in refining my code was Gustavo Tavares whom I have known for coming up on 2 years now at Seneca. I was confident in his ability to help me simplify my code and test for bugs.

First, I tested his code which was a fun experience. One of my favorite things about code reviewing is seeing how others approach the same problem that I do but in a different way. A surprise I did not expect was that originally he did not use "fs" module to read the files, and instead used the built in "Yargs" library functions. However, this presented some issues with the naming of the files after generating HTML The filename was: "filename.txt.html". Furthermore, there were some unused variables and code that I requested be deleted.

When it came to reviewing my own code, Gustavo found a few more "crucial" issues which included my "output" option being coded incorrectly. It was attempting to generate a folder, rather than output to an existing folder on the system which is what the requirement specifies. Another issue was that I needed a check in place to see if the file or folder actually existed on the system and print an error if it doesn't. I had the "throw error" statement but changed it to a console log which is easier to read.

One issue that was raised that I think is not an issue is the tool taking only 1 file or folder at the same time. The requirements and examples show 1 of each, not multiples. So this is more of a feature improvement request than a bug and did not get fixed.

In the end I was able to fix all of my issues which was nice. There are now checks in place for files that don't exist, and my output option can use another folder besides default "./dist". I'm sure there are more issues I haven't found but for this lab I fixed all the ones Gustavo and I found.

What I learned through this process is that there are multiple ways to achieve the same result. It's nice having a second set of eyes to review your code and refactor it to make it better. Sometimes a reviewer will spot something you didn't see because you wrote the code so it seems like it should work properly and makes sense to you. It was also useful testing someone else' code because it gave me an idea of some things I should test in my own code that didn't occur to me.

by Andre Willomitzer at Fri Sep 17 2021 16:56:54 GMT+0000 (Coordinated Universal Time)

textToHTML-- my first open source tool.


textToHTML is a file and folder parser to generate HTML files from txt files. It can be run from the command line. This tool was built as part of a Seneca College course OSD600 and was built over 2 weeks time using JavaScript/NodeJS and a library called Yargs.

Github Link:


To install the tool download the source code. Make sure to have an updated version of nodeJS and npm installed. On the command line, type npm install.

Input is required, stylesheet and output folder are optional.

Default output folder is "./dist".


node textToHTML -i <filename/foldername> -s <stylesheet url or path> -o <alternate folder output>

node textToHTML --input <filename/foldername> --stylesheet <stylesheet url or path> --output <alternate folder output>

node textToHTML --input <filename/foldername> --stylesheet <stylesheet url or path> 


  • Supports outputting to a specified folder.
  • Allows adding of custom stylesheets to generated HTML files.


- node textToHTML.js --help or -h displays a help menu with options/commands available.

Sample Output

The Input Text:

I was not surprised. Indeed, my only wonder was that he had not
already been mixed up in this extraordinary case, which was the
one topic of conversation through the length and breadth of
England. For a whole day my companion had rambled about the room
with his chin upon his chest and his brows knitted, charging and
recharging his pipe with the strongest black tobacco, and
absolutely deaf to any of my questions or remarks. Fresh editions
of every paper had been sent up by our news agent, only to be
glanced over and tossed down into a corner. Yet, silent as he
was, I knew perfectly well what it was over which he was
brooding. There was but one problem before the public which could
challenge his powers of analysis, and that was the singular
disappearance of the favourite for the Wessex Cup, and the tragic
murder of its trainer. When, therefore, he suddenly announced his
intention of setting out for the scene of the drama it was only
what I had both expected and hoped for.

“I should be most happy to go down with you if I should not be in
the way,” said I.

The Output HTML:

<!DOCTYPE html>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<p>I was not surprised. Indeed, my only wonder was that he had not already been mixed up in this extraordinary case, which was the
one topic of conversation through the length and breadth of
England. For a whole day my companion had rambled about the room
with his chin upon his chest and his brows knitted, charging and
recharging his pipe with the strongest black tobacco, and
absolutely deaf to any of my questions or remarks. Fresh editions
of every paper had been sent up by our news agent, only to be
glanced over and tossed down into a corner. Yet, silent as he
was, I knew perfectly well what it was over which he was
brooding. There was but one problem before the public which could
challenge his powers of analysis, and that was the singular
disappearance of the favourite for the Wessex Cup, and the tragic
murder of its trainer. When, therefore, he suddenly announced his
intention of setting out for the scene of the drama it was only
what I had both expected and hoped for.</p> </br> 
<p>“I should be most happy to go down with you if I should not be in the way,” said I.</p> </br>

by Andre Willomitzer at Fri Sep 17 2021 15:21:43 GMT+0000 (Coordinated Universal Time)

Tuan Thanh

Process of reviewing my friend's code in Nodejs


Hi everyone, I'm a Computer Science student at Seneca College, this is the 2nd week of open source programming course, we have an assignment about reviewing my colleague's code which is about static site generator.To be honest, this lab is quite realistic mainly because all programmers have to not only write their own codes but review and read other people's code as well. So I found it quite interesting when being matched with Ritik Bheda (a very brilliant Indian guy), who's been working for CGI Toronto 8 months as he said, which means he has a lot of experience. Lucky us, we all used Node to do this assignment.

Me reviewing his code

At the beginning, I had no trouble reading his code because he's done it pretty clean and understandable. But everyone makes mistakes right, he also did :) He had a few typos in his code that could have been tracked by an extension in Visual Studio if he had used it (Code Spell Tracker) but that's no big deal at all Issue on github can be found here. After a few hours reading, I found another thing that could have been improved which is the program version. I read it online saying that the program version can be pulled off of the package.json so we don't need to hard code the program version everywhere Issue on github can be found here. The third problem that I found is quite important and it can lead to severe errors as he forgot to handle cases when users type in invalid files or folders Issue on github can be found here. Other than those small bugs, I couldn't find any other bugs as he did it very well.

Me fixing my issues that he filed

I had no doubt that he would definitely find bugs and errors in my program, and here he goes. The first time he tried to display my program version, it failed LOL. That was my big mistake because I moved all the files into BIN folder but I completely forgot to change relative links in those folders. The other 2 bugs (Not really bugs) that he found out were the options thing. Thanks to his recommendation, I used commander library to fix those 2 issues and it now works perfectly fine.

Wrap up

As we discussed, this is just the very first version of our programs, so it still has problems and edge cases that we have not thought of. But as time goes on, we will get better as well as our program. I'm very happy to work with you in this assignment. Although this is just a very small project that we had together
but I learnt a lot from him like how he handle and simplify different kinds of things.


by Tuan Thanh at Fri Sep 17 2021 16:55:58 GMT+0000 (Coordinated Universal Time)

Kien Nguyen

OSD600 - Week 2 - Lab 1

I find a partner to work with on Slack of OSD600 class. I text few people. Some people reply late or just start working on Release 0.1. Some people have their partners already. Finally, I find Thanh Van to work with. He creates a Static Site Generator with Node Js.

At first, I have some difficulties to run his code. I need to install some required packages to run (which not specify in the README). After all, everything goes fine to test his code. He has few issues on his code. He put all the text file into a single paragraph tag. He has not specify detailed packages needed to install to run the program on README. His code is organized but he needs few comments to explain how it works. The optional features about external stylesheet and specifying output folder work great. I would list some errors or recommendations to improve his code in the Issue Page on his repository:

Also, he gets my code and reviews it. We have hard time to find a way to install required software because I work with C++ and he works with Node Js. We installed MingW and C++17 and everything goes well. After that, I realize I should list more detailed the instructions about system requirements. I edit the README and --help option to give better clarification. You can see his feedback on my page in the Issue Page on my repository:

Reviewing other's code is interesting. This reminds me the knowledge I studied with Node Js. Also, I can see a different way to implement a static site generator. In contrast, it's good to let someone else review my code so I can learn more about the errors that people face with my program so I can fix it.

by Kien Nguyen at Fri Sep 17 2021 16:48:42 GMT+0000 (Coordinated Universal Time)

Xiongye Jiang

Working In Open Source

In order to make our code of Static Site Generator better, we are required to share our code to a partner and try to find out some issues that can make their original code better. And this is the main point that we have Lab 1 in OSD600.

The partner I found was Kunwarvir. I had never met my partner Kunwarvir before. And we just team up randomly. However, although we haven't met each other before, we both treat this sharing code behavior seriously.
After communicated with Kunwarvir, we both started to check our each other's code.

Interesting Stuff

This is the first time that I tried to improve other's code by my own knowledge. I've never thought that I can help people improve their code because I always think that what I known are limited and basic. However, through this Lab 1, sharing code with my partner, I learned something. I learned that there are no perfect code ever, even some beginners can help those experienced programers improve their code. I can help people improve their code as well!

Honestly, the first time I got my partner Kunwarvir's code, I was soooo confused. I felt like there is no way I can help them to improve their code base on my knowledge even though we built the code in the same language -- JavaScript. And then I just told myself, just break it down step by step, make it slow.... And then I just followed the instruction that our professor provided, and check the code step by step. And finally, I found a few issues that can help my partner improve their code! That was amazing to me! And when it comes to the end of the checking, I realized that there are a lot of similar code in our code! And I shouldn't felt panic at the beginning!

There is one thing surprised me in my partner's code. And that is they have a personal logo when the user access their code. So whenever I run their code, it will have a logo comes up like this:


Here are some issues I found in my partner's code:

  • Issue #1 There are some defined variables that never used in the code. const yargs = require("yargs"); const path = require("path"); These two variables are never used in the code, so I suggested my partner to remove them.
  • Issue #2 There is a deletable statement in the code. This statement can be deleted since the output path is set by default.
  • Issue #3 I found that the code my partner shared to me would generate a weird html file. What I mean "weird" is they are trying to divide the article sentences by sentences, but not paragraphs by paragraphs. And then I suggested they write the code with my new code
  • Issue #4 Since I changed one line of code in my partner's code, they need to update another line of code as well.

Here are some issues my partner found in my code:

  • Issue #1 My Index Html is failed at (X)HTML5 validation. There a space in the name of the HTML files that my code generated.

  • Issue #2 My code would convert any type of files that the user input into a html file, which is kind of a stupid feature of my code. We're only supposed to convert .txt file into a html file.

  • Issue #3 My code would convert any type of files inside the folder that the user input into a html file. This is a nonsense feature at all. My code should only supposed to work when it comes to .txt file.

  • Issue #4 My code set that all the html files generated will place into ./dist folder by default. And it doesn't allow any other save path.

  • Issue #5 I didn't have a clear declaration in my README file. And that made a misunderstanding for my partner to access my code.


After reviewing the issues that my partner found in my code. I realized that those are simple and stupid mistakes!

  • For the Issue #1, the main reason that my Index Html is failed at (X)HTML5 validation is my code generated some html files that with blank space in their name. Therefore I update my code to generate html files that without spaces by using the code let validFname = fname.split(' ').join('');.
  • For the Issue #2, I update my code to check the file type fileType = argv.input.split('.').pop(); if(fileType == 'txt'){...} before doing anything.
  • Same for the Issue #3 I update my code to check the file type inside the folder fileType = file.split('.').pop(); if(fileType == 'txt'){...} then convert the files to html files.
  • For Issue #4, I'm not going to fix it right now since it's an optional feature. And there is no harm to force the user save the output html files into a specific folder.
  • And finally about issue #5, I updated my README file so that any new users could run my code easily and correctly.

I know there are more issues in my code that need improvement. And I will try my best to make it better!


Link to my repo: []
Link to Kunwarvir repo: []

by Xiongye Jiang at Fri Sep 17 2021 16:15:11 GMT+0000 (Coordinated Universal Time)

Francesco Menghi

Collaborating via Github

After developing my new Static Site Generator dodo-SSG, I was tasked to work with a classmate to review each other's code.

Hung Nguyen posted on slack that he was looking to collaborate and that he wrote his code in Node. I quickly jumped on the opportunity since my code is also written in Node and I was very interested to see how someone else approached the same assignment.

Providing Feedback

Hung's program is called OSD600-SSG and it is similar to mine in functionality. I found the process of testing the program pretty straightforward. I cloned it, I followed the instructions on the README and everything worked as expected.

I found and filed some issues in his code and also messaged him on slack to understand his point of view. One example is this issue: the program allows as input all types of files instead of allowing only .txt files. It turns out that he misunderstood the instructions and so he wrote the program like that on purpose.

Receiving feedback

This was my first time sending my code for review to a classmate instead of submitting it to a professor. I like the fact that this activity is made to learn from others and to hopefully improve each other's code.
I received some helpful feedback such as this issue. Using the option -v or --version on my program only showed the version number without anything else. I took that feedback and I improved the output to be:

~/repos/dodo-SSG (main) % dodo-SSG -v
dodo-SSG version: 0.1.0


It took me some time to go through Hung's code and to clearly understand all the logic behind it. Since the beginning of my studies at Seneca, I have done a lot of code writing but very little code reading. Everyone has a different coding style so I understand why big projects tend to use clear guidelines when it comes to code formatting (for example using Prettier).

Overall it was a great experience collaborating with Hung and it allowed for the both of us to go back and look at what we could have changed in our code.

by Francesco Menghi at Fri Sep 17 2021 16:02:37 GMT+0000 (Coordinated Universal Time)

David Humphrey

Learning to Review Code

This week's open source lab has the students reviewing each other's code on GitHub.  I've purposely given every student the same programming problem so that they would a) all have the same knowledge about the problem space; b) get to see how another person might solve it in a totally different way.  Above all it's a chance to gain some experience working on both sides of a GitHub Issue before I send them out into the wider world for Hacktoberfest in a couple of weeks.

I've spent some time this morning reading through the blog posts that are already posted to Telescope.  There are some great insights being shared, and I wanted to say something about the various themes I've seen emerging.

The difficulty of estimation in software development

I did start my release 0.1 one night before the due date and did not recognize how rusty I am.

Despite what anyone tells you (including Bill Gates), you can’t do software development effectively at the last minute.  No one can.  Writing code of any length necessarily involves hitting issues you don't expect, the need to do research and learn skills you don't have, and tripping over problems that you can’t see until you’re well into the code.

The trick to software is to give yourself enough time to succeed.  I see a lot of self-sabatoge, where students set themselves up for failure.  You need time to learn, time to debug, time to walk away in frustration, and then time to come back and keep working.  Most of all, you need time to communicate with your partner, team, and community.  Code always involves people, too.

Students often think they can’t code something, but in reality it's just that they can’t code it in the tiny amount of time they've allotted themself.  You're capable of a lot if you give yourself a chance:

At first I was panicking a lot. The problem was that I didn't know the how.  I didn't know the steps. I didn't know where to look. But really - I  did. I just thought it was too much. So I wrote down a checklist and  went one by one. The more progress I made - the easier it became.

Reading other people's code is a skill to be learned

Reviewing someone else's project and having mine reviewed was.... weird...I found their code pretty different.
At first, the idea of reviewing someone else's code is daunting to me. Everyone uses different logic and different tools to implement that logic.
To me, testing and reviewing someone’s code isn’t easy as it involves multiple skills such as communication, knowledge of the programming language/ library, coding, and an open heart to learn new things.

When you mostly read your own code, it can be a lot to jump into someone else's code, and by extension, someone else's head.  We think about problems differently, use different approaches, and favour different styles.

It's useful to recognize that this isn't something that will neccesarily feel natrual or be easy at first.  It takes time to become comfortable being uncomfortable in other people's code.  It takes time, but it will happen.  Keep going.

If you let it, reading other people's code can open your mind to new ideas

It was interesting to look at someone else's way to tackle the same problem
She even checked for empty path input which I did not think about until reading her code.
I was able to learn a lot just from watching my partner code
Seeing how someone else does the same project but with different lines of thinking or logic is really cool.
Even though this is a fairly simple program there are many approaches different people take

If we approach another person's code with an open mind, we can often learn a lot. It's easy to go into a review and only look for the problems.  This is an important part of review, but not the whole story.  Code review is also how we share knowledge in a community, and where we learn about new techniques, tools, algorithms, and approaches. If we can let go of our ego and go into a code review with a willingness to learn, there's often an equal benefit for the person doing the review as there is for the one getting the review.

It won't necessarily feel good to have people critique your code

nervous to have someone review my code
the thought...was horrifying

Why would I ever want to showcase how little I know?  Why would I want to expose my code (and myself!) to ridicule from programmers who are so much better than me?

We put a lot of trust in our reviewers to treat us with respect, and it's imporant that we remember this whenever we are asked to do a review.  Code review isn't only about code: there's always a person behind it.

Putting yourself out there won't always feel good, and yet...

But code review helps me write better code

During the testing and reviewing for her code, I have encountered both minor and major issues.
she was able to find issues that I never realized before
Some things that I was not able to see in my code were found by my classmate and i was able to resolve them
It was interesting to see the obvious things I was missing
The feeling of reading others' codes is amazing, you will not only experience various methods to deal with the same problem, but you will also figure out whether the way you write your codes is optimum or not...I would say, if I did that project alone, I could never find those errors

It's amazing what another set of eyes can see, or how someone running my code on a different operating system can reveal assumptions I was making!  Even after spending hours and hours staring at this code I still miss things that a colleague can spot immediately.

Maybe I'm a good programmer on my own, but I become a great programmer when others are willing to help me review and fix my work.

Other interesting take-aways

the -o or --output option specified in the help section has not been applied yet. I solved this problem by commenting this option out cause I intend to implement that feature in the next version of the tool.

This is a brilliant approach.  Often the best way to fix a bug is to remove the entire feature until it's ready.  Even better than commenting it out would be to move that feature code onto its own branch in git, and keep it out of the main branch until it's ready to ship.

Sometimes, we have a tendency to stick to certain methods to deal with the problems depending on who are your instructors or what kind of documents you follow. This means if the person you are giving feedback to has a different way of writing code, compared to yours, it would be very confusing for you and you might end up having no idea what are they writing and what is the purpose of that line of codes.

I thought this was insightful.  We are all prone to confuse what's familiar with what's correct: "I do it like this because that's how I learned."  What if there's a better way? I think expanding what we know by reading lots of other code helps to mitigate this risk.

...his stylesheet code blew me away and I borrowed his module generateHtmlTemplate.js with properly citing it as his work.  That is the beauty of Open Source like this at Seneca.

I love this.  What would be cheating in another class is exactly the right thing to do here.  Even better would be to take that code and extract it into its own open source library that can be included more easily.  We'll get to that later.

Through communication on Slack and video call on discord we were able to successfully run each other's code.

I thought it was useful to call out how code review can be done both async and sync, and how different tools might be needed.  Talking in a GitHub Issue is fine for some things, but often, hopping into a call on Teams or Zoom, or talking with higher bandwidth in Slack or Discord can sort things out more quickly.  Don't be afraid to use the most appropriate tools.

Having said that, another point worth making is that taking review/discussion to private vs. public spaces is exclusionary.  How does a community learn from and contribute to your work if it all happens in DMs or private rooms?  If you do take a detour into a private meeting, make sure to report back on what was discussed, and which decisions were made (and why) in a public place later (e.g., in the GitHub Issue):

We communicated on problems mostly in slack, but forgot to make issues  for them. So we had solved them before even creating an issue. We had to  make issues later

by David Humphrey at Fri Sep 17 2021 15:04:28 GMT+0000 (Coordinated Universal Time)

Reza Poursafa

Build a static site generator with Commander.js

In my first assignment in open source development, I was tasked to create a CLI tool to create HTML files from text files.

The tool is supposed to accept a file or a folder and either create an HTML from that file or create htmls from all the text files inside the folder.

After lots of research, I found Commander.js, to be a great library for this assignment.

By adding a folder (The ‘text files’ folder in this scenario)as a command, the tool will create HTML files from all the text files inside that folder and place them inside a ‘dir’ folder.

As the created HTML files are derived from an index.html in the main folder, Any styling to the main HTML, I added bootstrap to the index.html to add styles to the texts and also make the page responsive.
I also separated the title from the rest of the text(which would be the first line in the text file) and added styles to it.

The full documentation of my code can be found at my github.

by Reza Poursafa at Fri Sep 17 2021 13:40:42 GMT+0000 (Coordinated Universal Time)