OSD_SSG VS yassgy

In this post, I will be releasing my little static site generator tool, OSD_SSG, to NPM package manager.

This week lab brought me back working on my genius friend's git repo which you can check out his amazing work hereDukeManh - OSD_SSG

I started to create a Issue#8 on his code, and describe what markdown I will implement to his code. After that, I started to read through his code. It was coded in TypeScript which is the same as JavaScript but with types. The code workflow wasn't hard to follow. I implemented a function to process all markdown features. In that function, I'm calling all other process markdowns to change markdown to HTML. I also added some checks such as only accept .txt and .md. After finishing my code I created a pull request PR#9 and requested Duc Bui Manh to review my change. He gave me some feedback to change. I had some redundant code. After fixing it I pushed back to remote and re-request to review.

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.

To explain for the title, I used to read a post where people interviewed Bill Gate and he has claimed that a good IT student should start to work on their deadlines one night before so as they can practice working under pressure. I did start my release 0.1 one night before the due date and did not recognize how rusty I am. I was panic and did not know where to start at all due to not coding for the whole summer. After that, I have a chance to connect with DukeManh on Slack and he helped me out a lot. You guys can visit his code at: OSD_SSG

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!