Release 0.3

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.

Continue reading Release 0.3


Open Source Tooling and Automation

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:

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.

Screenshot from 2017-03-23 17-55-05

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.


Screenshot from 2017-03-23 18-21-08

Add ESLint to avoid common patterns and bugs

npm install eslint --save-dev

Screenshot from 2017-03-23 18-27-56


Screenshot from 2017-03-23 21-59-06




Screenshot from 2017-03-23 22-02-12



Screenshot from 2017-03-23 22-02-35



Open Source Tooling and Automation Part 3: Deploy to Heroku

Welcome everyone!

Today I am going to use Heroku. Heroku is a clod hosting platform.

Create a node.js Web Server

I am going to create a simple REST API for Seneca module using Express web framework for node.js.

First, I am going to install Express using npm:

Screenshot from 2017-04-06 15-21-37

After creating server.js file and running it with the following command:

node server.js

I got the following:

Screenshot from 2017-04-06 17-11-52


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.

Screenshot from 2017-04-06 19-08-47.png

Screenshot from 2017-04-06 19-08-56

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.


Open Source Tooling and Automation Part 2: Unit Testing

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:

Screenshot from 2017-03-30 17-54-11.png

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!

Screenshot from 2017-03-30 17-58-24

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 seneca module 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.” (


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. (

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:


First step towards the Open Source community

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.