This blog post documents my experience going through Open Source Development (OSD600) course at Seneca College.

Throughout the semester, I’ve learned a lot about open source development and collaboration.

I’ve learnt how to collaborate with other developers through many different tools, especially Slack (collaborating chat tool), GitHub (web-based code hosting service), and Git (version control system). In addition, I’ve been introduced to new concepts regarding open source development through many different excellent sources on OSD600 wiki, and having a wonderful professor like David Humphrey for guidance.

Through working on open source projects, I’ve had to deal with many different ideas and concepts (ex: languages, technologies, …) that I’ve never seen before. It was challenging at first, but after I get through them, it was satisfying and gave me more incentive and confidence to participate in more open source works.

Overall, I think this is a great course that introduces valuable information and practices that will get me ready for the workforce after I graduate.

This is the final blog post for release 0.4 in OSD600. For the final external Pull Request, I decided to continue working on and improving upon ESLint issues.

This time, instead of creating eslint configuration file, I had to fix eslint errors. The repo that I was working on is exercism/javascript, basically this repo contains exercises in Javascript.

The eslint configuration was created in package.json, but the exercises contain lots of eslint errors that haven’t been fixed. Thus they were added to .eslintignore file.

So for my PR, I just had to pick one or more exercises from the repo and fix the eslint errors in those exercises.

Here are the step that I took to complete the PR:

1. I ask to work on some of the exercises on this issue.
2. Then I forked, and cloned the repo to my computer.
3. Created a new branch called issue-480.
4. Look up the exercises in .eslintignore file (these are still not fixed for eslint errors), choose 3 of them and remove them from the list.
5. Go to each individual exercises folder and run npm install.
6. The guide for this issue states that I can run npm run eslint to see the eslint errors then fix them, but since I’m coding in Visual Studio Code, I can already see eslint errors in Problem panel without the need to run the command.
7. Fix the errors either by putting in a single line comment like // eslint-disable-next-line rule1, rule2 or fix the actual code.
8. After fixing all eslint errors, I made a commit and pushed it to the origin repo and made a PR.

Here are some example of eslint error fix that I did:

For the above error, I just had to add a comment specifying that some eslint rules should be disable for the next line:

// eslint-disable-next-line no-bitwise, no-restricted-properties

For the object destructuring error, it was a bit more complicated and I had to do a google search and came upon this answer on stackoverflow, and all I had to do was to fix line 17 to const { value } = this.head;

And that’s it for this blog post. Thanks for reading!

In this blog post, I’ll talk about the second External Pull Request I’ve done for OSD600 Release 0.4.

For this PR, I decided to work on issues that have to do with ESLint, particularly setting it up. So ESLint is a pluggable linting utility for Javascript and JSX. More information and documentation can be read on eslint.org.

The repo that I was working on is Kentico Developer Community Site. The issue that they had is that their project code is full of comments to disable eslint check, and they would like someone to create eslint configuration files for two of their projects’ directories.

After I skim through the configuring ESLint user guide provided, and similar issues, I was able to successfully create a PR.

So there are many ways to create an eslint configuration files:

• JavaScript – use .eslintrc.js and export an object containing your configuration.
• YAML – use .eslintrc.yaml or .eslintrc.yml to define the configuration structure.
• JSON – use .eslintrc.json to define the configuration structure. ESLint’s JSON files also allow JavaScript-style comments.
• Deprecated – use .eslintrc, which can be either JSON or YAML.
• package.json – create an eslintConfig property in your package.json file and define your configuration there.

Taken from eslint user guide.

And they also have order of precedence if placed in the same directory, the priority is:

1. .eslintrc.js
2. .eslintrc.yaml
3. .eslintrc.yml
4. .eslintrc.json
5. .eslintrc
6. package.json

Then I had to look up how to disable rules for a group of files in configuration files instead of using in-file comments.

{
  "rules": {...},
  "overrides": [
    {
      "files": ["*-test.js","*.spec.js"],
      "rules": {
        "no-unused-expressions": "off"
      }
    }
  ]
}

Taken from the user-guide.

For my purpose, I changed the no-undef rule to “off”. I also had to figure out how to select all the .js files in the directories. Then I came across this:

**/*.js

This RegEx will include all JavaScript Files looking forwards from the location of the eslint configuration file.

The last step is just to remove all unnecessary eslint-disable comments from every files.

To make it easy, I just need to use Visual Studio Code search and replace feature.

This is the first blog post for the final release of OSD600. I’ll talk about what I did for the third and final internal Pull Request for the GitHub Dashboard Project.

As mentioned in the third blog post for Release 0.3, this fourth Pull Request is responsible for creating mock-up pages to house the Dashboard components and make the page responsive.

So one of my classmate has created a homepage with login button using React framework and its default start-up page. My job was just to improve upon that to make the site more suitable for our needs and requirements.

To make the site more responsive across devices, I have made use of Bootstrap framework, adding these lines of code to the main index.html page:

<link rel="stylesheet" href="proxy.php?url=https%3A%2F%2Fmaxcdn.bootstrapcdn.com%2Fbootstrap%2F3.3.7%2Fcss%2Fbootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">

after the meta tags in <head></head>.

https://code.jquery.com/jquery-3.2.1.min.js and

And that’s it for this blog post! Thanks for reading!

This is the final blog post for OSD600 Release 0.3.

At the end of this Release, I have had a total of 4 PRs:

1. https://github.com/joelnet/MojiScript/pull/250
2. https://github.com/yevseytsev/SenecaBlackboardExtension/pull/39
3. https://github.com/deepanjali19/GitHub-Dashboard/pull/12
4. https://github.com/deepanjali19/GitHub-Dashboard/pull/17

The third and fourth PR are about the GitHub Dashboard project that I’m doing for internal Pull Requests.

Basically in this project we’re trying to revamp the GitHub front page, creating a dashboard that allows user to see important and relevant details for his/her issues and pull requests, as well as other information about the repositories that they’re interested in.

Some of these new features will be implemented as components on the dashboard, for example:

• Display issues that match given labels for a repo the user is interested in
• List most recent activity for a repo the user is interested in
• Display issue with least amount of comments/most amount of comments in a given repo
• Display and list comments related to recent pull request/issue a user has made
• Display the user’s recent activity in a list
• Display total number of stars for all the user’s repos
• a list of issues the user is currently working on
• a pie chart showing a distribution of languages the user worked with based off the repositories they have
• a simple list of languages the user has used

But for now we have to create mock-up pages to house these components, as well as setting up testing environments and making the page responsive.

My fourth PR has actually accomplished creating mock-up pages for the dashboard but I will go into the details in the next blog post.

For the moment, I want to talk about something that I have learnt through creating my first external PR that I haven’t mentioned.

To recap, for that PR, I was tasked with  creating a new type for MojiScript Language, based on similar existing type. Through the creation of new type, many new functions were created as well.

And when I’m pretty sure that everything works perfectly by running local test (npm test), I got stuck when I tried to commit my changes. At first I didn’t understand what or why something would stop me from committing on a local clone of the project (not to mention it was a fork repo).

I just didn’t understand what the error was about (it says something like global test coverage not satisfied). After a while I got frustrated, and figured out that I could uninstall the node_modules folder (in other word, not running npm install from the start) to prevent my commit from being blocked by whatever it is when I tried to run git commit. Then I was able to commit successfully and pushed the code to my origin repo and  made a PR.

This is where I figure out the problem I encountered earlier, all thanks to the awesome third party services connected to GitHub like TravisCI and coveralls.io, because they give much better visual information about what is problematic with your code, rather than the boring, plain terminal. So it turned out that because I have created new type and more functions, I’m also required to create additional tests to cover additional and new cases. Furthermore, I also learned that there is a thing called pre-commit hooks (the one that I saw was husky), that are basically procedures to run on my code before it get committed (or whenever I call `git commit`), like ESLint, or tests that check whether my new codes have broken anything, and of course the test coverage, which gave me trouble.

I then go back to write additional tests for my new functions, but I still get the test coverage not fulfilled error. I was so annoyed that I couldn’t figure out which tests hasn’t been covered by looking at the table of percentage in the terminal and can’t make a commit, that I deleted the node_modules folder again to push my code to the PR.

This is where coveralls.io comes in very handy. It shows me a nice clean GUI of which test still needs to be covered or created, by putting check marks over every functions. Then I see the one function that I haven’t written test for, I wouldn’t had been able to do this just by looking at the statistical data in the table in the terminal. After that, everything was fixed and I got no errors and my PR was merged.

The point to pull out of this experience is that GitHub works with many other third-party services that are connected to repositories that enhance the quality and workflow of open source collaboration.

In this blog post, I’ll talk about my first internal Pull Request for the Seneca Blackboard Extension Project.

Before talking about my PR, I’ll briefly touch on what this project is about. Everyone studies at Seneca is no stranger to the blackboard that is used to display common college services and let you get access to your courses’ announcements, materials and grades. But often time, students find the blackboard to contain unnecessary information that makes it hard to navigate within the site, it also lacks some important resources that are useful or important to students.

Therefore, with the Blackboard Extension Project, we’re trying to collaboratively make blackboard better visually and functionally, by making an extension for Google Chrome browser that allows anyone visiting the blackboard to experience the new and improved design.

In my PR, I added two new links to Seneca ICT and Seneca International sites since they’re vital to us as IT students, and for me as an international student. I also modified another collaborator’s work to make the font size for a drop-down list to be more reasonable and pleasing to look at. All of these fixes  were done through editing a giant HTML retrieved by the .innerHTML method of the module of interest:

document.getElementById("module:_3073_1").innerHTML = 'HTML String'

We figured out the module number by inspecting the original blackboard page with inspector tab from the developer tool.

Here is are before and after pictures of the BB, after applying the extension:

Although more work are required for a complete extension, as you can see, the page is significantly rid of unnecessary information that distracts users from important ones.

Even though I didn’t code that much for this PR, I think what matters is what I learn from going through collaborating with others to start a new project from scratch in GitHub and be one of the contributors. For me, the best part was that I learned how extension works in browser. Before, as a user, I simply installed and refreshed browser to see extensions take place without knowing much what is happening behind the scene, or how the extension is making the browser changes. After this PR, I learnt that the code for extensions come mostly from a javascript (.js) file. In combination with some resources like images (for the extension) and most importantly a manifest.json file to specify which site the extension will take effect on (and match the .js file), the whole extension are contained within a folder to which the browser can have access, by toggling on developer mode in chrome and choose load unpacked.

After that I just have to visit the myseneca.ca page and see the magic happens! Knowing and seeing how the extension takes place is also valuable when I’m trying to work on the source code of the extension, because I can see the changes reflecting as I edit the code in VSCode. All I have to do is save the file I was working on and refresh the extension and the site to see the changes.

In this blog post, I’ll talk about what I’m planning to do for the next 3 weeks for the Release 0.3 of Open Source Development course.

But before that, I’ll talk about the first external Pull Request that I’ve done. This Pull Request continues on the previous MojiScript repo that I was working on for Hacktoberfest.

This time, instead of adding functions to a specific type (Maybe type) in MojiScript, I was tasked with creating an entire new type (Either type), along with all the sub types (Left and Right) and the functions associated with them.

Since I’ve already got experienced on working on this project, it was pretty easy to set things up, and navigating the project. Things got even easier when the project maintainer provided the specifications and expected results for the new type. All I had to do was following the pattern of the code from the similar type, and created the new file. During the process of creating the new type (Either, Left, Right), I also had to update the relevant files that contain the definitions of the aforementioned type, and test files as well.

As for my plan for the next 3 weeks, I’m going to finish one more external PR, probably from the same repo, and one more internal PR for one of the Seneca Open Source Projects. There are 3 topics that I’ve chosen for the internal PR:

1. Seneca Blackboard and Student Centre Extension.
2. Seneca Student Personal Github Dashboard.
3. NodeChat.

The reason for choosing the above repos to work on is because I have similar issues when working with Github, where I can’t find a quick and easy way to track the issues and pull requests that I’ve done. For the Seneca blackboard, I could see some improvements being made. As for the NodeChat, the repo is forked from an already well-established repo with issues to work on.

This is the final blog post detailing my experience through contributing to Hacktoberfest event.

By now I have had 5 working Pull Requests made, and four of them have been merged, with difficulty ranging from creating simple JSON file to making enhancement to project code by creating new functions.

For the first two PRs, I wanted to start out small and worked on creating JSON files that adding more entries to the project collections of movies and words. The third PR was a bit larger, where I have to create a localization JSON file for Vietnamese language support. I had to translate each properties to corresponding words in Vietnamese.

The last two PRs are harder, and they took me much more time to do, especially the fourth one. I’m going to talk about the last one first. In the fifth PR, I had to write implementation code for an existing function, and creating a new function without implementation and test cases for it as well. I had no trouble doing all of these, but I encountered problems when I tried to create a PR. Since the project is mostly maintained by automated bot, it has no way to know that the fact that I’ve fixed a test case for the function that I implemented is OK. It always check for 3 files in the PR, if you have more or less than that, it will give you an error when testing your PR. Therefore, I had to wait for a while until the real project maintainer comes and resolves the issue. In the end, my PR was merged.

The last PR was the most challenging to me. For this one, I had to create new functions to the project codes that were required by the project owner. The hard part about this project is that it involves syntax, and style that I’ve never seen before, it was written in MojiScript, which is a language that emphasizes on asynchronization, and functional paradigm that has 100% compatibility with JavaScript engines (at least this part makes it easier). After studying the syntax of the language and going through a few simple examples, I was able to dig in and find where to put the code, and all the necessary information to create a new function. I also had some problems when creating a PR, it gave me so many error. Later on I figured out that I should’ve installed all dependencies of the project and ran the test locally instead of relying on the Travis test on GitHub, it is cleaner this way and I don’t have to create so many unnecessary commits. After that I discovered issues with ESLint and resolved them, then my PR passed the check and was successfully merged.

In conclusion, through this second release, I was able to truly participate in open source projects. It was quite difficult to find available issues that I have the ability to work on at first. But as I progress through creating PR after PR, I became more confident of tackling new issues and creating successful solutions.  In general, I think Hacktoberfest is a good place to start your journey into open source development.

Here are the links to the Issues:

1. https://github.com/jsonmc/jsonmc/issues/826#issue-368331255
2. https://github.com/jsonmc/jsonmc/issues/824#issue-368318688
3. https://github.com/Showndarya/Hacktoberfest/issues/884#issuecomment-429974562
4. https://github.com/erxes/erxes-widgets/issues/79#issuecomment-433178894
5. https://github.com/joelnet/MojiScript/issues/221#issuecomment-433229216
6. https://github.com/rgehan/hacktoberfest-2k18-katas/issues/953#issuecomment-433289311
7. https://github.com/rgehan/hacktoberfest-2k18-katas/issues/1057#issue-374238512

Here are the links to the PRs:

1. https://github.com/jsonmc/jsonmc/pull/829#issue-221542888
2. https://github.com/Showndarya/Hacktoberfest/pull/1164#issue-223018572
3. https://github.com/erxes/erxes-widgets/pull/87
4. https://github.com/joelnet/MojiScript/pull/238
5. https://github.com/rgehan/hacktoberfest-2k18-katas/pull/1056#issue-225980495

This is the fifth and the last Pull Request for the Hacktoberfest event.

I chose to work on hacktoberfest-2k18-katas repository. This repo is made specifically for hacktoberfest purpose, it allows anyone to start contributing to an open source repository and create a PR that counts towards their hacktoberfest event. The main language used in this repository is Javascript, and people are encouraged to create javascript functions that do a certain thing in the source folder. These functions started out as issues to solve specific problems, after they are implemented, another issue is suggested in the same pull request, and stub code and new test cases for the new function should be incluced in the pull request as well, which makes it 3 files in total for the Pull Request to be accepted and merged.

Here are the steps that it took me to complete this PR:

1. I forked and cloned the original repo on my computer.
2. I asked the project owner for permission on working on this project, since many people before me seems either get stuck or took too long to reply.
3. It was simple to write the code to implement the function
4. But I noticed that one of the test case for this function is incorrect, so I fixed that
5. Then I created a new function with it implementation code stub, and test cases
6. After that I push my codes to the remote repo and created a PR, also created a new issue for the new function.
7. But I encountered a problem when my PR failed the travis test. The problem was about me having 4 files in my PR instead of 3, and the project is mostly maintained through automatic messages. So I had to wait a few days until the project maintainer reviewed and merged my PR.

In this blog post, I’ll talk about the fourth Pull Request for the Hacktoberfest event.

I chose to work on MojiScript project, which is an Async First, opinionated, and functional language designed to have 100% compatibility with JavaScript engines.

The issue that I worked on was an enhancement feature that aimed to add 2 new functions to the project code (flatMap and leftMap).

Even though I didn’t know about and understand MojiScript very well, I was successfully able to create a working PR that got merged into the project. Here is the step that I took to complete this:

1. I forked the original repo.
2. I requested to work on this issue even though somebody else had asked for it before me, because the person took a long time to respond, and the project owner was checking on the progress.
3. After that, I cloned a local repo on my computer to work on.
4. Before coding, I need to understand what Moji is and how to set up environment to work on Moji codes, so I went to the documentation page to learn how to set up everything, the syntax, and style of Moji codes.
5. Also I went into the examples folder and tried out fews simple examples to see how MojiScript works, and to figure out the necessary way to test my output when I code so that I can see that I’m on the right track.
6. Once I’m comfortable with how some of the basic functions and syntax work in MojiScript, I headed to the issue page and started on it.
7. The good thing about this issue is that the owner already laid out the step required to complete the PR, and I just had to write my code based on these requirements.
8. So I just had to start out with codes from the hello world example, and from there I can write my code and see if the output matches what was required by the project maintainer.
9. From the requirements, I can see that two object that stand out which is Just and Nothing. So from the project folder in my computer, I started a search for these object in Visual Studio Code and find the definition files for these object types, which is Just.js and Nothing.js.
10. Within these files, I could see the functions that are associated with these objects. From there, I just had to follow the requirements to create new functions, based on the existing ones.
11. After I wrote the implementations for these new functions, I also wrote the corresponding tests for them.
12. After I finished with coding, I push the codes to my remote branch on GitHub and created a PR from the original repo.

I learned a lot from working with this PR. I learned how to work with code that I’ve never seen before and still figure out the solution based on what’s given, all without being afraid or confused about what to do. This experience gave me more confidence and motivation to tackle and contributing on more open source projects.