When I was working on my Second Release, I noticed a bug. You can find it here. And I thought that these bugs are related somehow to each other, so I might as well fix this one too! Only later on, I realised that they were not related at all 🙂 Which happens sometimes, you don’t always get what you expect.
In this lab we are going to learn some open source tooling.
So the first step is to read the instruntions! If you, dear reader, want to practice with me please go ahead and take a look here: https://github.com/humphd/Seneca2017LearningLab
The next step is to create a new repo and clone to the local machine. These steps are really easy, and are amazingly explained in the instructions by Mr. Humphry. So I am just going to move on to the next step.
Initialize a new Node.js Module
This part was not tricky for me, since I am a linux user, so let’s just move on to the next part.
Create your Node.js Module in seneca.js
So I created a seneca.js file. I put the code provided for us, and that’s how it looks now.
The next step is to implement those two functions. Which shouldn’t be hard.
First we need to implement isValidEmail, which basically validates if the provided email is a valid seneca email address. In order to do that, I am going to use regular expression. The second function returns a formatted Seneca email address.
Add ESLint to avoid common patterns and bugs
npm install eslint --save-dev
Today I am going to use Heroku. Heroku is a clod hosting platform.
Create a node.js Web Server
First, I am going to install Express using npm:
After creating server.js file and running it with the following command:
I got the following:
Now, after we tested our server.js and made sure that it works, we can move on to the next part.
Deploy to Heroku
Step 1 – Create your account
In order to create an account we should go here.
Step 2 – Download the Heroku CLI
After installing Heroku, you can login with your credentials:
Step 3 – Create Heroku App Settings Files
Next step is to create a Procfile which is going to look like this:
Step 4 – Deploy the App
First, I am going to create a new app using Heroku CLI:
After this, we need to make sure we added all of the files and committed them. Now we can push our code to Heroku.
By doing all the above we just deployed the our code to Heroku. Now we need to start the app.
heroku ps:scale web=1 heroku open
I found this lab really interesting and knowledgeable. Like all labs that I have completed in OSD600. I deployed an app!!! I learned how to create a node.js web server and what is Heroku and how to use it.
Unit Testing Frameworks
There are a lot of Unit Testing Frameworks, David Humphrey provided some suggestions for us:
I want to try using Jest.
Writing our first Test
First, I am going to install Jest. You can find the instructions here. Or just follow with me 🙂
In order to install, we need to run the following command:
npm install –save-dev jest
And it going to look something like that:
Basically, by running this command we installing Jest to our node_modules directory and also save it as a DevDependency in our package.json file. So let’s see how our package.json looks now!
As you can see now we have DevDependencies, with Jest added on the last line. Looks great so far!
The next step is writing the test. I really like what my Professor wrote about unit testing in the instructions and I want to have it in my blog to share this information with people who read the blog and for myself to remember.
“Next, I need to add a test. What should we test? Learning what to test, and how to write useful and complete tests is an art. It takes time, and practice will help you.
To begin, let’s write a single test for our
senecamodule and the
isValidEmail()function. A unit test should test one thing, and one thing only. Instead of trying to write a single test that will test everything at all once, we’ll write many small tests, each of which tests a single aspect of the code.” (https://github.com/humphd/Seneca2017LearningLab/blob/master/README-part2.md)
Now, when we know this useful information, we can move on to writing our first unit test. I am extremely excited!
Now I am going to create a new file: seneca.test.js. Which looks like this:
Running a test
Just something to keep in mind:
It’s often a good idea to write tests before you write your code. This is called Test Driven Development (TDD), and helps to make sure that your code evolves in ways that are expected, documented, and safe. It’s not always necessary, appropriate, or possible to do this, but it’s something to keep in mind. (https://github.com/humphd/Seneca2017LearningLab/blob/master/README-part2.md)
So let’s see how my implemented function is looks like:
Now it’s the time to run out test. We can run it from the command-line.
And even though my first test failed, it’s okay. Let’s fix the code.
Now, let’s try to run our test again:
I think that this lab is an amazing opportunity to play around with different editors, discover their functionality, possibilities and helpfulness.
Here is a time for a second bug fix for Mozilla!
Moving forward to the new horizons of Open Source world. To get more familiarised with Open Source and the way it works. For the past week I’ve been working on couple of things.
The first step is always the hardest step. Why? Simply because you are just afraid. It is something new, something you have never done before. Therefore, you don’t know what to do and what to expect. But once you have the courage to follow the path and make the first step, you feel amazing.
That what I have experienced this week. I was afraid even to try. But thanks to my Professor, who made it so much easier for us. I just simply followed the instructions. First I was searching for a problem which needs to be fixed. And I found it in gulp-util project.
What did I do next? Well, I saw that their package.json file was missing correct repository URL. I checked the URL in the Package.json validator and it couldn’t find the repository. So I forked the gulp-util repository, and cloned it to my local computer. This allowed me to edit the .json file easily. After adding the correct URL to the package.json file, I have validated the changes using Package.json validation site to be sure that the issue was solved. I pushed the file into my github repository and committed the changes.
Result? They didn’t approve my changes unfortunately. The reply was: “Our repository URL is valid by npm standards”. Which is honestly fair enough! I tried to make a small, but a useful change. However, as it turns out they even didn’t need it. Which I guess happens from time to time in the Open Source community. To be honest, that doesn’t make me feel bad. I know that it was my very first time, and now I am not afraid to make a contribution to the Open Source community.