glazed-donut VS yassgy

For the past week, I have been researching on where to release my command line interface (cli), glazed-donut.

For this week, I set up a CI pipeline for yassgy with GitHub Actions. I also contributed to glazed-donut, by creating a few test cases.

Throughout the last months while I was working as a Software Developer Intern and on my my ssg repo, I was hardly ever touching front end. I missed working on front-end a lot, so as my first PR for the #hacktoberfest challenge, I decided to take on a small issue related to front end.

This week I was doing some refactoring for my glazed-donut repo. Since its creation, the features kept coming in every week, but there was no refactoring done whatsoever, so... it got pretty messy😅

This time, I've added two features for Glazed-Donut. It now supports the --lang (or simply -l) command, where you can specify a language tag (ex: fr-CA for Canadian French) and it will set the lang attribute in the generated HTML files to whatever value you put. By default, it will set the lang attribute to en-CA. It is done so that the browser can know what language the contents of the file are, and how it can better interpret them.

Irene also added a similar feature to my glazed-donut repo. The feature she has added was a Markdown file support that's able to convert all # into

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.

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.

You can view the project here.

This time, I would like to talk about publishing yassgy to crates.io, and the process I went through, in the case there is a fellow developer who is going to publish their application.

In Rust, there is a similar mechanism, however, there is a slight difference and that is in the fact that it is built-in. All integration tests found in the tests folder can access the application code to test it, if the application code is found in the lib crate. This was the main issue. Before, yassgy had all of the code placed inside the binary crate, making it inaccessible for the tests.

For this week, I set up a CI pipeline for yassgy with GitHub Actions. I also contributed to glazed-donut, by creating a few test cases.

I learned enough Rust to add a feature!!

However, how good is this branching feature? This is what I decided to learn when working on my static site generator, yassgy, by implementing two features on different branches, parallel from each other.

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.

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