Release 0.4 – Including eslint in npm test on Mozilla Thimble

For release 0.4 I decided to work on issue 1921 in Mozilla Thimble.

The issue was that the grunt task that runs when you run npm test only ran jshint. This doesn’t do enough style profiling. We needed to add eslint in order to catch style errors that contributors might miss.

I fixed this issue by first installing grunt-eslint. After that I needed to modify the Gruntfile.js file to include the eslint task. I included the files that should be checked by eslint when npm test runs.

Here is how the eslint task looks in the Gruntfile.js file:

In the .eslintrc.json file I added the rules that we needed to use. The only rule that I added was the indent rule. I specified that the indent of the files needed to be 2 spaces. I used the eslint indent rule to see how to turn the indent rule on and specify 2 spaces. Of course in the future many other rules can be added to this file as needed. All the eslint rules are available here: http://eslint.org/docs/rules/.

I also specified the ecmaVersion for the parser to be 6. I needed to include this in the .eslintrc.json file because if it is not there it will give many parsing errors like the keyword let is reserved and const is reserved.

Here is how the .eslintrc.json file looks:

My pull request is available here: https://github.com/mozilla/thimble.mozilla.org/pull/1971 

In conclusion, I learnt that installing eslint for Mozilla Thimble was a similar process as how we installed eslint in lab 6. The difference here was that I needed to include the eslint task in the Gruntfile.js file. Using eslint in Mozilla Thimble will be very useful for future contributors since it checks their code style and warns if anything needs to be fixed. This can be especially useful for contributors that forget to use 2 spaces for indentation.

 

Release 0.3 – Updating Major Dependencies in Mozilla Thimble

For release 0.3 I decided to work on issue 1908 on Mozilla Thimble.

The issue was updating major dependencies that Mozilla Thimble uses. The major dependencies that needed to be updated were:

• cryptr
• fs-writefile-promise
• glob
• grunt-cli
• grunt-contrib-csslint
• grunt-lesslint
• jquery
• helmet
• wolfy87-eventemitter

I solved this issue by creating 9 separate pull requests for each dependency. This was suggested by @Pomax. This made it easy to debug and test each update rather than have one pull request that contained all the updates. I used npm-check to get a list of the major updates that were available for these dependencies. I found using npm-check was a great tool that made it really easy to get the updates and install them. It also updated the package.json file once the updates were installed.

After I updated each dependency separately I needed to test the update to see if everything works correctly. I did these steps for each of the updated dependencies in order to test them:

• npm install
• npm test
• vagrant up
• opened Thimble in localhost to test if everything is working

The update for grunt-lesslint resulted in having many warnings when running npm test. The warnings were from the rules known-properties and order-alphabetical. I needed to fix these warnings so that when npm test runs all the tests pass.

I fixed these warnings by turning off the known-properties and order-alphabetical rules in the Gruntfile.js file. This resulted in making the tests for lesslint pass since these rules were turned off.

For the grunt-cli update I needed to test it on bramble.mofostaging.net to make sure that nothing broke on staging from the new update. I tested it on staging and everything seemed to work fine.

As of now, most of these updated dependencies got merged in. However, some of them still need to be reviewed.

Here are my 9 pull requests:

• https://github.com/mozilla/thimble.mozilla.org/pull/1936
• https://github.com/mozilla/thimble.mozilla.org/pull/1937
• https://github.com/mozilla/thimble.mozilla.org/pull/1938
• https://github.com/mozilla/thimble.mozilla.org/pull/1939
• https://github.com/mozilla/thimble.mozilla.org/pull/1940
• https://github.com/mozilla/thimble.mozilla.org/pull/1941
• https://github.com/mozilla/thimble.mozilla.org/pull/1942
• https://github.com/mozilla/thimble.mozilla.org/pull/1943
• https://github.com/mozilla/thimble.mozilla.org/pull/1944

In conclusion, I learnt that updating major dependencies resulted in sometimes needing to modify some files in order to meet with the new update. It is not as easy as just updating the dependency and expecting everything to work afterwards. Testings need to be made in order to check that everything is working properly. Also working on this issue made me become better with using Git since I needed to create 9 different branches for this issue.

 

DPS909 Lab 9 – Deploy to Heroku

This lab builds upon the previous lab. For this lab the task was to extend the previous lab’s code to include cloud PaaS deployment.

I needed to create a simple node.js web server and REST API that uses the Seneca module that was created in the previous labs. I than needed to deploy the server to run on the cloud hosting platform Heroku.

My GitHub repository is available here: https://github.com/badrmodoukh/Seneca2017LearningLab

My Heroku app URL is: https://protected-island-21203.herokuapp.com/

Steps I took to complete this lab:

I first created a node.js web server using express. This provided an HTTP based API for calling the Seneca module functions. I named the file server.js. This is the code in the file:

I than tested the server locally by running node server.js.

This enabled me to navigate to the routes I created which are:

• http://localhost:3000/ – (this route displays a simple message “My Server is Working!”)
• http://localhost:3000/validate/badr@myseneca.ca – (this route returns a JSON formatted response indicating that the given email is valid or invalid)
• http://localhost:3000/format/badr – (this route returns a JSON formatted response with the given name formatted as a valid Seneca email address)
• http://localhost:3000/healthcheck – (this route returns a JSON formatted response with the server’s uptime)

After I tested locally and everything seemed to work properly I needed to deploy to Heroku. I install Heroku and was able to interact with it using the command line. I created a Procfile that informs Heroku which command to run when it starts the app.

After creating the Procfile I needed to add, commit, and push the code onto GitHub.

Once the code was on GitHub I than started the process of deploying the app onto Heroku. The commands I used to do this were:

• heroku create – this creates a new app and generates a random name for the app
• git push heroku master – this is used to push the code to the heroku remote that was created
• heroku ps:scale web=1 – this starts one web server with the code I pushed
• heroku open – this is used to open the app that was deployed to heroku

After doing these steps the app was running on Heroku.

Conclusion:

Overall, doing this lab was quite interesting. I never used Heroku before and I found it fun and important learning how to use it. I liked the way Heroku works with Git making it easier to deploy code. I can see now why it is so important to run your code on cloud infrastructure like Heroku to test your work especially REST APIs. I will definitely consider using this in the future.

DPS909 Lab 8 – Open Source Tooling and Automation

For this lab we extended our work from the previous lab to add unit testing. I decided to use Jest for the unit testing framework. It is a JavaScript tester that is created by Facebook.

Here is my GitHub repository for this lab: https://github.com/badrmodoukh/Seneca2017LearningLab

Steps I took to do this lab:

Doing this lab was straight-forward and I did not face any problems.

The first step I did was install Jest using the command npm install –save-dev jest. This installed Jest and saved it in the devDependency in the package.json file.

After I got Jest installed I created tests for the two functions I implemented in the last lab (isValidEmail() and formatSenecaEmail()).

I found creating tests for these two functions to be really useful. When I first implemented these functions I did not consider all the ways someone might use and misuse them. Creating tests for these functions allowed me to test them and improve them so that they can meet with the tests I did.

I created a test file name seneca.test.js which contains all of the tests.

The tests I did were for these scenarios:

for the isValidEmail():

• testing a simple myseneca address
• testing a non-myseneca address
• user passes something other than a String to the function (ex. Number, Boolean)
• user passes a variable which is actually null
• email address contains leading whitespace
• email address is for a professor vs. student (ex. ends with @senecacollege.ca)
• email address uses old style Seneca address (ex. @senecac.on.ca)
• string is empty

This is how the code looked for these tests:

for the formatSenecaEmail():

• adds @myseneca.ca to a simple string
• adds @myseneca.ca to a string that contains spaces
• user passes something other than a String to the function (ex. Number, Boolean)
• user passes a variable which is actually null
• string is empty

This how the code looks for these tests:

Using describe() organized the code and grouped the tests together for each function. This made the code easier to read and follow.

I automated the tests by modifying the package.json file. I added a jest script and modified the test script to run lint and jest together.

This is how it looks:

Conclusion:

I believe unit testing is important to take into consideration when coding. It allows you to improve on your code and take into account how other people might use your code. I used unit testing in the past for Java with JUnit. I don’t remember much of it since it was a long time ago, but the general idea is similar. I found using Jest to be easier and more simple than when I used JUnit for Java in the past.

DPS909 Lab 7 – Open Source Tooling and Automation

In lab 7 I was assigned the task to explore and learn about open source tooling and automation. I found this lab to be useful and learned some interesting things from it.

I did this lab by first creating a repository on GitHub. This repository will be expanded on in the coming weeks. It is a starting point to learning open source tools. I initialized the repository with a README.md file, added a .gitignore for node, and added a license using the MIT license.

Here is a link to my repository: https://github.com/badrmodoukh/Seneca2017LearningLab

After that I cloned the repository using:

git clone git@github.com:badrmodoukh/Seneca2017LearningLab.git

After the repository was cloned I initialized the package.json file using npm. This created the package.json file and included the information I set. The steps I took to accomplish this are:

• npm init
• entered the name, version, description, entry point, license

Once I created the package.json file I needed to create the node.js module in a JavaScript file called seneca.js.

I implemented the isValidEmail and formatSenecaEmail functions in this file. This is the end result of that file:

The isValidEmail function checks to see if the passed in email is a valid Seneca email. The formatSenecaEmail function creates a Seneca email using the string that was passed into the function.

Once I finished implementing these functions I wanted to test my work and see if the functions did what they are suppose to do. In order for me to test my work I needed to write a simple command line tool that uses seneca.js.

I accomplished this task by following the steps done in this tutorial: Building command line tools with Node.js.

These are a summary of the steps I did:

• created an index.js file
• added a shebang (#!/usr/bin/env node) to the beginning of the file
• added a bin section in the package.json file with a property key “seneca” and property value “./index.js” which is the script that will run the seneca.js module
• used “commander” npm package to receive arguments
• defined the options to use
• installed shell command using npm install -g

Here is how the index.js file looks at the end:

This enabled me to test my seneca.js module by running the commands:

“seneca -v <seneca email>” which checks if the Seneca email is valid

“seneca -f <name>” which creates a Seneca email with the given name.

“seneca –help” which displays the options available to use this command

Here is how this looks:

After I tested the functions I implemented I needed to add ESLint to avoid common problems in my code.

I accomplished this by doing these steps:

• npm install eslint –save-dev (which installs eslint and adds it to the development dependencies in the package.json file)
• create a configuration for eslint using ./node_modules/.bin/eslint –init
• selected Airbnb JavaScript rules
• selected JSON format the eslint config file

This created a new file called .eslintrc.json.

After I configured eslint I ran it to check the seneca.js file and it showed me a couple of warnings that are “Unexpected unnamed function”.

I fixed this error by adding the function name to the function. ESLint Rules provides all the errors that can occur and how to fix them.

I added a script to the package.json file to always check my code when I make changes.

The final step I did was to use TravisCI. I thought using TravisCI will be a difficult task to accomplish but surprisingly it was very simple to add to the repository.

I followed the steps on Getting started to accomplish this task. I found these steps to be really easy to follow and clear.

Here is a summary of what I did to add TravisCI to my repository:

• signing in to Travis CI using my GitHub account
• Enabling Travis CI for my specific repository
• created a .travis.yml file for a node project to tell Travis CI what to build

Here is the link to my TravisCI build: TravisCI build for lab

Finally at the end I added the Travis CI build badge by copying the code in the Travis CI website. I did this by following these steps Embedding Status Images.

I learned a lot from doing this lab and found it to be really useful and interesting. The tools that are used in this lab such as ESLint and Travis CI are used in many other open source projects and being able to understand how to add them to a project I found to be really useful. Now I understand how other open source projects add these tools to their repositories.

 

DPS909 Lab 6 – Picking and Learning a Good Editor

The two editors I wanted to explore with are Atom and Brackets. I never used these editors before and wanted to explore what they offer and see which one I liked more than the other.

After experimenting with these two editors I decided to use Atom which can be downloaded from https://atom.io/.

I liked using Atom more than Brackets because I felt more comfortable with its layout and how the code’s font and size is displayed more clearly. Also I found it easier to customize and find different packages to install. Even though I chose Atom over Brackets I found Brackets to be not that bad and recommend you to try it out.

Here’s how Atom looks with the entire Mozilla Brackets project opened in it:

And this is how Brackets looks:

I will be demonstrating how to do 5 simple tasks with the Atom editor. These tasks are:

• How to open an entire project
• How to open the editor from the command line
• How to split the screen into multiple panes
• How to install editor extensions (packages)
• How to change the theme of the editor

How to open an entire project:

Like most editors opening an entire project is done in a similar way. When you first open Atom it displays a Welcome Guide with an option to open a project. This is done like this:

You can also open a project by going to File -> Open… -> and selecting the project you want to open.

How to open the editor from the command line:

Before you can open Atom in the command line you need to install the shell commands. This is done by going to Atom > Install Shell Commands. Then you can open Atom from the command line by simply typing “atom” in the terminal. This is done like this:

You can also type “atom <file or project path>” which will open a file or project in Atom.

How to split the screen into multiple panes:

Splitting the screen into multiple panes can be done like this:

How to install editor extensions (packages):

Installing extensions/packages in Atom is very simple. You goto Atom -> Preferences. This will open a Settings window in the editor. Than you goto Install and type in the package you want to install. This is done like this:

The install section also displays featured packages that you can install.

How to change the theme of the editor:

Many editors enable you to change the theme of the editor. To do this in Atom you goto Atom -> Preferences -> Themes. You can select from the pre-loaded themes. This is done like this:

You can also choose to style Atom by editing the stylesheet.

My 5 favourite extensions(packages) for Atom:

Atom offers many extensions(packages) that you can install. The 5 most packages I found to be my favourite and most useful are:

• linter-jsonlint
• atom-beautify
• color-picker
• minimap
• git-plus

linter-jsonlint:

This package I found to be very useful for linting JSON files. It saves you a lot of time when you are trying to find where the syntax error is in a JSON file. There are also other packages available for linting other file types like HTML, CSS, PHP, JavaScript, etc. Here is a demonstration of how this package works:

atom-beautify:

I found this package to be really useful for formatting code. Instead of going through every line to format the code properly, you can use this package to do it for you. It saves a lot of time. Here is a demonstration of this package:

color-picker:

This package is quite interesting and useful. It shows you a preview of the color you want to pick in the CSS file. Instead of browsing through the different colors available, you can use this package which shows all the colors to you in the editor. Here is a demonstration of this package working:

minimap:

I found this package to be really useful when working on files. It allows you to scroll through a file that contains a lot of lines of code faster. This package saves you a lot of time when scrolling through a file with 1000s of lines of code. The Sublime Text editor has this feature and it was great finding a package for Atom that offers this feature. Here is a demonstration of this package:

git-plus:

The git-plus package is also one of my favourite in Atom. It enables you to work with Git without leaving the editor. I found this to be quite useful. Inside of the editor you can add, commit, push, pull, and do other git commands.

Release 0.2 – Fixing bugs 593 and 589 in Mozilla Brackets

For release 0.2 I decided to pick two bugs to fix on Mozilla Brackets. They are:

• Update node deps #589
• Remove or Update issue template #593

My pull requests for these two bugs are:

• Fix #589 updated node dependencies and devDependencies
• Fix #593: Modified the ISSUE_TEMPLATE.md file

Fixing issue #589:

Fixing this issue I found to be quite interesting and learned a lot from it. The issue was that we needed to update the dependencies and devDependencies in the package.json file and ignore the updates for the dependencies and devDependencies that Adobe uses upstream. As humphd stated, these dependencies/devDependencies would get updated later when merging with Adobe upstream.

I fixed this issue by using a tool called npm-check. This tool helped me find the dependencies/devDependencies that needed to be updated in the package.json file. When I installed it and ran it, it displayed this:

This is a list of all the dependencies/devDependencies that Mozilla Brackets uses in the package.json file that had updates available. By running the command npm-check -u it enabled me to select all the dependencies/devDependencies that I wanted to updated. This looked like this:

After I had selected all the dependencies/devDependencies I wanted to update (ignoring the dependencies/devDependencies that Adobe uses) the tool updated them for me and also updated the version number in the package.json file. I reinstalled bramble and ran it using these commands:

• npm install
• npm run build
• npm start

And got a few error messages that looked like this:

This error message was caused from updating the autoprefixer-core dependency. It caused the postcss dependency to not work correctly. I fixed this problem by switching over to autoprefixer and changing the code in the Gruntfile.js for the postcss task as humphd suggested. After doing this it fixed the problem and bramble installed and ran without any errors.

Fixing issue #593:

Fixing this issue I found to be simple. The ISSUE_TEMPLATE.md file got added when we merged with upstream. There were two options that were suggested to fix this problem. Either to remove the file completely or to modify it to fit our project. As suggested by humphd I needed to modify to file to fit our project instead of removing it.

I modified the file by using vim to change the text in the file. humphd suggested to modify the file with these suggestions:

• Get rid of the Prerequisites section
• Keep the section on Steps to Reproduce, Expected and Actual behaviour
• Change the Versions section to be about which browser (name and version) and OS the user is using

After modify the file using vim to make these changes I created my pull request and it got accepted.

I learned a lot from fixing these issues especially updating the dependencies/devDependencies in the package.json file. I never installed a npm tool before and found that installing one like npm-check can be quite helpful when fixing a bug. I learned how to install the npm tool by using these videos that are available here which is from the npmjs website. I also learned that updating module dependencies/devDependencies in the package.json file don’t always work as planned and you have to sometimes rewrite code to work with the new APIs they use.

Overall, I found solving these 2 bugs in Mozilla Brackets to be interesting and fun. I learned a lot from solving issue #589 and found using an npm tool such as npm-check to be helpful and time saving when updating a lot of dependencies/devDependencies in the package.json file. Also I learned that updating dependencies/devDependencies don’t always go as planned and you need to sometimes rewrite code in order to get the updates to work correctly, which is what I had to do to get autoprefixer and postcss working.

DPS909 Lab 5 – Preparing for Release 0.2 in Mozilla Brackets

For release 0.2, I decided to chose issues based on the brackets repository rather than Thimble. The issues I choose are:

1. Remove or Update issue template #593
2. Update node deps #589

These issues are fairly simple to fix. They do not involve modifying code but rather focus on documentation. I believe having proper and up to date documentation is important in open source projects. This makes it easier for contributors to find the information they need.

The first issue “Remove or Update issue template #593” was an issue filed by humphd. The issue is that when the Brackets repository got merged with the Adobe Brackets repository a file named “ISSUE_TEMPLATE.md” got merged into the repository. The purpose of this file is to provide the user with a template they can use when they want to file an issue they faced with Brackets. Since Mozilla Brackets has different features and requirements than Adobe Brackets, the template needs to be updated to fit with Mozilla Brackets.

Initially there were two options we could take to fix this issue, remove the file completely from the repository or modify the file to fit with Mozilla Brackets. I found the second option better because every repository should have an issue template for users to use and it makes filing an issue easier and more manageable.

humphd suggested some ideas on what information to modify in the file. They are:

• Get rid of the Prerequisites section
• Keep the section on Steps to Reproduce, Expected and Actual behaviour
• Change the Versions section to be about which Browser (name and version) and OS the user is using

I plan on modifying the file by using these suggestions and making sure the formatting of the file is clear for the user to understand.

The second issue I chose is “Update node deps #589”, which was also created by humphd. The issue is that the dependencies and devDependencies in the package.json file needed to be updated. It is important to update the package.json file so that the users know the versions of the dependencies that are used my Brackets.

In order to fix this bug I plan on following the suggestion given by humphd. Which is to examine the dependencies and devDependencies in the package.json file and see which one’s we are using that need to be updated. The professor suggested using a tool to accomplish this task such as npm-check. This tool is used for checking outdated, incorrect, and unused dependencies. Using this tool can make the process of checking each dependency easier. After I find which dependencies need to be updated I plan on changing the package.json file to fit with the updated dependencies and devDependencies.

Release 0.1 – Fixing bug 1001 on Mozilla Thimble

The bug I chose to fix on Mozilla Thimble was: The delete button is scary, because I don’t know what it’ll do

The problem with this bug is when the user wants to delete a project from their list of projects the pop-up warning message isn’t clear for the user. The warning message says “OK to Delete this project?”. This message doesn’t inform the user that if they delete their project, the published version of their project will also get deleted. Therefore this results in the user becoming scared to use the delete button.

The fix to this problem was relatively simple. I had to change the text that appears in the pop-up window to a more descriptive message. The message that was suggested by flukeout was “Are you sure? The published version of this project will also be deleted”. This message is more detailed than the previous message and informs the user that the published version of their project will also get deleted.

To fix this bug I changed the message from the previous one to the suggested one like this:

The fix was simple and didn’t take much time for me to accomplish.

This is my pull request: Fix #1001: Changed text for deleteProjectConfirmText

The struggle I faced when working on this lab was using vagrant to get the virtual machine to work properly. I didn’t have much trouble getting bramble to work but getting thimble to work wasn’t as easy.

I installed the virtual machine and got bramble and thimble working on my browser:

However for some reason when I make a change to a file in thimble it doesn’t automatically update on the browser. The only way it would show the changes I made was if I uninstalled the virtual machine by using the command vagrant destroy and re-installed it again by using vagrant up.

Overall contributing to my first bug in a project as complex as Mozilla’s Thimble editor was successful and accomplishing. Other than having to figure out how everything works and getting the virtual machine working properly, I found it fun and encouraging to contribute to this project. Although the bug I fixed wasn’t a big bug, it showed me the process that is required to contribute to an open source project.

In the future I would like to contribute more to the Mozilla Thimble project.

 

DPS909 Lab 4 – Working with branches, merging, rebasing, and gh-pages

This week I got to learn more about using branches, merging, rebasing, and gh-pages on git. I have had experience with using branches before but I never merged branches together or rebased my commits into one commit.

I found rebasing to be really helpful and useful to use in git. I always have different commits and don’t always want to share them when publishing to GitHub. Learning about rebasing helped me understand how to combine all of these commits into one commit which I found to be awesome.

Learning about GitHub’s gh-pages branch was also interesting. I never knew GitHub had this feature. The gh-pages branch is a special branch on GitHub that allows you to host static web pages. I found this to be useful to use when you want to play around with HTML and test your work. I also found it to be simple to use, all you need to do is create a gh-pages branch, add and commit the branch with the HTML file and publish that branch on GitHub using the push command.

Overall, I found these features to be useful to use in the future when using git.