DEV Community: Andre Willomitzer

My Final Week Of Open Source at Seneca

Andre Willomitzer — Fri, 10 Dec 2021 21:42:33 +0000

What the class was about

For those who haven't seen some of my previous blogs about the OSD600 open source class at Seneca College here is some background... My name is Andre Willomitzer and I am a Seneca College student taking this class. I am trying to specialize in JavaScript/TypeScript/NodeJS and web development.

OSD600 is about contributing to open source projects on GitHub, collaborating with professional developers/maintainers and also our fellow students. The goal of this is to learn how to leverage the community and learn from each other to build better software and learn best practices.

Throughout the class we have built our own static site generators and also contributed to a variety of projects "out in the wild".

The Final Release 0.4

For the final release we are supposed to once again pick an open source repository. I have chosen solr-node-client which allows you to run solr on NodeJS using a Docker container. What I was hoping to fix in this repository that one of the maintainers Igor Savin told me about is that the tests were not browser compatible (he knew about that).

The repository did not yet have browser tests set up, but he knew that the Undici library was not compatible with browsers.

First Steps

To run browser tests, I decided to use Karma. It is something I previously set up in another TypeScript project, and since the existing tests use describe() and it() functions it seemed like the best choice again.

First I installed the dependencies such as jasmine-core, karma, karma-chrome-launcher, karma-jasmine, and karma-typescript. These allow the Jasmine tests to run and also compile typescript using pre-processing. I also added a script to the package.json file to run the karma --start command.

Next I had to create the config file (note the compiling to JS from TS):

Running The Tests

Well running the tests went about as well as expected (3-4 errors and very cryptic). One of the errors was esModuleInterop which means one of the modules was using an older import statement no longer compatible. I went and fixed several imports such as:

After that it was just 1 error left... And that is where I got stopped in my tracks. The error was once again very cryptic. It said one of the imports was not a function even though I used require() in the exact same way as my other imports.

Due to this, I was unable to even run the existing tests using Karma to try and fix the Undici errors.

Unfortunately, I was unable to solve the issue of browser incompatibility. I believe this was in part to choosing a repository which I had no prior experience with... on top of it being a really complex issue but I was hoping to push myself. However, I am satisfied because I learned a lot still during this project.

My takeaways

Working on this project has exposed me to learning how to install Docker on Windows 10 which I will likely need to do at some point in my future as a developer. Furthermore, I learned how to configure Karma for a project that runs tests using a container like Docker which required some extra set up. I was also able to learn about debugging cryptic errors when setting up configurations for things like Karma, and Docker which required a lot of determination.

In addition, due to my own struggles and taking a long time to set up Docker Desktop I wrote README documentation in the repository about how to do it for future developers who want to contribute. I found a lot of my time was spent initially getting the Docker container running rather than actually trying to fix the issue at hand. So if other developers can avoid that it's good.

Conclusion... It's about the friends we made along the way.

I have learned an immense amount during OSD600 at Seneca. I got the chance to work on some amazing projects like jasmine, toad-scheduler where I got to fix a setInterval() bug, and solr-node-client. These projects have exposed me to professional development workflows and how development is done "in the real world" with tools like linting, automated testing, continuous integration. All things I was previously unaware of.

Although I am a little sad I was unable to fix the issue I set out to in this Release 0.4, I feel that it was valuable and I plan to continue contributing to Open Source in my future whenever possible. I met some amazing people who have been extremely helpful and kind in letting a new developer such as myself work on their repositories.

I plan to take OSD700 next winter if I can, after I complete my internship. In the meantime I would like to contribute to more open source projects even if it's small fixes. It's a fun way to learn and meet interesting people.

Release 0.4 Progression

Andre Willomitzer — Thu, 09 Dec 2021 18:30:09 +0000

The Task At Hand

This past week I have been working on solr-node-client repository, and attempting to adjust their test cases to be browser compatible with the help of the maintainers.

In order to do this, I have had to learn a lot about setting up Docker containers locally. This has been made even more of a challenge by the fact that I am on Windows 10 Home, which is missing some nice little features like enabling Hyper-V.

What I have accomplished so far

So far, I have managed to install Docker Desktop for Windows 10 Home. This involved workarounds using a batch file (.bat) and installing WSL/WSL2 and the Linux kernel update manually.

First, I had to install developer dependencies for jasmine-core, karma, karma-chrome-launcher, and karma-jasmine. Also in the package.json file, I added a script to run the karma tests: "karma-tests": "karma start --single-run --browsers ChromeHeadless karma.conf.js",.
In the repository itself I have set up the karma.config.js file to use Headless Chrome. .

Running the tests

When I initially ran the tests, I had to start Docker by running npm run solr:current:start to start the Docker container. And then to execute the tests, I ran my karma-test command with it pointing to the existing test directory.

Surprisingly, it didn't work. Because the project uses Typescript rather than JavaScript which Karma is made for, I had to create an exception for .ts files in the config file:

files: [
      {
        pattern: 'test/**/*.ts',
        type: 'js'  // to silence the warning. Means load with <script> tag
      },
    ],

To make sure it wasn't my Karma setup, I created a basic Karma test of adding 1+1 and making sure it equals 2. The test passed so I moved on to trying their already created tests.
After running the tests with no Karma warnings, I started to get other errors which were 100% expected because that's why I made the issue branch to try and fix the browser incompatibilities.

One error was about esModuleInterop which I assumed was to do with some parts of the code using old import statements (even some packages) and some using require(). In order to fix these I went into the types.ts file and changed the import statement from import Dispatcher from 'undici/types/dispatcher'; to import Dispatcher = require('undici/types/dispatcher');.

Upon changing that statement, I ran the tests again and had a strange error about "figc" one of the imports not being a function. From here, I decided it would be best to ask the maintainer what to do about this issue because changing the imports did not seem to fix it like it did the other issues.

In the meantime and moving forward...

Since I got a little stuck and Docker Desktop took so many tries, attempts, sweaty armpits to set up I asked the maintainers if I could add some documentation to the README about setting it up so that future developers can have an easier time getting going.

That's all for now!!!

OSD600 Final Release Planning

Andre Willomitzer — Tue, 30 Nov 2021 02:17:45 +0000

Release 0.4

For this final assignment, we are tasked with contributing to another repository as we have done in the past. I am hoping to improve my Karma test skills even further by developing some tests that run in a Docker container. This is done in an application I intend to help add Karma to called solr-node-client.

The reason this must be done is the maintainers have let me know that the tests should fail in Karma because the application uses something known as undici under the hood which is not supported in browsers.

My Plan

My initial part will simply be writing the Karma config file and adding the existing tests to the Karma test commands. However, I am hoping to have enough time and skill to also find a solution with the help of the maintainers and to have a workaround in place for browser compatibility. Perhaps I will be able to write a few tests as well in order to get more experience with writing Jest and Karma tests.

What I hope to learn

I am hoping to learn again from experienced developers like Igor Savin and the folks at solr-node-client. Through this I will learn about browser testing and hope to write some tests of my own for the project (whatever they happen to want tested). Furthermore I think this will be a good overall learning experience to understand asynchronous programming because the API uses promises which I have less experience with than synchronous styles.

I am excited and let's see how the next couple weeks go!

Andre :)

Publishing my first npm package

Andre Willomitzer — Fri, 26 Nov 2021 19:36:11 +0000

The Project

Eleven weeks ago when I started in Open Source Development 600 at Seneca I never thought I would get to the point of actually releasing something into the wild. Over the term we have been working on our individual static site generators. The purpose of these tools is to take a text file or Markdown file and parse it into a valid HTML document.

It can include a variety of features depending on the student, but some of the options for my own textToHTML include stylesheets, using a config file instead of the command line, and having an output option to specify a folder to put the HTML documents into.

The Journey

Throughout the weeks, we have been contributing to Open Source projects on GitHub and making pull requests. Included in this is the idea of contributing to each other's SSG's. Collaborating with classmates has truly opened my eyes about new ways of doing things and best practices of development. All of my classmates such as Kevan Yang have been instrumental in getting the tool ready for npm deployment.

We added linting, style guides, testing, continuous integration, among many other things throughout the semester. Each time, finding a better approach and refactoring.

How does npm deploying work?

First of all, you will need to go to the npm website and create an account. This is where your packages will be stored. Then, make sure you have npm installed on your computer. You can check using npm -v in the terminal.

Next you will need to run npm login command and enter your credentials for the account you created. From the root directory of your project, run npm publish.

Important you may get an error about a package with the same name existing. You may either create a scoped package or change the name to something else. The name is found in the package.json file of your application.

That's it!!! Your package should show up on your npm account. However, if you want to tell people how to use your application you should create a README.md with usage instructions, and then run npm version patch and npm publish again to release a new version. In order to do this your Git commit history must be clean.

How to try my tool (if you want)

As mentioned, I published a package as part of the course and the way to install it is via terminal. My tool is called textToHTML. You may type npx texttohtmlv2 in your command line. It will prompt you to install the package (say yes). Then, to see if it's working you can try the help command by typing npx texttohtmlv2 -h in the terminal. It should display a list of other things to try out.

Final thoughts (for the final lab)

This has been such an amazing journey in my 5th semester at Seneca. I have had the opportunity to contribute to things I never dreamed of having a hand in working on like the jasmine testing framework, and also learned how to persevere when things aren't going right and to keep trying different approaches. I have also learned things that will serve me in my career such as Continuous Integration, end-to-end testing, Linting.

Last, and certainly not least I learned about using Git. At first it was terrifying because all of the commands were foreign. Throughout the term we have been forced to adopt Git and learn to use commits, branches, merges, and pull requests to organize our work which has been an amazing learning experience.

I know this article wasn't all about publishing, but I hope my experience inspires someone else to build a project even if it starts small.

Thanks for reading!

Andre Willomitzer

GitHub continuous integration basics (my experience).

Andre Willomitzer — Fri, 19 Nov 2021 20:46:21 +0000

Looking back...

Last week in class we added automated testing to our Static Site Generators (mine is called textToHTML). This included some tests for Jest which make sure the core functionality of our programs work as expected.

Continuous Integration?

After writing our tests, if you run npm run test from the command line it will run the tests. But... what if someone who is contributing to your repository forgets to run the tests before committing?

Introducing continuous integration (I'm using the GitHub version).

This allows you to set up a .github folder containing a .yml file to configure your tests to run automatically on any push or pull request to your repository. The above linked article shows step by step how to set up the configuration folder and file for either Node.js or Python.

Once the changes are made, commit them to your repository so GitHub has the .github folder and .yml file(s).

Testing if it works

If you want to test whether the continuous integration is working, create a branch from your main branch using git checkout -b new-branch-name. Make some small change such as a spelling change to your README.md.

Commit these changes to the branch, and then navigate to the GitHub website. Under your repository, you should see an option to "compare and pull request" the new branch with your main branch.

If the continuous integration is set up properly, when you create the Pull Request it will run the checks you have outlined in your .yml configuration files. In my case it runs npm run test which executes my Jest test suites. You can also configure it to run linting and prettier formatting by using the corresponding scripts from package.json.

Ask A Friend

After making a pull request to my own repository to check if the CI worked, my friend Kevan Yang and I added more tests to each other's repositories to create a pull request and test it that way.

For my pull request to his project text-to-ssg I tested one of his functions called getAllFiles(). I wrote an expect() function expecting the files function to throw if it does not find the file (it's not the function itself throwing, but the fs.readfile function throwing).

Moving Forward

In the future I plan to use continuous integration in my projects, and it was nice to have an understanding of how to set it up. It makes collaborating much easier because it stops unintentional bugs and code breaking changes by running the tests. Furthermore, it can be used for linting and styling which is useful because developers contributing to your project may not have the same style as you, and so the CI checks will report any differences.

Markdown file auditing: what I learned.

Andre Willomitzer — Tue, 16 Nov 2021 17:18:52 +0000

C Programming At Seneca

For the longest time, the C Programming class notes at Seneca were hosted on a website. However, given the development in web technologies and frameworks since their creation the professors and heads at Seneca have decided to reformat the notes into Markdown using Docusaurus.

Because this a huge undertaking, and we're all learning software development which includes documentation writing, the job of auditing the new Markdown files has come to us students.

What are we looking for?

Generally the automatic conversion tool did a good job of taking the website notes and creating Markdown files. The files were added to Docusaurus and include dark mode. However, some things it missed or converted to non-standard ways of writing Markdown.

For example, in the file I audited called functions.md the images were loaded properly using Docusaurus. But because the original website did not have dark mode capability, the images backgrounds were not adjusted. This lead to issues like black arrows on a black background:

Before

How I fixed it was using a <span> element around the images on the page with the class name mdImg. Inside the global CSS file I added a selector of .mdImg > p > img and changed the background color to white background-color: #ffffff;. I used a <span> because they are inline as opposed to <div> which is block-level and may mess with responsiveness accidentally.

After

React specific changes

Since Docusaurus is built using React, and the original website was made using HTML/CSS. As such, when the HTML elements were rendered they used class and colspan. React uses className and colSpan. It didn't cause a direct error, but my friend Kevan Yang pointed out it had many console errors so I changed all the classes. Furthermore, it didn't cause an error again but the <tr> elements needed a matching <thead> and <tbody>:

You may also notice that I removed spaces before <tr> because that's another issue in React rules that <tr> can't have blank spaces before or between it.

Other small fixes

Some smaller fixes included fixing the mispelling "parameter", adding alt tags to images, and adding Markdown admonitions for notes instead of blockquotes.

I also removed inline CSS that was causing table backgrounds to be yellow even in dark mode:

What I learned

Auditing the file taught me a lot about attention to detail, in large part due to my friends code reviewing the pull request. I caught a lot of the issues myself at first, but things like the console error and the image in dark mode being incompatible I learned a lot about researching how to fix issues I haven't encountered before.

Code Reviews: Problems (but also solutions).

Andre Willomitzer — Mon, 15 Nov 2021 22:21:25 +0000

What we're doing

This assignment for our Open Source class has us doing some work with Markdown, HTML, and CSS to transfer the C Programming notes from Seneca College from a website, to a Docusaurus website using Markdown/HTML. Because the initial conversion was done doing an automatic tool, we are tasked with auditing and making sure the notes match the website. Images loading properly, looking good in dark mode, different screen sizes, etc.

Code Reviews

Part of the process of 50+ students working on a project is having a lot of reviewing to do so nothing breaks. The professor can't possibly do all of that and we're going to need to review in our developer journey, so it's time to learn!

For this review I did a PR review for my friend Kevan Yang who was adding PWA support to the application. Overall, there was not much to say about the code and Kevan did a great job. One small thing I noticed which is nitpicking is in the manifest.json file the "name" and "description" for what the website does were different and needed to be the same: "IPC144 - Course Notes".

Furthermore an issue with the PWA approach was the application launch icon being blurry.

We tried to resolve this, and my suggestion was to attempt to resize the image and up the resolution using Adobe tools. The article I recommended to Kevan is here which provides tools to use to try and change the image.

Although it seemed like a good idea it didn't work, and a separate issue ended up being filed because Kevan had done a lot on the issue already. Fixing the image would have been too much in addition to that.

Review 2

For my second review, I decided to review one of my fellow students doing an audit/review of a Markdown file, information.md. The tool used to transfer the notes from a web page to Markdown files may have missed some syntax or images in the process.

By the time I reviewed, Yoda-Canada (Tengzhen) had already made several fixes to the page

Fixed images in to be readable in dark mode
Added alt text for diagram images.
Replacing blockquotes with Markdown style admonitions like note.

My suggestions

The issues themselves were super well spotted and Tengzhen did a great job taking notice when reviewing the page. Some things I noticed because I also ran into them on my own auditing:

To fix the dark mode image issue, I suggested wrapping them in a tag and adding class "mdImg" to it. Then, using this, we can apply global CSS and have the background of the image white. On normal screens this does nothing but on dark mode it stops this from happening: Instead, the image is white background and the arrows stay black.
I suggested removing the <img> and <div> tags and sticking with the original Markdown images. The issue with using <div> is that block-style elements may mess with CSS and responsiveness by accident. <span> on the other hand is inline-styled.
For regular text, I don't believe it is necessary to wrap them in
tags because we're using a Markdown file and so regular text that isn't preceded by a symbol like ### is treated like normal text. I suggested Tengzhen remove them.

Propose a solution

What I learned from doing code reviews, is that it's really appreciated when you don't just point out the problem. Point out some reasons you think it's happening, a potential solution or how you've fixed a similar problem in the past. The person you are reviewing will really appreciate a solution oriented approach.

Doing code reviews and having my own reviewed is great because it allows you and others to catch things you may not see because it's your code. This in turn catches mistakes, bugs, and makes the code overall better developed.

Happy reviewing!!!

Andre

Cross platform testing using Karma.

Andre Willomitzer — Mon, 15 Nov 2021 21:45:35 +0000

What am I working on?

The last 2-3 weeks I have been working on Pull Requests for my Open Source class at Seneca College. Previously, during Hacktoberfest I contributed to a tool called toad-scheduler which is an in-memory NodeJS scheduling tool.

In this tool, I helped fix a bug about setInterval() limit throwing an error with anything over than 24.5 days. During this PR, I had to write a test using Jest framework to handle the long intervals and make sure it was firing the task correctly.

Different types of tests

For my next PR, I wanted to work on the tool again with Igor Savin. I asked him what I could do to help this time around. One of the options he mentioned was adding Browser based testing using Headless Chrome.

I asked him why exactly we needed to do that considering there was already a full suite of Jest tests. His answer was that it was to prevent any "Node specific" functionality from creeping in to the code. This means we have to make sure the code works on any platform (command line, browser, etc).

Browser Testing With Karma

Setting up Karma is actually quite straightforward thanks to the documentation and provides step by step instructions on installation, and configuration. Furthermore, I used this Google Dev Article about headless chrome setup.

Since my task was the initial setup and writing a basic test, the test I decided to use in my Karma setup is:

describe('a simple Karma test', () => {
  it('should equal 2', () => {
    expect(1 + 1).toBe(2)
  })
})

Commit Links

Interesting note about Jest & Karma

However, because Jest is built on top and mostly compatible with Jasmine (which Karma is built on top of), the creator Igor had the idea to use the already predefined Jest tests but make them platform neutral. Take the Jest specific functions, and change them to be the Jasmine counterpart so that Karma can also run the tests originally made for Jest.

An example of changing the functions is when advancing timers:

How to run your tests?

After following the setup for creating a karma.conf.js and installing Karma with npm you should be ready to write a basic test as I did above. Create a folder for your tests. Next, create a file with .js or .ts extension. Inside your test file, copy paste the it/describe() from above.

In the config file, in the "files" property, add the correct path to your test folder so Karma can find the test files. For us it was just called "test":
files: [{ pattern: 'test/**/*.ts' }, { pattern: 'lib/**/*.ts'}]

Package.json script

Inside package.json under the scripts, add a new "test:karma" property or whatever name you prefer and set the value to the Karma test command like so:
"test:karma": "karma start --single-run --browsers ChromeHeadless karma.conf.js"

After saving and running npm run test:karma on the command line it should run your test file.

Note

An error I ran into doing this would be eslint environment property needing "browser":true. In some cases if you don't do this, it will not recognize export-default and cause an error with Karma in the command line.

What I learned

I learned a lot about cross compatibility testing, and how to make multiple testing tools work together. It was interesting seeing the differences and also similarities between Jest/Jasmine/Karma.

They all are related in some way so it was funny seeing that we didn't even need to write any more tests, just import the ones from Jest and change the functions to be Jasmine ones which Jest is able to understand too.

I hope that helps someone get Karma tests up and running in their application!!!

Thanks for reading.

Andre

Jest: execution testing & automated setup.

Andre Willomitzer — Fri, 12 Nov 2021 14:20:45 +0000

Why Test?

When we write software or applications, generally we try to do it with the future in mind. By that I mean when you're writing code you already somewhat anticipate issues the user will create (for example, entering a letter where a number input should be), and you take steps to catch that error.

But honestly, there is likely something that was missed. There are too many possibilities to catch as you're writing the code. That is where automated testing comes in. There are a variety of frameworks, but because my application is in NodeJS/JavaScript I picked Jest. I also have written 1 or 2 tests for it in the past so I was familiar with it() and describe().

What Is Jest?

Jest is a testing framework used for writing unit tests for your application. It allows you to write tests and test suite files ending in .test.js or .spec.js. In these files, you are able to test individual pieces of your application. For example, in my textToHTML SSG I have a function that processes Markdown syntax, called... processMarkdown()... I know, super creative.

To install Jest, run npm install --save-dev jest in your project folder. Then, as mentioned earlier create a .spec.js file for your testing.

How and What to Test?

Because Markdown has so many symbols and combinations that can result in different HTML, I figured it would be a good idea to test different combinations in my tests.

To test functionality, make sure to require() or include your file containing all the functions you want to test, and be sure to export them in that main file:

const { processMarkdown, generatePara } = require("./textToHTML");
And then inside textToHTML: module.exports = { processMarkdown, generatePara };

Example Test with processMarkdown()

Here are a few examples of tests I wrote. describe() is used to group tests into a suite, and can be used to organize WHAT the group of tests is testing. it() can be used to run a single test.

describe("it should process various Markdown combinations", () => {
  it("should handle a blank file", () => {
    //testing if the input I give is blank (empty file but it exists)
    const emptyContent = "";
    const returnResult = processMarkdown(emptyContent);
    expect(returnResult).toMatch(""); //it should be blank if md.render() worked
  });

  it("should return a string", () => {
    const testString = "";
    const returnResult = processMarkdown(testString);
    expect(typeof returnResult).toBe("string");
  });

  it("it should return h1", () => {
    const testString = "# Should be inside h1.";
    const returnResult = processMarkdown(testString);
    const expectedResult = "<h1>Should be inside h1.</h1>";
    expect(returnResult).toContain(expectedResult); 
  });
}

This is only a small portion of the tests, but you can write as many as you want for whatever functionality you want in your program.

Okay great, but how do I run the test?

To automate the tests, all you have to do is go into package.json and add "test": "jest". Save the file and run npm test from the command line. Voila! It should search for all .spec and .test files.

To exclude a single test, you may go into the test file and change it() to xit(). To run only a single test or test suite, add .only() to the end of the describe() or it() test you want to run.

What I learned

I learned a lot doing testing for the first time on my application, and I definitely plan to use more of it in the future. It promotes modular programming because you can't really test unless you have functions that handle smaller pieces of logic. Furthermore, it makes you really think about what the edge cases are in your program and how it SHOULD work vs. how it does.

I hope that was helpful,
Thanks for reading,
Andre :)

Linting: Oxyclean for your code.

Andre Willomitzer — Thu, 04 Nov 2021 18:23:01 +0000

Why Lint & Prettify?

It's easy to forget that writing code is a creative practice like many others. When working on your application, you have a style. It's not something anyone taught you (some of it like basic syntax sure), but we all have our own ways to indent, write conditional statements, among other things.

How would you explain your style to someone who hasn't seen you code before? Luckily, you don't have to when you use... static analysis tools.

Tools For The Job

In my case, since the project is JavaScript based I have chosen eslint, and Prettier as the formatting and style guide tools. I chose them due to the popularity, and variety of setup guides which allows me to customize how I want.

Prettier Setup

To set up Prettier, you will need to install the package from npm and using the instructions from Prettier Install Docs. This will set you up with a .prettierrc.json file. In this file is where you will set all the configuration options for your Prettier formatting.

Once the initial setup is done, you can choose which files to ignore by either creating a .prettierignore file, or inputting which file to use as a base when you run the command using --ignore-path CLI argument.

eslint setup

To set up eslint, you can go to the getting started page which will show how to create a config file similar to Prettier. It also demonstrates how to set basic rules to get your linting started. More advanced configurations are available but getting started... gets you started.

Similar to Prettier, you can create an .eslintignore or specify --ignore-path when you run the npm run eslint command.

How do I do that anyway?

Open package.json
Create a new property under scripts called "lint", and set the value to "npm run eslint"
Save the file and run npm run lint!

Bonus: .vscode config folder

Create a folder called .vscode in your project root directory.
This folder can contain many files, but an example of one is settings.json where you can set the rules for your VSCode editor such as auto-format on save, tab indenting, and more.

What did it find in my own code?

Having set up linting/formatting in my own SSG called textToHTML, commit link, I was curious what it would find.

Mostly, it found spacing and line length issues. For example, when I generated my HTML template string, it split the string into multiple template strings separated by +. Another thing I noticed was since I specified "semi": true in the aforementioned config files, it added a couple missing semi-colons to the end of variable declarations.

In terms of indenting/spacing nothing changed because I try to keep a consistent style and I set the rules up to match my own style (since I'm the project owner).

Moving Forward

This was a great experience learning how to set up linting and formatting because in the future it will help others work on my project without having to ask how I want it done. I also now know how to set it up for future projects and where to find the setup docs.

setInterval() and the 32 bit debacle.

Andre Willomitzer — Sun, 31 Oct 2021 14:02:22 +0000

Backstory

I first set out at the start of October to complete 4 Pull Requests for Hacktoberfest. My initial research led me to a tool called "Colorette" which is a CLI tool for coloring terminal output. I really wanted to work on this repository, but before I could implement my proposed issue fix, someone had swooped in and merged a PR in my place.

Afterwards, a nice contributor to the project named kibertoad saw this happen and asked if I wanted to come work on his scheduling tool. I said sure, and off we went. There were very few issues in the repo because the tool had been tested well.

However, one key issue remained. setInterval().

setInterval()? What's the problem?

You may think: "setInterval()? I've used that 1 million times no problem." and you would be right. The issue with setInterval() as we learned through the project is a problem with the JavaScript language itself.

The value for setInterval is held in a 32 bit signed integer. Most times, the maximum is never exceeded because setInterval() is mainly used for executing tasks closer together. In our case however, it was discovered that because we are making a scheduling tool, someone may actually want to schedule a task for 30 days, when the limit is 24.855 days.

Constructor Fixing

Initially when creating a job and task with a schedule of 30 days, the tool would crash with a NodeJS error about the limit. In order to fix this, a lot of checking, delaying, and time-tracking had to be implemented in the constructor.

First, we set the future time to execute the task using the current time + the time the user schedules. Then, we create a task inside the SimpleIntervalJob itself. The purpose of this is so that when the task executes(wakes up) it will check if it's time to execute the original task, or if we're still over the limit. If we are, keep running the timeEating task. If we're not, then execute the task the user planned.

By doing this, we "eat time" until setInterval() won't throw an error anymore. Overall, the most difficult part of this constructor fix was having to wrap my head around the timeEating task calling itself and checking inside itself whether were over time.

Testing

Having seen the application code now, I noticed the creator was using Jest testing framework. Before this, I had no experience writing automated tests but if you're going to implement a fix you need to test so now was the time.

For the most part, the tests consisted of a counter variable, and a job/task to be executed. In order to test if my constructor worked, I wrote a test that initialized a job to execute in 25 days (which is over the limit). I advanced the timer by just under 25 days, and then pushed it right to 25 days to check if the task executed properly.

    it('correctly handles very large intervals', () => {
      let counter = 0
      const daysInMs = 25 * 24 * 60 * 60 * 1000 //25 days in ms
      const scheduler = new ToadScheduler()
      const task = new Task('simple task', () => {
        counter++
      })
      const job = new SimpleIntervalJob(
        {
          milliseconds: daysInMs,
        },
        task
      )
      scheduler.addSimpleIntervalJob(job)

      expect(counter).toBe(0)
      jest.advanceTimersByTime(daysInMs - 1000)
      expect(counter).toBe(0)
      jest.advanceTimersByTime(1000)
      expect(counter).toBe(1)
      scheduler.stop()
    })

The Creator

The original creator of the tool is Igor 'kibertoad' Savin and I had a really great time getting to know him and picking his brain about this issue. Overall it was a very difficult issue to solve which is why I chose it for my 4th Pull Request but I learned a lot about how to work around issues that you CAN'T fix at a base level such as the 32 bit integer not being big enough. I might not be able to change the size of the integer but I can change how my code handles these issues.

Sometimes it's the little things (3rd PR).

Andre Willomitzer — Sun, 31 Oct 2021 12:49:12 +0000

The Night of PR's Past

In the month of October we are participating in Hacktoberfest. For my third pull request although it wasn't labelled for the competition, I decided to choose the Open Air Quality main website. In the past, I worked on the API that functions behind the scenes and removed some commented code from it.

I decided to look again and see if there was another issue to work on but in a different repository for the same project. Doing so I found a very recent issue regarding one of the front end components of the application.

Doing Some Digging

To fix this, I went into previous commits and PR's to see which files had been worked on for similar tasks. The bug was concerning the "comparison tool", and so I looked for commits and pulls saying they worked on compare/comparison features. By doing this I was able to find which file had the error. I had a strong feeling that since the issue was new, it may have been a more recent commit that made the spelling change.

The fix itself was rather simple so I did not run into problems since the issue raised was a misspelling of "correlation" in the UI, but only in that 1 spot in that 1 file. Naturally I had a peek at the other files to make sure nothing else was spelled wrong by maybe even the same person.

Committing The Changes

I cloned the app, made the issue branch. After changing the mistake I committed, and made a Pull Request on GitHub.

It was a good experience contributing to Open-AQ again in some way!