DEV Community: Minh Hang Nguyen

The final release

Minh Hang Nguyen — Sat, 11 Dec 2021 04:49:58 +0000

Release 0.4

After completing the implementation mentioned in previous blog, this week, I focused on testing the new feature. Currently, the project is not using any testing framework so I had to manually test the feature. I went through several aspects of the feature:

Testing on video/channel page
Testing on dark/light theme
Testing the existing Subscribe button
Subscribing to a profile more than once
Ensuring list of subscriptions is updated correctly

Since everything was working as expected, I continued to create the pull request. After a few days without any response from the maintainers, I send a private message to the project owner on the project channel. Unfortunately, all the maintainers are busy so even though the pull request was created on Monday, only one of them got the time to review my implementation. After a quick check, he approved my new feature and didn't request any changes, but he didn't merge it either. There is another pull request that is under progress and he wants that issue to be resolved first before merging my pull request. He also suggested another feature that can be implemented similarly. Though nothing is decided yet, I'm open to continue working on this project and take on the new feature.

Final thoughts on OSD600

After 14 weeks working intensely in open source, I finally understand what "open source" really is. Open source is not randomly picking an issue and working on it. To effectively resolve an issue, I need to spend a lot of time with it to understand the codebase, to know how the project works. I feel much more motivated when I can work on project that I like and would personally use. It gives me a sense of responsibility since I also put myself in the shoe of the users and also gives me ideas on what the feature/the fix should do.

Having worked on open source makes me understand that collaboration is very important. The best advice I could give myself on anyone starting this path is to not be afraid of code reviews, they could be one of the best things that you can learn from the open source community. Code reviews can make you see your code from a different aspect, they can also give you good practices on coding that you never learned before. Therefore, if you really hope to get the best out of open source community, you need to actively participate in discussion and don't be afraid to raise questions.

This journey is not too long but I did learn a lot from it: a whole new framework, better understanding of Git/Github and the workflow of coding - review. There were a lot of happy moments where I finished a contribution and they are actually big booster for my confidence in coding. There were also stressful moments but I believe that's a part of learning and I can say that I'm proud of myself for not giving up at those times. I'm also grateful to David, who has brought this amazing course to us. Thank you for sharing such a wonderful source of learning and guiding us on how to make the most out it. OSD600 has ended but it's only the starting point of my journey into open source and I hope I could bring what I learn here into greater contributions in the future.

Release 0.4: Progress on a new way to subscribe

Minh Hang Nguyen — Mon, 06 Dec 2021 18:05:55 +0000

Last week, I was planning on implementing a new feature for FreeTube and have been working on it for the whole week.

I first commented on the issue to let the maintainers know that I would like to take on the issue. After a few days without response from them, I had to reach out to them through their private channel and got their approval. Then I went on to work as planned in previous blog post and was able to finish all the tasks.

After some testing, I realized that combining the new feature with the existing functionality of Subscribe button can be confusing since the button also has to handle unsubscribe functionality. Therefore I decided to add a separate button just to handle the new feature. I mentioned this approach to the maintainers and they agreed with that.

With this new approach, the Subscribe button is kept separately without any changes. The plus button is implemented as a toggle to show and hide the profile list. Clicking this button will trigger a simple function showProfileList() to change the showProfiles property:

showProfileList: function () {
   this.showProfiles = !this.showProfiles
},

When the profile list is shown, users can click on any profile and function subscribe(profile) (code) will be triggered to directly add the subscription to the target profile without switching.

Another thing I found was that the feature can also be added to the Channel page so I suggested creating a component for the two buttons and added it to both Video page and Channel page.

To do this, I had to first create a new component including:

ft-subscribe-button.js file that contains the logic of the component
ft-subscribe-button.vue file that is responsible for the template of the component
ft-subscribe-button.sass file that has all the styling for the component

After that, I added the component to the Video page and Channel page by

including the component in the components property of the logic files:

components: {
    'ft-subscribe-button': FtSubscribeButton
},

replacing the existing Subscribe button with the new component in the template files and passed any related properties

<ft-subscribe-button
  :channel-id="channelId"
  :channel-name="channelName"
  :channel-thumbnail="channelThumbnail"
  :is-subscribed="isSubscribed"
  :subscribed-text="subscribedText"
/>

I have finished the implementation for all these ideas and in the remaining week, I will be sending the PR, waiting for the maintainers' review and work with them to finalize the new feature.

Before:

After:

Planning for a new feature

Minh Hang Nguyen — Wed, 01 Dec 2021 07:05:15 +0000

For the next two weeks, I will be implementing a new feature for FreeTube. FreeTube is a desktop Youtube player with lots of features that I find useful for myself. I've been interested in this repo but haven't got the chance to contribute to it.

There are a lot of feature requests from users and I found 1 feature that was requested twice (request 1, request 2) but unfortunately hasn't been implemented. With this feature, users will be able to quickly add the subscriptions to profile without switching. This would be very useful especially when users want to add to multiple profiles.

In week 2, I will look into the codebase to understand the structure of the project. I also need to get myself familiar with the coding styles, naming conventions, etc. After that, I will start the actual implementation and try to create a pull request with the first version of the new feature. Implementation of this feature will include the following tasks:

Create a dropdown to display the list of profiles
Add tooltip to profile so that when user hovers over, they can see the full name of the profile (the dropdown only shows the initials)
Modify the current behavior of Subscribe button. Right now, user will add the subscription to the active profile on clicking the button. I'll need to make some changes so that clicking the button will open/close the dropdown
Add click event on each profile in the dropdown to handle the actual subscription
Add logic to prevent adding a subscription to a profile twice

For week 3, I will wait for the maintainers' reviews, discuss any issues that arise and try to resolve them until we are all satisfied with the code. In week 3, I'll also look closely at the new feature to find any aspects that might be affected by it.

Publishing my first package

Minh Hang Nguyen — Sat, 27 Nov 2021 07:15:40 +0000

This week, I've published my 1st package on npm - mh-ssg - a static site generator CLI.

The process is not complicated and only involves 4 steps:

1. Configure the package

In the package.json, I need to make sure that I have all the required information filled: name and version. When the package is first published, usually it should be version 1.0.0.

2. Publish the package

In order to publish package on npm, I had to first create an account on the website. Then log in from the command line with:

npm login

After successfully logging in, I can publish the package with:

npm publish --access public

3. Test the package

I asked my friend for help to test the package I just published. She was able to install the package but when she tried to run it, she found a bug and noticed that README.md was outdated. Following her feedbacks, I fixed the bug and updated README.md with more instructions on how to use the tool.

4. Update the package

When all the bug fixes were in place, I updated the version in package.json with any related test cases, committed those changes and did a final npm publish.

Now mh-ssg is available on npm and ready to be used by the community. The tool can be installed with the simple command:

npm i mh-ssg

Creating dark mode for the first time

Minh Hang Nguyen — Fri, 19 Nov 2021 03:03:53 +0000

The issue

Looking through my classmates' contributions for Hacktoberfest, I found badge-generator - a cool tool that helps us create markdown badges for our documentations. The owner wants to implement the dark mode for the site, and since the tool is written with VueJS, I decided to challenge myself as I could also continue to learn this framework.

The implementation

The owner suggested some resources for my inspirations. I found them very useful and had some basic ideas for this.

First, I added the dark and light theme for the site and applied them to the elements that would be affected by the theme change such as the background, the font of the main content as well as the links and logo.

:root.light-theme {
  --background-color-primary: #ffffff;
  --background-color-secondary: #eeeeee;
  --accent-color: var(--grey);
  --text-primary-color: #222;
}
:root.dark-theme {
  --background-color-primary: #1e1e1e;
  --background-color-secondary: #3f3f3f;
  --accent-color: #e4e4e4;
  --text-primary-color: #f3f3f3;
}

The next thing I did was to create a ThemeToggle component and add the it to the App component. ThemeToggle includes 3 parts: the template, the script and the style. For the template, I used input of a checkbox so I could switch between 2 modes. The styling was inspired by tq-bit's blog, which was one of the owner's suggestions.

In the script, I added one data that is userTheme and 3 methods. These include

getMediaPreference() is used to retrieve the initial theme when the website is launched
setTheme() will set the class name of the root element to "light-theme" or "dark-theme"
toggleTheme() will switch to the other theme on user's click action

I also added a mounted() hook to set a theme for the website on initialization:

mounted() {
    const initUserTheme = this.getMediaPreference();
    this.setTheme(initUserTheme);
  },

After I sent my pull request, the owner requested some changes including removal of unnecessary class and refactoring code with shorter syntax for readability. For example, he suggested that I should use the ternary operator instead of traditional if ... else statements.

if (hasDarkPreference) {
  return "dark-theme";
} else {
  return "light-theme";
}

can be changed into

return hasDarkPreference ? "dark-theme" : "light-theme"

Final thoughts

Working with dark mode, I have learned a lot. Last time when I worked with Vue for my 4th contribution in Hacktoberfest, I only had to migrate the existing code to a newer version of Vue. This time, I got the chance to create a brand new component, which gave me better understanding of how the component works. I also learned the general steps to create a dark mode for an application and this is a good foundation for me to generate different themes not just with Vue but with any other frameworks as well.

The details of the PR can be found here

Code Reviews for IPC144 Course Notes Project

Minh Hang Nguyen — Fri, 19 Nov 2021 02:57:12 +0000

The Problem

As mentioned in my [previous post], we are currently working on auditing the markdown files for Seneca IPC144 course notes. Another way I'm contributing to this project is by sending reviews to other students' pull requests.

There were 2 existing pull requests by hphan9 and oliver-pham at the moment so I decided to take a look at both.

The Process

While I could quickly look at the changes on GitHub, it's still necessary to add their repo as remotes so I could properly test their code locally.

Fixing `compilers.md` by hphan9

Emily already fixed a great deal of issues on this page such as the typos, markdown syntax, Frontmatter metadata, improving page's accessibility, adding inter-site links and alt text on images. However, I also found a grammatical mistake and some minor parts that needed to be wrapped in backticks. I also suggested her to replace the plain **Notes** with Admonitions.

Fixing `algorithms.md` by oliver-pham

Oliver did a great job fixing the major problems of the page including: updating Frontmatter for page, fixing all code to be wrapped with backticks, replacing ... used as a fourth heading level with ####, replacing blockquote with Admonitions and adding inter-site links. The page content looks much clearer after his changes and all the links are working as intended. There are only 2 things I found which was a grammatical mistake and some extra indentations. These are minor issues but I believe that fixing them will improve the overall consistency of the document.

Final thoughts

After both receiving and giving reviews, I believe that the best approach to do review is to also give suggestions along pointing out the issues.

Auditing markdown file

Minh Hang Nguyen — Fri, 19 Nov 2021 02:56:33 +0000

IPC144 course notes

For a long time, students at Seneca College have been using the class notes for course IPC144 at this website. For better maintenance, we are moving the notes into a new platform using Docusaurus. Docusaurus will convert the notes into markdown files to be hosted. The auto-conversion, however, has some limitations and we also want to have some customizations. Therefore, the students are joining hands to audit all the markdown files generated by Docusaurus.

The process of auditing

The page I decided to work on is A Simple Calculation. To start the work, I followed the basic workflow: fork and clone the repo, run the page locally, go through the checklist mentioned in the meta issue and was able to resolve some issues:

fixed typo mistakes
removed unnecessary markdown syntaxes: removing bold when the text is already wrapped in inline code
added backticks for anything related to code
added alt tags for photos to improve accessibility

![numeric-constants](/img/image22.png)

used admonitions for notes and additional information
updated Frontmatter to include more tags:

id: a-simple-calculation
title: A Simple Calculation
sidebar_position: 2
slug: /B-Computations/a-simple-calculation
description:  Create a computer program to solve a basic programming task

Receiving reviews

The great thing of working with open source is that we can get reviews from other developers. After sending the pull request, I got some suggestions from other students, mainly for some minor parts that need backticks but I didn't notice. I was also suggested to update the slug in Frontmatter to match with the standardized format.

Fixing a problem by one self is never enough. It is very helpful to have other people also looking at the same issue so we can get suggestions from multiple perspectives, which can give us an even better solution.

To know the detailed solution, read more in the issue and pull request.

Adding Continuous Integration - GitHub Actions

Minh Hang Nguyen — Thu, 18 Nov 2021 19:14:15 +0000

Continuous Integration

In order to avoid breaking the code in the main branch, I added the Continuous Integration to the GitHub workflow. In this workflow, I want it to run on node ver 14.x whenever there's push or a pull request to the main branch. There are 2 actions I wanted to include:

a clean install of all dependencies: npm ci
a full test run: npm test

The yml file would look like this:

name: Node.js CI
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]
    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 test

After setting it up myself, I found that CI is not too hard to use and it also brings lots of conveniences as it can quickly detect if a push or pull request might contain a potential error.

Adding more tests to another project

This week, I also created some test cases for another repo. Adding tests for someone else's code is no doubt for difficult than working on my own code. I had to understand the logic of the code and try to figure out what each function is supposed to do in order to find all possible scenarios.

For Leyang's project, I found that getHtlmlTitleBody() was not tested yet so I decided to contribute some tests to it. This function accepts the content of the file as a string and a boolean indicating whether it's a text file or not, it then returns an object with 2 properties: title and body.

const getHtmlTitleBody = (file, isTxt) => {
  let html = {
    title: '',
    body: '',
  };

  let tempTitle = file.match(/^.+(\r?\n\r?\n\r?\n)/);
  if (tempTitle) {
    html.title = tempTitle[0].trim();
  }

  if (isTxt) {
    html.body = file
        .split(/\r?\n\r?\n/)
        .map((para) => {
            if (para == html.title) {
              return `<h1>${para.replace(/\r?\n/, ' ')}</h1>\n`;
            } else {
              return `<p>${para.replace(/\r?\n/, ' ')}</p>\n`;
            }
        })
        .join('');
  } else {
      let md = new markdownit();
      html.body = md.render(
        file.substring(html.title.length).trim()
      );
  }

  return html;
};

After investigating the function carefully, I came up with 3 scenarios to test:

a text file input with title
a text file input without title
a markdown input file

The details of the tests can be found here.

Add testing to SSG

Minh Hang Nguyen — Sat, 13 Nov 2021 04:17:20 +0000

For this lab, I picked Jest as the testing tool for mh-ssg. This is a popular Javascript testing framework thanks to its simplicity and ease of usage.

The framework can be easily installed with the following command

npm install --save-dev jest

Since mh-ssg is using ESLint, I also have to install eslint-plugin-jest so that ESLint can work with Jest.

yarn add --dev eslint eslint-plugin-jest

In .eslintrc config file, I added the plugin for Jest and "jest/globals": true to the env variable.

{
   "plugins": ["jest"],
   "env": {
      "jest/globals": true
   },
}

I also configured the rules under the rules section

{
  "rules": {
    "jest/no-disabled-tests": "warn",
    "jest/no-focused-tests": "error",
    "jest/no-identical-title": "error",
    "jest/prefer-to-have-length": "warn",
    "jest/valid-expect": "error"
  }
}

In this lab, I wrote some test cases for generateHTML.js and validateOutputFolder.js as unit tests. I realized that sometimes the code for testing can be even more than the code itself. Since the program might have several paths and in each path, it could direct even more sub-paths. Effective testing should cover most of these paths, hence, the amount of testing can be too much if we don't know which feature to focus on. For these test cases, I also learned about mocking. To be specific, I created a mock for the fs module to test the output folder.

Another thing I learned was to create end-to-end testing. In order to run this, I had to install another module - execa.

npm install execa

I created run.js to execute the program for end-to-end testing.

const execa = require("execa");

async function run(...args) {
  try {
    const result = await execa.node("bin/index.js", args);
    return result;
  } catch (err) {
    return err;
  }
}

Thinking from a testing perspective, there are a lot of scenarios to be tested since the program allows several options. I was planning to write tests for all scenarios but due to the limited time, I couldn't complete all of them. Currently, only the tests for --input are finished and other tests are commented out and I'll find some time to update them soon.

Adding Static Analysis Tools to SSG

Minh Hang Nguyen — Thu, 04 Nov 2021 19:15:27 +0000

To maintain the quality of source code, I added a formatter and a linter for my project.

Prettier

I pick Prettier as the project's formatter. Prettier will help fix any format issues and generates a neatly-formatted version of your code. That means a consistent style will be applied to the whole code and we can also add any addition styles that we want to apply.

I installed the plug-in with the following command:

npm install --save-dev --save-exact prettier

Then, I added an empty config file to let the editor and other tools know Prettier is used:

echo {}> .prettierrc.json

One thing I noticed when using this command was that running it from the terminal will generate the file encoded in UTF-16, which won't work. Instead, I had to run the command from cmd (Windows) so that the file is encoded in UTF-8.

If you have any style that you want to code to conform to, .prettierrc.json is the right place to put your styles into. For me, the default format is good enough for me so I keep the file blank as for now. Another file I created was .prettierignore, which stores the files/folders that I don't want to be processed by Prettier.

Right from the beginning of the project, I used the extension of Prettier in VSCode so after installing, there was no changes in the format of the code.

I also added scripts to run Prettier from the terminal so contributors who work on this project can quickly use the tool.

To format, run:

npm run prettier

To check if all files are already formatted, run:

npm run prettier-check

ESLint

ESLint was chosen as the linter for the project. ESLint will analyze the code to quickly find problems. It can also automatically fix many of them.

The tool can be installed with:

npm install eslint --save-dev

A configuration file called .eslintrc will be created with this command:

npx eslint --init

This command will prompt you to choose the file type you want - js, yml or json.

To include the basic rules marked with the tick on rules page, this line should be on the config file you just created.

"extends": "eslint:recommended"

ESLint also allows you to add any rules you want to implement. These additional rules should be put in "rules" property in the same file.

Similar to Prettier, we can also add the .eslintignore file to define which files/folders we don't want to be linted.

To check for problems and automatically fix problems, you can use the following scripts respectively:

npm run eslint

npm run eslint-fix

After running the linting, I found some issues with my code:

PS C:\Users\hang0\Documents\CPD\S5\OSD\mh-ssg> npx eslint bin

C:\Users\hang0\Documents\CPD\S5\OSD\mh-ssg\bin\index.js
  51:3  error  Parsing error: 'return' outside of function

C:\Users\hang0\Documents\CPD\S5\OSD\mh-ssg\bin\utils\generateHTML.js
  16:23  error  Unnecessary escape character: \<  no-useless-escape
  16:45  error  Unnecessary escape character: \>  no-useless-escape
  16:20  error  Empty block statement  no-empty

✖ 4 problems (4 errors, 0 warnings)

The problem descriptions are very clear so it was easy to find and fix those issues.

IDE Integration

To integrate the tools into the IDE, I installed the Prettier and ESLint extensions and created .vscode folder. Inside the folder are two items: extensions.json and settings.json.

extensions.json indicates which extensions are used

{
  "recommendations": ["dbaeumet.vscode-eslint", "esbenp.prettier-vscode"]
}

settings.json defines the default formatter to be Prettier and the behavior on save to be auto format and auto fix linting

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": { "source.fixAll.eslint": true }
}

The commit for new changes can be found here

Static Site Generator - Support static files

Minh Hang Nguyen — Fri, 29 Oct 2021 04:19:45 +0000

Throughout the previous week, I was exploring Docusaurus and found that they have a feature to support static files. I find this feature very useful for any static site generator since images, favicons, stylesheets, etc. are very common parts of a webpage. Therefore, I decided to add this feature in my tool.

Planning

To add this feature, I sketched out a few tasks to finish:

Add markdown support for image syntax
Create a folder inside the output folder to store all assets
Save all static files from user input to assets folder
Parse the saved assets to the html file

Implementation

While finding a way to parse image syntax, I decided to fully implement support for markdown. I used markdown-it and highlight for this task.
I added a new module - copyAssets and imported fs-extra to easily copy the assets from users' folder to the default assets in output folder.
Since the process of generating HTML file is getting more and more complicated, I separated a part of the logic into the generateHTML module. Apart from the existing logic, I also added code to replace old image path to the new one that I just create.

The actual implementation turned out to be more complicated that expected. In step 1, 2, 3, my original plan was to code them myself but then I had to look for libraries to simplify the process, otherwise it would take too much time and there might be unnecessary errors.

Next step

The feature is currently working but there are still rooms for improvement.

For now, t he tool only accepts static files through the config json file. It should accept the assets as an option. For example, users should be able to use mh-ssg -i file.md -a assets.
Currently all files in user input folder are copied to the default assets folder. However, the tool should go through all the files and only filter out image files before copying so that the storage is not wasted.

Hacktoberfest - 4th contribution

Minh Hang Nguyen — Thu, 28 Oct 2021 07:29:35 +0000

For the last contribution in this Hacktoberfest, I decided to take this opportunity to learn a new technology - Vue.js. Therefore, I picked GeekScore as my starting point.

The issue

The project originally used Vue.js 2 and is currently migrating to Vue.js 3. The issue I picked was to do the migration for one of the components - GamesEditDialog.vue

The fix

To resolve this issue, I imported defineComponent and ref from composition-api while removing vuex. An important change in Vue.js 3 is that both the data and methods will be set inside the setup() function.

I had to remove any this instances because in the new composition-API, setup() does not resolve this anymore. Instead, ref is used to manage reactivity. In Vue 2, function data() returns one single object containing the data. However, in Vue 3, the data are defined in setup() with the use of ref to mark each them as a reactive and mutable object. Apart from the data, the two existing methods submitGame() and updateTheGame() were also moved inside this function. The function setup() will then return an object containing these data and methods so that the view can be automatically updated when reactive state changes.

Owner's feedback

The owner suggested that there was an instance where I should use reactive instead of ref. I looked for more explanations and found that while their main purpose is the same, the usage is a bit different. ref is mostly used to wrap non-object data while reactive only wraps an object.

const toDelete = ref(false);

const fields = reactive({
      name: {
        label: 'Name',
        icon: 'dice-multiple-outline',
        value: game.value.name,
        rules: [...standardField, requiredField]
      },
      ...
});

Another suggested change was about the use of props. Instead of directly using props, the repo owner pointed out that I should use toRefs to restructure it to improve readability and maintain consistency.

const { game } = toRefs(props);

Final thoughts

Learning a new technology can be confusing at first, but directly working on an existing project like this really gained me better understanding of the concepts. The comments from the project owner also pointed out the parts that I was missing while learning. Looking through them again, I was able to clarify any confusions between ref, reactive and toRefs.
There is still a long way to learn about Vue.js but I believe this has been a good starting point already and I'm ready to go to the next step.

Issue-4 link: https://github.com/DavidGolodetsky/GeekScore/issues/131
PR-4 link: https://github.com/DavidGolodetsky/GeekScore/pull/202

DEV Community: Minh Hang Nguyen

The final release

Release 0.4

Final thoughts on OSD600

Release 0.4: Progress on a new way to subscribe

Planning for a new feature

Publishing my first package

1. Configure the package

2. Publish the package

3. Test the package

4. Update the package

Creating dark mode for the first time

The issue

The implementation

Final thoughts

Code Reviews for IPC144 Course Notes Project

The Problem

The Process

Fixing compilers.md by hphan9

Fixing algorithms.md by oliver-pham

Final thoughts

Auditing markdown file

IPC144 course notes

The process of auditing

Receiving reviews

Adding Continuous Integration - GitHub Actions

Continuous Integration

Adding more tests to another project

Add testing to SSG

Adding Static Analysis Tools to SSG

Prettier

ESLint

IDE Integration

Static Site Generator - Support static files

Planning

Implementation

Next step

Hacktoberfest - 4th contribution

The issue

The fix

Owner's feedback

Final thoughts

Fixing `compilers.md` by hphan9

Fixing `algorithms.md` by oliver-pham