silkie VS cmd-ssg

[metadata] name = silkie version = 1.0.7 ... description = Static site generator with the smoothness of silk long_description = file: README.md long_description_content_type = text/markdown url = https://github.com/oliver-pham/silkie project_urls = Bug Tracker = https://github.com/oliver-pham/silkie/issues classifiers = Programming Language :: Python :: 3 License :: OSI Approved :: MIT License Operating System :: OS Independent [options] packages = silkie python_requires = >=3.9 install_requires = click >= 8.0.0 markdown >= 3.3.0 yattag >= 1.14.0 python-frontmatter >= 1.0.0 [options.entry_points] console_scripts = silkie = silkie.cli:silkie

Last week, I already set up some automation tests for Silkie, my static site generator (SSG). Instead of running tests manually on each Pull Request (PR), I made an attempt to configure GitHub Actions to automate this Continuous Integration (CI) workflow. Moreover, I also helped my friend, Luke, add a test case to his SSG this week.

According to my parter's issue, I create a new test file named. I pull a new PR, the partner's Actions passed it. Before that, I found that many projects have the function of automatic error checking. I wonder how to do it. After lab9, I also created my own GitHub actions. I'm very excited.

After setting up static analysis tools last week, it's time to configure a testing framework for Continuous Integration (CI). There are several options for Silkie, my work-in-progress static site generator, but I decided to give Pytest a try. In this blog, I'll show you how I set up:

If you are tired of maintaining your coding style, I have good news for you. Fortunately, there are developer tools that can automate and streamline mundane development tasks. In this blog, I'll show you how I integrated 2 static code analysis tools and a package manager for pre-commit hooks into Silke, my work-in-progress static site generator.

After wandering the world of static site generators (SSG), I came across an eye-catching, well-documented, and developer-friendly one focusing on documentation sites: Docusaurus. After diving a bit deeper into their documentation, I realized they have many out-of-the-box features, which I can try integrating into Silke, an SSG I wrote from scratch.

This week, I noticed that some functions in my static site generator (SSG) were hardcoded with complex logic and "magic values", so I decided to focus on refactoring them. Without cleaning them up, maintaining them would be a tragedy. For instance, there was a function spanning 36 lines of code with 8 if/elif statements. Some of the statements even have nested if/elif statements themselves. You can find the function referenced in this issue.

This week on my Open Source journey, I attempted to add support for JSON formatted configuration files for an open source Static Site Generator (SSG). The owner of the repo, Tengzhen, also contributed the same feature to my SSG, Silkie. However, I made a step forward by testing his code from a tracking branch before merging it.

After establishing Markdown support for my static site generator (SSG), I decided to enable parsing Markdown horizontal rules along with HTML document language support. However, I developed the two features on separate branches this time, so I could switch between the two if I encountered any obstacle. Little did I know the obstacle was awaiting me at the end.

As for Eugene, he also contributed the same feature to Silkie, my SSG. I noticed his code might need to be fixed and refactored, so we worked together on both Slack and GitHub to resolve those issues. Given our time constraint and Eugene's lack of experience with Python, it was a success that we managed to add a new feature without breaking the existing ones.

After that, I tried to make a test that with errors to check my CI. I updated my code so that it will have an error when I run the tests. And then I made a PR to my repository. When Github receive my PR, it will run the workflow automatically. It will check my PR to make sure it won't crush my original program. Well, there was an warning showed up as I expected: And because there was an error with the PR, there is no way I can merged them to my program. Therefore, I just reset the wrong code to the right one. Then I made the PR again. And this time, it didn't show my the error anymore and I can merge it to my repository. Moreover, for this Lab 9 we need to test other people's CI as well. I found my partner Eugene through Slack. And we talked about what is the good idea for adding a new test function to each repository. Personally, I just added a new small test function to my partner's program. It was a test function about testing what will happen if the user use the function with empty argument. Due to this is not a program that I made, I need to go through my partner's code and followed his logic to made up a test. It's slightly different when adding a test function to a program that you never participated in. But it became easy after you communicated with the program builder!

I have choose to work on JavaScript SSG application that created by Eugene Chung. The testing setup and environment is completely different. He has configured the Node environment whereas I have configured .NET environment on CI. Also the testing environment is different. I have used XUnit for unit testing whereas he has used the Jest for unit testing. However, I have change to work Jest for unit test on WEB422 and previous contribution on Telescope. Also he has excellent CONTRIBUTING.md for providing how to test in his application. Therefore, the testing on my partner's repo is straightforward.

This week, I've been contributing to another static site generator (SSG). I've picked up a few things that may be useful to first time open source contributors:

Testing and reviewing code might sound difficult, but with my previous co-op experience. I got better and better to read someone else code. It is like reviewing a Pull request. No code is perfect, they will be always a bug, improper formatting, unnecessary comment. One of the issue reading his code was the code wasn't properly formatted and they are random comment all over the place. Issue #2, Issue #3. After creating those issue Eugene fixed within a day and the code was much nicer to read.