DEV Community: Leyang Yu

Finishing Up Release 0.4

Leyang Yu — Fri, 10 Dec 2021 22:20:32 +0000

Intro

Hello! This is my last blog post for OSD600 and this week, I worked on two pull requests for my last assignment. If you've read my previous blog post, I've been working on two issues for Seneca's IPC144 course website repository. The first issue, which I blogged about last week, involves finding a way to convert raster images to SVGs. The second issue, which I worked on this week, involves updating the website style to work for both light and dark modes. This blog post will summarize the pull requests I created for both issues.

Issue 1

This issue was about experimenting with SVGCode to see if it could be used to convert raster images to SVGs. I blogged about this process in my last post. I created a pull request which demoed the results of my research by including several SVGs that I created using SVGCode, Adobe Illustrator and Inkscape. Overall, I think that Inkscape produced the most consistent results for coloured and black and white images compared to other tools I tried, which I mentioned in my PR.

Issue 2

For this issue, I had to come up with a strategy for styling that would work in both light and dark modes. For example, some table cells in dark mode originally had white text on a yellow background, which is very hard to see:

I went through the pages of the site and other than highlighting and image backgrounds, I didn't notice any major issues that appeared due to using a specific mode.

For the highlighting issue, I decided to stick with the yellow background in light mode and for dark mode, I decided to use a different colour since the yellow seemed too bright on a dark background:

Light Mode

Dark Mode

I did this by creating a class called highlight and applying different styles depending on the mode:

.highlight {
  background-color: rgb(255, 255, 224) !important;
}

html[data-theme='dark'] .highlight {
  background-color: rgb(72, 77, 91) !important;
}

In addition I added a white background to all images for both modes, since some images looked a bit weird on a black background:

Before

After

I did this by adding a white background when the site is in dark mode:

html[data-theme='dark'] p img {
  background-color: rgb(255, 255, 255);
}

Conclusion

As of this blog post (Dec 10), I haven't received any reviews on my pull requests from the maintainers. For the SVG issue, I don't expect my changes to get merged as the issue was just to experiment with SVGCode to see if this tool could be used in the project and the SVGs I included in the pull request were just samples of what I came up with based on my research.

When starting off this assignment, my goal was to work on open-ended front-end issues that allowed me to be more creative. For my PRs, I was able to experiment with a variety of image editing tools, some which I've used before, such as Inkscape, and others which were new to me, such as SVGCode and Adobe Illustrator. I think this will be useful when I work on future projects involving different image formats. I was also able to experiment with different styles for light and dark modes. Overall, I think this was a great end to a wonderful course and I hope to continue contributing to the open source community even after completing OSD600. Thanks for reading!

Converting Raster Images to SVGs

Leyang Yu — Sat, 04 Dec 2021 01:11:54 +0000

Intro

In a previous post, I mentioned working on an issue for converting raster images to SVGs. This week, I did some research on the tool recommended in the issue, SVGCode, as well as other popular tools and in this post I will be discussing some of what I learned after trying them out. For the tools that I tried, I wanted to find something that is free and easy to use, while still being able to create high quality SVGs, as there are a lot of images to convert. (Disclaimer: I'm pretty new to working with images and image editing software so I'm probably not using all the right terminology here, but I'm trying to learn!)

SVGCode

After watching the video tutorial and testing out the different settings, this is what I could come up with for one image. It looks decent here, but upon zooming in:

You can see that the outlines don't look great. I tried to de-speckle the image in order to create smoother outlines, but this left a lot of white space that I tried to fill using other methods such as by increasing stroke width, but the result wasn't much better.

Although I think this tool is great considering it's free and very easy for anyone to learn and use, I decided to try out a few others to compare and see if I could get better results.

Adobe Illustrator

Another tool I tried was Adobe Illustrator, which luckily I have access to for free through my school!

Personally, I liked the results using Adobe Illustrator and it was surprisingly easy to use as well. All you have to do after selecting an image is click on "Image Trace" in the toolbar and choose a preset.

For this particular image, I found that "High Fidelity Photo" produced the closest result to the original image, but depending on your image, other presets may be more suitable.

Here is an example of the image zoomed in, which although is not perfect, seems to be much cleaner compared to the image created through SVGCode.

Inkscape

I also tried using Inkscape, which I had a bit of experience working with before in a previous project, where I modified an SVG logo. This tool was pretty easy to use as well. From the toolbar, you can click on "Path" and select "Trace Bitmap":

After doing so, you should see this box appear, which allows you to customize the image that you wish to convert:

For this image, there are 8 colours so I chose to do 8 scans and you can see the result below:

The top image is the original whereas the bottom image is the converted vector. However, upon zooming in, the SVG doesn't look that great:

Vector Magic

Vector Magic is a free online image conversion tool that I found. I think it's great because, like SVGCode, you don't need to download anything and you can edit the image right in your browser.

Here are some images of the results. For a free program, I think the results are pretty decent but it's not as customizable as Illustrator, for example.

Conclusion

Overall, I learned a lot about different image conversion tools and hope you did as well after reading this blog post. Next week, I'll be creating a pull request with my different findings and suggestions and I'll be blogging about this as well. Thanks for reading!

Publishing My First NPM Package

Leyang Yu — Sat, 27 Nov 2021 03:25:05 +0000

Intro

I published my first package, jellybean, to npm! I actually published the package back when I first created the repository in September, just to experiment. However, it didn't work back then and I kind of forgot about it after that. This week, I fixed up the issues I was having and now it works. 😊 In this post, I'll be explaining the process of how I published the package and fixed the issues I previously encountered.

Preparing a Project to be Published

I decided to publish my program to npm since it's the most common package manager for JavaScript programs. There are a few steps I followed in order to prepare the program to be published. First, in the package.json file, I added main and bin parameters. In addition, you need to have name and version parameters as well. For example, here is a snippet from my package.json file:

{
  "name": "jellybean",
  "version": "1.0.10",
  "description": "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/markdown files into HTML.",
  "main": "src/index.js",
  "bin": {
    "jellybean": "src/index.js"
  }
}

Name and version are pretty self-explanatory, but main specifies the main entry point into the program and bin specifies the command to run the associated executable file. In this case, when a user runs the command "jellybean" after installing the package, the file "src/index.js" will be executed. In addition, each time I published to npm, I incremented the version and if you forget to do so, you will receive an error message.

In addition, I added the line:

#!/usr/bin/env node

To the top of the file to be executed ("src/index.js" in this case), which specifies that the program should be run in a node environment.

Testing the Project

Before publishing to npm, I tested the program by running:

npm link

From within the same directory as the repository. Then I ran the program as if it had already been published (eg. running jellybean --version would print the version number, etc.). You can read more about how to use npm link here.

Publishing the Project

Next, I published the program by running the commands:

npm adduser
npm publish

npm adduser creates or links to your npm account. npm publish publishes your package, which you should run each time you want to update your package.

Problems I Encountered

Although the steps described above are quite simple, I encountered some problems along the way. Because I originally published the package in September and installed it, I had an older version of the jellybean files in my C:\Users\...\AppData\Roaming\npm folder. Therefore, every time I tried to run the jellybean command, I got the following error:

& : The term '/user/bin/env.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.

I fixed this issue by deleting the old files from the npm folder and once I published my package to npm, I reinstalled it globally and was able to successfully run the program.

Testing

I partnered with another student from my class, Suhhee, in order to test each other's programs. When Suhhee tested my program, she received the following error:

Error: ENOENT: no such file or directory, open 'src/layout.html'
    at Object.openSync (fs.js:498:3)
    at Object.readFileSync (fs.js:394:35)
    at getHtmlLayout

Because of this, I changed my file paths from relative to absolute paths using path.resolve() so that the program can be run from any directory. For example instead of:

return fs.readFileSync(
        'src/index.html',
        'utf8'
    );

I updated the code to:

return fs.readFileSync(
        path.resolve(__dirname, '../src/layout.html'),
        'utf8'
    );

Conclusion

In conclusion, the process of setting up an npm package was pretty straightforward, other than a few problems that I was able to resolve. Over the past almost three months, I've been working on this project every week and getting to publish it was a great end to this journey. If you're interested in trying out the program, you can read more about it here or run:

npm install -g jellybean
jellybean --help

To get started. Thanks so much for reading!

Finding Issues to Work On

Leyang Yu — Fri, 26 Nov 2021 21:19:05 +0000

Intro

For my open source class, our next assignment is to find and contribute to a larger and more impactful issue compared to previous assignments. I'll be working on this over the next three weeks and blogging about my goals, progress, and results during this time. In this first week, I would like to talk about the process of finding a project and issues to work on and my goals for this assignment.

Finding a Project

For this assignment, I wanted to continue my work on the IPC144 repository, which is the course notes repository for the IPC144 course. Previously, I had submitted a PR and also completed code reviews for other PRs for this repository. I want to continue working on this project on a deeper level and hopefully provide some fixes for things that I was not able to accomplish in the previous PR, which I'll explain in the next section.

Finding Issues

One of my goals for this assignment is to work on something related to the front-end/UI as this is the area of development I am most interested in. In addition, I want to work on more open-ended issues that allow me to be more creative and come up with new ideas or solutions. Therefore, when I saw these two issues in the IPC144 repository, I was really excited to work on them:

Issue #1: Figure out highlighting colour(s) and strategy for light and dark mode
Issue #2: Experiment with converting Raster images to SVGs

These two issues were both problems that I had encountered while working on my previous PR for this repository. For example, in my previous PR, I converted all tables from HTML to images due to sizing issues on different screen sizes. However, the images were a bit blurry, especially if you zoomed in, so I don't think the current solution is ideal. Therefore, I'm really interested in doing more research about SVGcode, which converts raster images to SVGs, to see if it would be a possible solution. In addition, another problem I previously encountered was dealing with tables and images in light vs dark modes, so in the upcoming weeks, I'll be working on a solution that allows pages to look great in either mode.

Approaching the Issues

Next week, I'll be doing more research on SVGcode. The issue links to a video tutorial which I will be following along with to convert a few raster images from the repository to see if and how it works. The issue regarding light and dark themes also links to a Docusaurus page, which provides more information on how to create styles for different themes. I will be testing this out and also experimenting with different colours to see what would be most suitable for the light and dark themes of the website.

In the next week, I will be blogging about my progress on these two issues so far and any problems I've encountered or solutions I've come up with. Thanks for reading!

Contributing to an Open Source Browser Extension

Leyang Yu — Sat, 20 Nov 2021 00:35:56 +0000

Intro

I've always wanted to try making my own browser extension and this week, I had the opportunity to contribute to a open source browser extension project called OpenLorem. I found OpenLorem while browsing through issues on GitHub and saw that they had several smaller issues open. In this post, I'll be talking about the issues I worked on, the difficulties I encountered, and what I learned during this process.

Setting Up the Project

Setting up an extension for testing was surprisingly easier than I expected. After forking and cloning the repository to my computer, I could try out the extension in the following ways:

In Firefox, go to about:debugging#/runtime/this-firefox and click the "Load Temporary Add-on..." button. Then upload the manifest.json file.
In Chrome, go to Settings and then Extensions. In the top right, there will be a toggle switch to turn on Developer Mode, which needs to be switched on. Then click "Load unpacked" and upload the folder containing the manifest.json file.

The first and second issues

The first two issues were fairly simple and small fixes. The first issue was a CSS fix whereas the second issue was finding a way to safely insert HTML into the DOM.

As you can see, the CSS for the Contributors list before didn't look great. All I had to do was add a class selector to the <ul> tag and apply some CSS to it to remove the bullet points.

In the HTML:

<ul class="contributors-list">

In the CSS:

.contributors-list {
    list-style-type: none;
}

After the fix, the CSS looks better.

The second issue was that a user could directly insert the generated text into the HTML via the context menu, but the innerHTML method being used was unsafe.

The repo owner suggested looking into the DOMParser.parseFromString() method. I did so and I found out that this method takes in a string containing HTML or XML and returns and HTMLDocument or XMLDocument. In this case, we are working with an HTML string, so parsing it would look like

let loremText = new DOMParser().parseFromString(request.text, 'text/html')

Then, in order to get the contents of the <body> tag, I did:

let loremText = new DOMParser().parseFromString(request.text, 'text/html').body.childNodes;

Finally, in order to replace the section of HTML with these child nodes, I used the replaceChildren() function like:

clickedElement.parentNode.replaceChildren(...loremText);

The third issue

The third issue took a bit more time. This issue involved modifying the icon for the extension because it had black text on a transparent background and was very hard to see in dark mode. At first I thought I could just change the transparent background to white, but the owner requested that I update the SVG as well and use this file to create the icons. I have never created or modified an SVG before, but I saw that the SVG that OpenLorem is using was created using Inkscape so I downloaded this program.

Through some tutorials, I learned how to add a background, center it, and also how to modify the shape of the background, as the owner requested rounded corners.

<rect
       style="fill:#ffffff;stroke-width:0.937212"
       id="rect1425"
       width="354.33212"
       height="353.82001"
       x="0"
       y="698.78735"
       ry="86.73204"
       inkscape:export-xdpi="4.0640001"
       inkscape:export-ydpi="4.0640001"
       transform="matrix(0.999996,-0.0028271,0,1,0,0)" />

This was the bit of XML code generated after I made my changes. I made the modifications to the SVG file and exported these changes to PNG files to be used as the new icons.

You can see the results of these changes in the icons here.

Conclusion

Overall, I learned so much through contributing to this repository. I was able to work on a browser extension which is something I've never tried before and I also learned how to create SVGs and custom icons.

Thanks for reading!

Reviewing Code in a Class Repo

Leyang Yu — Fri, 19 Nov 2021 18:28:26 +0000

Intro

In another post, I talked about contributing to a course website repository for a course at my school. I audited and fixed a markdown page and received a lot of great feedback and reviews from my classmates. In this post, I would like to talk about my experience reviewing other pull requests in the same repository.

Review #1

This pull request looked really good and there were not a lot of things to fix. However, I did find some small typos, which I mentioned to the author.

For example "We store the SKUs" instead of skus and "[...] the algorithm picks [...] and swaps the values [...]" instead of swap.

Review #2

This pull request was really good as well, but one thing I noticed right away was the sidebar:

The String Functions section describes the functions that will be explained later, including String Length, String Copy, String Compare, and String Concatenate. However, all five of these sections had the same heading level. I suggested that perhaps the latter four section headers could be one level down since they were subsections of the larger String Functions section. The author agreed with my suggestion and changed the headings from second to third level so that the sidebar now looks like:

Review #3

In the last code review I did, I made a few suggestions to the author. First was the Frontmatter, which initially only included the navbar/sidebar position. I suggested adding more details to the Frontmatter, such as id, title, slug, and description.

Instead of:

---
sidebar_position: 1
---

The Frontmatter now looks like:

--------
id: computers
title: Computers
sidebar_position: 1
slug: /introduction/computers
description: This chapter will teach you about the major components of a modern computer and the software that controls them.
--------

I also suggested adding some intra-site links where it may be useful to users as well as adding descriptive text to links. For example, the first paragraph of the page mentions algorithms and libraries, which are other pages on the site. After adding links and descriptive text, it now looks like:

Which is useful if a user wants more information about related topics.

Finally, I also found a couple of typos which I mentioned and these were fixed as well.

Conclusion

As I mentioned in my previous post about contributing to this repository, it was great to work on these issues as an open source community. I learned a lot from reviewing other people's code and it was interesting to see the different ways in which everyone approached similar tasks. Overall, I hope these reviews will help improve the quality of the code and create a better and more consistent website.

Contributing to a Class Repo

Leyang Yu — Fri, 19 Nov 2021 07:42:00 +0000

Intro

One of the courses I previously took at Seneca, IPC144, is getting a major overhaul to their website, and through my open source class, I had the opportunity to contribute to this project. There was a huge meta issue with all the pages that needed to be updated and I decided to take on the task of auditing and fixing the arrays.md page.

Approaching the Task

If you take a look at the issue, there was quite a significant list of things to be completed. I first forked and cloned the issue, created a new branch for my issue (called issue-40) and started up the website to see how it looked. After this, I tackled the list one by one, checking off tasks as I completed them and creating commits for each one.

Some of the changes I made included:

fixing typos
adding intra-site links and adding descriptive text to links
adding Frontmatter

---
id: arrays
title: "Arrays"
sidebar_position: 1
slug: /data-structures/arrays
description: "An array is a data structure consisting of an ordered set of elements of common type that are stored contiguously in memory."
---

adding syntax highlighting
fixing some HTML that was causing console errors

For example, in the HTML tables, there were no <thead> or <tbody> tags which caused the <tr> cannot appear as a child of <table> error and the columns were using colspan instead of colSpan.

I pushed all these changes to the issue-40 branch and created a pull request in the main repository.

Receiving Reviews

I received so many helpful reviews to my pull request. For example, the image on the page was difficult to see in dark mode and I had forgotten to add alt text. Two of my classmates, Tengzhen and Minsu pointed these out to me and Tengzhen suggested that I could save the image and add a white background so that the black text would still be visible on a black background.

This is what the image looked like before. As you can see, the circled text is barely visible in dark mode.

After the fix, it's clearer.

Jerry suggested that I could convert the tables to images since the tables didn't look great on all screen sizes and in his case, he needed to scroll to see the full table.

This is how a table looked for Jerry.

After the fix, all the tables are images and resize according to the page size.

Finally, Kien pointed out a typo as well as a broken link on the page.

Conclusion

Although I had checked over my work before creating the pull request, I guess the great thing about open source is even if you miss something, you can get a lot of great input from others and suggestions on how to make things even better. It was a bit overwhelming working on such a large meta issue because everyone had different ways of approaching the same tasks, but it was a great learning experience and made me very appreciative of working with an open source community.

Adding Continuous Integration to a Project

Leyang Yu — Fri, 19 Nov 2021 03:52:01 +0000

Intro

After writing a few unit and E2E Integration tests for my static site generator, Jellybean, last week, this week I added Continuous Integration to the repository. It was very easy to set up and is useful if you or other contributors forget to manually test while making changes. It ensures that changes or pull requests made to the main branch are automatically tested by running a workflow.

Setting up GitHub Actions CI Workflow

The process of setting up the workflow was very simple. In the "Actions" tab of my repository, I selected a workflow template for my program. In my case, I selected the Node.js template, which automatically created a .github/workflows folder in my repository containing a node.js.yml file:

# This workflow will do a clean install of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions

name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

The only thing I changed in the default template was the supported Node versions. By default, versions 12.x, 14.x, and 16.x are supported. However, I was using a function in my program called fs.rmSync(), which is not supported in version 12.x and I was running my program on version 14.17.5. Therefore, I decided to remove the option for version 12.x from the template and put a note about which version of Node to install in the README and CONTRIBUTING.md files.

For my own project, I wrote a few more unit tests for two functions, just to ensure that the workflow was properly set up and working and my changes passed all the checks. I merged these changes to the repository.

I also worked on another project, mh-ssg, and added tests to this project as well. I created unit tests for a function called processFolder(). This function accepts an input folder path, output folder path and stylesheet URL. I created two unit tests, one which tests when a valid input folder containing files is passed to the function and one which tests when a non-existent folder is passed to the function. The function logs a message to the console depending on how many files are saved in the output folder, so the tests I wrote tested for these console logs.

const MOCK_FILE_INFO = {
    "/path/text.txt": "Hello World!",
    "/path/markdown.md": "This is a markdown file",
    "/output": []
  };

  beforeEach(() => {
    require("fs").__setMockFiles(MOCK_FILE_INFO);
  });

This part of the code sets up a mock file system. This is different from my own tests, as I used a real file system, but I think that in the future, I will change to using a mock file system as well because it reduces the need to create extra files.

  test("should log success message to console", () => {
    const mockSpy = jest.spyOn(console, 'log');
    processFolder("/path", "/output", "https://cdnjs.cloudflare.com/ajax/libs/tufte-css/1.8.0/tufte.min.css");
    expect(mockSpy).toHaveBeenCalledWith(`${chalk.green(
      `2 file(s) saved to folder /output successfully!`
    )}`);
  });

  test("should log success message to console", () => {
    const mockSpy = jest.spyOn(console, 'log');
    processFolder("/nonexistent", "/output", "https://cdnjs.cloudflare.com/ajax/libs/tufte-css/1.8.0/tufte.min.css");
    expect(mockSpy).toHaveBeenCalledWith(`${chalk.green(
      `0 file(s) saved to folder /output successfully!`
    )}`);
  });

This part of the code contains the tests. I had to do some research on how to capture console logs in my tests and I discovered the jest.spyOn() function. By assigning mockSpy to jest.spyOn(console, "log"), I spied on the console.log function while running the function I was testing, and I could check to see whether it was called and the arguments it was called with. When passing a mock directory with two valid files, I expected console.log to have been called with:

`${chalk.green(
      `2 file(s) saved to folder /output successfully!`
    )}`

(Chalk is used to style the console output)

However, when passing a directory that doesn't exist, I expected console.log to have been called with:

`${chalk.green(
      `0 file(s) saved to folder /output successfully!`
    )}`

My tests passed and I created a merge request to the repository. The repository owner, Minh Hang, approved running the workflow on my pull request, which passed, and merged my changes.

Minh Hang also created a PR for adding tests to my repository. When creating a PR in a repository for the first time, usually the owner needs to manually approve running the workflow and Minh Hang's changes looked good to me so I did so and all the checks passed. I was able to merge her changes into my repository as well.

Conclusion

If you work on any repository with others, you will probably come across CI sooner or later. Almost every repository I've contributed to uses them and sometimes my changes would work locally but fail when I created a merge or pull request and it would be hard to figure out why as I had never used CI in my own projects before. After learning more about testing and CI, I understand the benefit and importance of using them in projects and will continue to use them in the future.

Testing Using Jest

Leyang Yu — Fri, 12 Nov 2021 22:20:44 +0000

Intro

This week, I continued working on my static site generator Jellybean and focused on creating and running tests for the program. I decided to use Jest for testing because it was what was recommended and also because I have tried other tools such as Jasmine and Karma before, but not Jest, so I thought this would be a good opportunity to learn how it works.

Testing Process

By following the documentation, I installed Jest by running:

npm install --save-dev jest

and adding:

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch --",
    "coverage": "jest --collectCoverage --",
  }
}

to the scripts in my package.json file. This allows the user to choose from three different commands to run tests:

npm run test specifies that the tests should be run.
npm run test:watch specifies that the tests runner should watch for changes and if a change is made, the tests will be run automatically.
npm run coverage specifies that the tests should be run and a coverage report should be automatically generated.

During this process, I created two types of tests. I created unit tests for a specific function in my program and E2E integration tests to test the entire program.

The function I decided to test with unit tests is called getHtmlNav, which accepts a string or array as an argument and returns the navbar of a page as a string.

For example:

test('Creates navbar with link to index page', () => {
    expect(getHtmlNav()).toBe(
        `<div><ul><li><a href='./index.html'>Home</a></li></ul></div>`
    );
});

When no arguments are passed, the function should return a navbar with a single link to the index page.

test('Creates navbar with link to index and user-defined pages (array of files)', () => {
    expect(
        getHtmlNav([
            'Silver Blaze.txt',
            'The Adventure of the Six Napoleans.txt',
        ])
    ).toBe(
        `<div><ul><li><a href='./index.html'>Home</a></li><li><a href='./Silver Blaze.html'>Silver Blaze</a></li><li><a href='./The Adventure of the Six Napoleans.html'>The Adventure of the Six Napoleans</a></li></ul></div>`
    );
});

When an array of strings is passed, the function should return a navbar with links to the index page and pages that are passed in the array (but the extension should be changed from .txt or .md to .html). There are several other scenarios, such as when a string is passed or when an empty array is passed, which I also tested for.

In addition, I created E2E tests for the entire program.

I created a file called run.js which runs the program using execa and another file that contains the tests. An example of an E2E test would be:

    test('Print error message when no input', async () => {
        const { stderr, stdout, exitCode } = await run();
        expect(exitCode).toBe(1);
        expect(stderr).toMatchSnapshot();
        expect(stdout).toEqual('');
    });

Which runs the program with no command line arguments. This expects the exitCode to be 1 with a stderr because arguments are required.

One thing that my program didn't test for previously was a input folder that was empty. If a folder does not contain any .txt or .md files, then the program should not continue and should instead return an error message prompting for valid input.

    test('Prints error message when empty folder', async () => {
        const { stderr, stdout, exitCode } = await run(
            '--input',
            'invalid-folder'
        );
        expect(exitCode).toBe(1);
        expect(stderr).toMatchSnapshot();
        expect(stdout).toEqual('');
    });

This was the test that I wrote for the scenario and I had to go back and change my code so that if an input folder was empty or did not contain any valid files, the program would return an error:

let files = fs.readdirSync(input);
                    let filesArray = files.filter(
                        (f) =>
                            path.extname(f) == '.txt' ||
                            path.extname(f) == '.md'
                    );
                    if (filesArray.length == 0) {
                        console.error('Input directory is empty.');
                        process.exit(1);

I created a testing branch to add all of these changes and I used an interactive rebase to squash all the changes together and merged them with the main branch.

Conclusion

Although testing is an essential part of software development, I don't have much experience with writing or running tests so this was a great opportunity to learn about two types of tests, unit and E2E integration tests. The tests I have written only cover a small portion of what is required for the entire program so I will definitely need to make adjustments in the future. However, I will definitely continue using the the tools and skills I learned during this process in my future projects.

Formatting and Linting for JS

Leyang Yu — Sat, 06 Nov 2021 00:23:52 +0000

Intro

This week in my open source development course, we learned all about Static Analysis Tooling. Although I've worked on several projects that used tools such as Prettier, ESLint and Husky, I have never actually gone through the process of setting up these tools for other developers to use in my own projects. I added these tools to my static site generator, Jellybean, and I'll be talking about the process in this post.

Prettier

I chose Prettier as the code formatter for my project, as I have used it before and it's probably one of the most well known code formatters for JavaScript. Following their installation guide, I was able to get Prettier installed by running the following commands:

npm install --save-dev --save-exact prettier
echo {}> .prettierrc.json

The second line echo {}> .prettierrc.json caused an error, but thankfully, a few of my classmates also encountered this error and I learned that it was because Windows uses Unicode UTF-16LE encoding by default, but JSON files are encoded in UTF-8 by default. By running the command through Command Prompt, I was able to bypass this issue and successfully create the .prettierrc.json file.

In my .prettierrc.json file, I added the following configurations. There are many other options available, which you can find in the Prettier docs.

{
    "trailingComma": "es5",
    "tabWidth": 4,
    "singleQuote": true
}

I added the following to the scripts in my package.json file:

    "prettier": "prettier --write .",
    "prettier-check": "prettier --check .",

And ran Prettier using npm run prettier. This changed my code quite a bit. For example, Prettier added newlines in many places, semicolons where I had missed them before, and wrapped function arguments in parenthesis, among other changes.

ESLint

Like Prettier, ESLint is a very commonly used tool that I see often so I chose it as the Linter for my repository.

Again, I followed the installation docs and was able to install it quite easily by running these commands:

npm install eslint --save-dev
npx eslint --init

When running the second command, you can specify details about your project through the command line such as what framework it uses, where it runs, etc. which is used to automatically generate a configurations file:

(Note: For "Where does your code run?", it should actually be "Node" instead of "Browser" and I had to go fix this in the config file later.)

I also added the following to the scripts in the package.json file:

    "eslint": "npx eslint .",
    "eslint-fix": "eslint --fix .",

After checking my code with ESLint, I got one error from this line:

md = new markdownit();

ESLint showed the error ""'md' is not defined no-undef" and once I added the keyword "let", such as:

let md = new markdownit();

This problem was resolved. 😀

Integrating With VSCode

First, I installed the Prettier and ESLint extensions in VSCode. After doing this, in the Command Palate, I searched for Configure Recommended Extensions (Workplace Folder). This creates an extensions.json file in your .vscode folder and you can add the extensions to your project by right clicking on an extension once it has been installed and selecting Add to Workspace Recommendations, as shown below:

In the end, I added these two recommendations to my extensions.json file:

"recommendations": ["esbenp.prettier-vscode", "dbaeumer.vscode-eslint"],

For settings, I created a settings.json file in the .vscode folder.

You can see a list of possible options in the dropdown menu when you start typing. These are the configurations I added to my settings.json file:

{
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": true,
    "eslint.lintTask.enable": true
}

Husky

The last step was to add a pre-commit hook, which checks staged files before you commit. I decided to use Husky because I had heard of this tool before and it seemed like a popular choice as well.

I ran the following commands:

npm install husky --save-dev
npm set-script prepare "husky install"
npx husky add .husky/pre-commit "npm test"
git add .husky/pre-commit

The first line installs Husky, the second line adds a script to the package.json file, and the last two lines add the pre-commit hook.

In the .husky/pre-commit file, I added the following lines:

npm run prettier
npm run eslint

To run Prettier and ESLint before a commit is made.

Last but not least, I documented all these changes in a CONTRIBUTING.md file so that anyone who works on the project in the future will understand what tools are used and how to work with them.

Conclusion

I'm so glad I had a chance to learn about Static Analysis Tooling. Although I have used some of these tools before in other projects, I didn't have experience configuring them or adding scripts to run them from the command line, so this was a really useful exercise.

I have worked on large-scale projects in the past where everyone was using their own way of formatting and it was a bit of a mess and sometimes very frustrating. By having a standard for formatting and checking the code, it simplifies the process of collaborating with others and I will definitely keep this process in mind when creating other projects in the future.

Hacktoberfest Recap

Leyang Yu — Sun, 31 Oct 2021 18:29:05 +0000

I finally completed my first Hacktoberfest!!! 🎃🎃🎃 To recap, here are the issues and PRs that I worked on over the past four weeks:

Week 1:

Issue, Pull Request, Blog Post

Summary:

During the first week, I was feeling really overwhelmed with trying to find an issue to work on. I decided to tackle something I was relatively confident about working on, which was UI, and I fixed a UI bug in the Telescope project. Although it was a small styling fix involving just a few lines of code, I learned the basics of working on an issue, creating a pull request, and getting my code merged into the main repository.

Week 2:

Issue, Pull Request, Blog Post

Summary:

I worked on creating updated issue forms for the Openverse Catalog repository, by converting their existing issue templates from markdown to YAML. I learned about issue forms, YAML syntax, and for this pull request, I received a lot of feedback on my changes, which I fixed before my pull request was successfully merged.

Week 3:

Issue, Pull Request, Blog Post

Summary:

This week, I was really interested in working on a bigger repository and I like React so Microsoft's Fluent UI repository seemed like a good choice. However, after working on the issue, I didn't receive any reviews on my pull request. I think that maybe this was because the issue was created by someone that wasn't a regular contributor to the repository and perhaps this change wasn't required. Therefore, even if a repository has the "Hacktoberfest" label, I think it's important to check if the code maintainers are active in an issue before working on it.

Week 4:

Issue 1, Pull Request 1, Issue 2, Pull Request 2, Blog Post

Summary:

Since my third pull request did not get reviewed, I decided to work on two issues in my last week. Because Hacktoberfest was coming to an end, I really wanted to challenge myself to try something new and out of my comfort zone. I worked on form validation in Angular and added a feature to a game in Python. I was honestly so surprised to find out how much I could accomplish using a completely new language (Python). The scope of these two issues was definitely much bigger than the issues I've worked on previously and I think it was a great way to end off an eventful month.

Conclusion

Overall, I learned a lot and also made some mistakes along the way:

I always avoided issues that had comments because I thought that this meant someone else was already working on them. However, I think these issues are still worth taking a look at. Sometimes, it's just the code maintainers providing input on the issue.
I wanted to work on some larger projects at first because it seemed they had more activity and more issues, but I realized that smaller repositories are also a great way to find issues. You can work on larger issues (because there are fewer contributors) or issues that are more beginner friendly (if it's a repository that's just getting started for example).
Last but not least, it may seem daunting to take on an issue in something you've never worked with before (such as a new language) but I think this event is a perfect opportunity try something new and you will be surprised by what you can get done.

I'm so grateful that my open source development course and professor introduced me to this event and it was such a great experience to both learn and improve as a developer and contribute to the open source community!

Hacktoberfest Week 4

Leyang Yu — Sun, 31 Oct 2021 16:55:09 +0000

It's the fourth and last week of Hacktoberfest. My third PR that I submitted last week wasn't reviewed, so for this final week, I decided to work on two different issues, one of which was for a recipe app written using Angular and another which was a Space Invaders game written in Python.

Foodilo

The issue
The pull request

The Issue

I found this issue interesting because I have also worked on a recipe app in the past using React. However, this project was written using Angular, which I am not as familiar with. I wanted to challenge myself this week so I thought this would be a good place to start.

For this issue, the main problem was that for the Sign Up form, the password and confirm password fields should have matching inputs before the form can be submitted. However, the validation was not working and therefore, a user could submit the form with different passwords.

The Code

The program uses a Directive to compare whether or not the inputs are the same. The problem before was that the input was not being correctly passed to the validate() function, which I rewrote in my pull request:

export class MustMatchDirective implements Validator {
  @Input('appMustMatch') appMustMatch: string;

  constructor() {}

  validate(control: AbstractControl): ValidationErrors {
    let confirmPassword = control;

    let password = control.root.get(this.appMustMatch);

    // return null if controls haven't initialised yet
    if (!password.value || !confirmPassword.value) {
      return null;
    }

    // return null if another validator has already found an error on the matchingControl
    if (password.errors) {
      return null;
    }

    // set error on matchingControl if validation fails
    if (password.value && password.value != confirmPassword.value) {
      return { appMustMatch: false };
    }

    return null;
  }
}

The argument passed to the function, control is used to get the confirmPassword field and control.root.get(this.appMustMatch) is used to get the password field since I added the property appMustMatch="password" to the HTML tag for the confirmPassword field. To be honest, I don't have much experience with form validation in Angular and it was my first time using Directives, so this tutorial greatly helped me understand how to approach this issue.

Feedback

After the changes were made, you can see that if the passwords don't match, the form will show an error and the Sign Up button will be disabled. After I submitted this pull request, it was promptly accepted and successfully merged.

Atari Space Invaders

The issue
The pull request

The Issue

I wanted to work on this issue because I really liked the project and it is also written in Python which I have no experience with but want to learn.

The issue was that the game had a default size of 750x750 pixels, but the project owner wanted to add the option to run the game in full screen mode.

The project uses pygame, which provides a lot of built-in functions and features to create games.

The Code

First I created a class that has a function to toggle between default and full screen modes, which is triggered by pressing [f]:

class DisplayControls:
     def toggle_full_screen():
        screen = pygame.display.get_surface()
        if (screen.get_flags() & pygame.FULLSCREEN):
            pygame.display.set_mode((750, 750))
        else:
            info = pygame.display.Info()
            pygame.display.set_mode((info.current_w, info.current_h), pygame.FULLSCREEN)

display_cfg = DisplayControls

I also added the following label to the screen:

        sfx_label = control_font.render('Toggle Full Screen', 1, (0, 225, 0))
        CANVAS.blit(sfx_label, (starting_x + 125, 655))
        sfx_key_label = keys_font.render('[f]', 1, (240, 0, 0))
        CANVAS.blit(sfx_key_label, (starting_x + 470, 655))

The hardest part about this issue for me was that the aspect ratio of the game was a square and had to be centered in full screen mode. Because each element was placed on the screen individually, I had to reposition everything. This is the method I used to center the background in the middle of the screen:

         screen_rect = CANVAS.get_rect()
         centerx = screen_rect.centerx
         x = centerx - self.rectBGimg.width / 2
         CANVAS.blit(self.bgimage, (x, self.bgY1))
         CANVAS.blit(self.bgimage, (x, self.bgY2))

The first two lines determine the center of the window and self.rectBGimg.width / 2 determines half the size of the background. By setting the starting x coordinate to centerx - self.rectBGimg.width / 2 instead of 0, this centers the background in the middle of the screen. I used a similar formula to place all other elements onto the screen.

Feedback

The repository owner provided a lot of feedback on my changes.

The first was that when playing the game using a mouse, the ship would move off the screen. Although this problem wasn't introduced by my code, it became apparent once the game was in full screen mode because there was blank space on either side of the game and the pixels would get stuck once the ship moved out of bounds.

Second of all, the way I implemented the toggle full screen was using a key up event. However, the repo owner wanted the user to be able to click the maximize button in the title bar. After some discussion through Discord over how this can be achieved using pygame, we came to the conclusion that the scope of this change would be greater than a simple toggle between default size and full screen and so I agreed to create a new issue after Hacktoberfest to continue working on this.

Conclusion

Although it was a bit stressful working on two issues in the last week and particularly using a language I've never used before, it was such a great experience to try something new and contribute to two projects that I found really interesting. I was really surprised at how much I was able to accomplish and feel really happy about ending my Hacktoberfest with these last two pull requests.