DEV Community: Samuel Raphael

Hacktoberfest 2018: JavaScript OSS that needs contributors

Samuel Raphael — Mon, 01 Oct 2018 21:09:59 +0000

I've not been actively contributing to opensource projects before now but having been following Hacktoberfest for a while before it finally got started today, I've been trying to clear out time on my schedule to contribute to a few open source projects and here I am looking for open source javascript projects I can contribute to.

Why JavaScript

I decided to go with JavaScript because I've been working with it at work and I've been actively learning and growing my skills with the language.

Anyone who has a JavaScript-based OSS project that needs contributors can drop links and a little description of the project so I can have options to contribute to.

HelpMeToHelpYou

Testing A Node/Express Application With Mocha & Chai

Samuel Raphael — Mon, 24 Sep 2018 01:14:33 +0000

You have spent a lot of time and effort writing up a fairly medium application, let’s say with a code base of about 1000 lines and you’ve manually tested the application to make sure everything is running fine. You push your code to Github and someone decides to contribute their own quota to your work. They push their code, created a pull request and you merge it in, now your application no longer runs, everything is broken, all because of the code you merged in. In other to avoid this type of problem and many more that come with software development, you need to integrate testing into your workflow.

Testing requires that you write tests which cover various input a software might receive and the corresponding output to them. That way you can be sure that the application is running exactly how you intended it to and this can prevent a lot of bugs. It is always important to write a test before new code is added to your code-base so you can be sure the new code is not introducing any bug to your code base and also it helps you know beforehand if the new code is breaking any part of your code base.

In this article, we’ll be writing a simple Node/Express API application while incorporating testing using the mocha & chai JavaScript testing packages.

Mocha, according to the description on its website, is a testing framework that makes asynchronous testing simple and fun. It will provide the testing environment that makes it easy for us to run chai.

Chai is an assertion library that can be paired with any test framework. It is the library that we’ll actually write our tests with.

Setting up our sample application

We’ll be building out an application that reads information from a non-persistent students record data. To continue, we need to have the following files and folders created:

---controllers/
------studentController.js
---dummy/
------students.js
---routes/
------index.js
---tests/
------test.js
---.babelrc
---server.js
---package.json

To set up our dummy data, we need to include the data in the dummy/students.js file:

const students = [
   {
     id: 1,
     name: 'Sean Grey',
     age: 24,
   },
   {
     id: 2,
     name: 'John Doe',
     age: 26,
   },
   {
     id: 3,
     name: 'Janet Dane',
     age: 19,
   },
];
export default students;

The code block above assigns an array of objects, each object holding the details of a student.

Now let’s set up our package.json, so we can install all the packages we would be needing to build out and test our application.

{
   "name": "student-record",
   "version": "1.0.0",
   "description": "An API to manage student record",
   "main": "server.js",
   "author": "Samuel Afolaranmi",
   "license": "MIT",
   "scripts": {
        "test": "mocha --require babel-register tests/*.js --exit",
        "dev": "nodemon --exec babel-node --presets babel-preset-env ./server.js"
   }
   "dependencies": {
        "body-parser": "^1.18.3",
        "express": "^4.16.3"
   },
   "devDependencies": {
        "babel-cli": "^6.26.0",
        "babel-preset-env": "^1.7.0",
        "chai": "^4.1.2",
        "chai-http": "^4.0.0",
        "mocha": "^5.1.1",
        "nodemon": "^1.17.4"
   }
}

In the package.json file, we include our mocha and chai, which we’ll be using to write our tests. We also needed to include chai-http which is a plugin that allows us to run HTTP integrations with chai assertions. We can now run npm install to install the packages and get ready to finish setting up our application.

The next step is to create our routes and server.js files, but first, we should create our controller file as we would be needing to import it into our routes file. In the controllers/studentController.js file, we should include:

import students from '../dummy/students.js';
class StudentController {
    // Get all students
    static getAllStudents(req, res) {
          return res.status(200).json({
                students,
                message: "All the students",
          });
    }
    // Get a single student
    static getSingleStudent(req, res) {
           const findStudent = students.find(student => student.id === parseInt(req.params.id, 10));
           if (findStudent) {
               return res.status(200).json({
                     student: findStudent,
                     message: "A single student record",
               });
           }
           return res.status(404).json({
                 message: "Student record not found",
           });
    }
}
export default StudentController;

In the controllers/studentController.js file, we imported our dummy data, created a class to hold our controller methods and created two static methods each for what we want to achieve with the controller class. The first method, getAllStudents, as the name implies gets all the students record we have in our dummy data and returns them with a 200 HTTP status code, while the second method, getSingleStudent, gets the record of a single student and returns it with a 200 HTTP status. If a record is not found, a 404 HTTP status code is returned.

Now that we have our controller set up, we can now go back to working on our routes and server.js. In our routes/index.js file, we should add the following code:

import { Router } from 'express';
import StudentController from '../controllers/studentController.js';
const routes = Router();
routes.get('/', StudentController.getAllStudents);
routes.get('/:id', StudentController.getSingleStudent);
export default routes;

We imported Router (express router) from express and assigned it to routes, we also imported our StudentController class from our controllers/studentController. js file. We used the Router we imported to create two routes, which are tied respectively to their corresponding controller methods.

Now we should create our server.js file so we can test the code we’ve been writing if it works.

import express from 'express';
import bodyParser from 'body-parser';
import routes from './routes/index';
// Instantiate express
const app = express();
// Set our port
const port = process.env.PORT || 8000;
// Configure app to user bodyParser
app.use(bodyParser.urlencoded({ extended: true }));
app.use(bodyParser.json());
// Register our routes in app
app.use('/', routes);
// Start our server
app.listen(port, () => {
    console.log(`Server started on port ${port}`);
});
// Export our app for testing purposes
export default app;

Because we’re writing ES6 code, we need babel to compile our code, and for that to work, we need to add the following code to our .babelrc file:

{
   "presets": ["env"]
}

Now that we have our application all set up, we can go ahead to run npm run dev to run our application and test our endpoints using Postman.

Writing tests for our application

Our application works well, but we need to write tests for it. To make sure we don’t break it, while also covering all edge cases. In our tests/test.js file, we’ll write our tests.

// Import the dependencies for testing
import chai from 'chai';
import chaiHttp from 'chai-http';
import app from '../server';
// Configure chai
chai.use(chaiHttp);
chai.should();
describe("Students", () => {
    describe("GET /", () => {
        // Test to get all students record
        it("should get all students record", (done) => {
             chai.request(app)
                 .get('/')
                 .end((err, res) => {
                     res.should.have.status(200);
                     res.body.should.be.a('object');
                     done();
                  });
         });
        // Test to get single student record
        it("should get a single student record", (done) => {
             const id = 1;
             chai.request(app)
                 .get(`/${id}`)
                 .end((err, res) => {
                     res.should.have.status(200);
                     res.body.should.be.a('object');
                     done();
                  });
         });

        // Test to get single student record
        it("should not get a single student record", (done) => {
             const id = 5;
             chai.request(app)
                 .get(`/${id}`)
                 .end((err, res) => {
                     res.should.have.status(404);
                     done();
                  });
         });
    });
});

At the beginning of the file, we imported all packages needed to make the test run, then we configured chai to use the chai-http plugin. We also configured chai to use the should interface by running chai.should(). Each describe blocks are used to group our tests together for easier access and better organization.

The first it block is a test that runs on the first endpoint to get all student record from the data, it asserts that the response should have a status of 200 and it should return an object. The second it block is a test that runs on the second endpoint to get a single student request. Assuming the student exists, it asserts that the response should have a status of 200 and it should return an object. And finally, the third it block is a test that runs also on the second endpoint to get a single request. Assuming the student does not exist, it asserts that the response should have a status of 404.

All that is remaining is for us to run npm run test and we’ll see our tests passing before our very eyes. Beautiful, isn’t it?

How I Changed My Django App Admin Password

Samuel Raphael — Mon, 11 Sep 2017 21:09:02 +0000

I know most of all have fallen prey to setting a ridiculously hard password to our admin panels, saving them somewhere and loosing the password due to forgetfulness, or one of the other many reasons we lose our passwords.

This happened to me while working through a Django tutorial and I just want to document how I was able to solve it.

1) Access your python shell using:

python manage.py shell

This little code snippet will bring up your python shell development.

2) Next thing we will do is to get the lists of users and this can by done by:

a: Import Users from Django auth:

from django.contrib.auth.models import User

b: Assign Users objects to a variable and print it:

users = User.objects.all()
print users

This prints out the total users in your application, and you can select which is your admin. Generally though, the admin user is often always the first user created.

3) Select the ‘id’ of the admin user:

user = users[0]

4) Set a new password for the user:

user.set_password('the password')

5) Save the new password:

user.save()

Deploying Django Apps To Heroku

Samuel Raphael — Wed, 12 Jul 2017 21:47:59 +0000

After spending long hours trying to develop that perfect web app with Django, that feeling of the time being right, and the mood all set up to put it out into the real world and for users to enjoy and for your bank account(s) to start smiling, â€˜cause obviously, no users = no profit'.

But what happens when we can’t afford any of the expensive Server hosting sites? In this article, I will be showing you how to deploy a Django based web app (www.hellosam.ng) to Heroku for free.

Before we get started, What is this thing called Heroku and What is behind the magic of Deploying?

Heroku is a Platform as a Service website that allows you host your web app with basic functionalities for free. You can always create an account at www.heroku.com.

While Deploying involves the process of pushing our web application to a remote server so that the audience can have access to it.

Great! Now we can get started, Firstly, Heroku needs to be installed on our development Machines. (No Heroku installed? Then we would just be deceiving each other)

NOTE: I run a Linux (Ubuntu) machine, although most of the codes displayed here were written and geared towards the same OS users, I also made alternative provisions for other users running on other OS though.

To install Heroku terminal app on Ubuntu, type in the following command into your Terminal:

    sudo add-apt-repository “deb https://cli-assets.heroku.com/branches/stable/apt ./”
    curl -L https://cli-assets.heroku.com/apt/release.key | sudo apt-key add -
    sudo apt-get update
    sudo apt-get install heroku

On windows, you can either download the 32bit or 64bit versions.

For the MAC users, you can either download and run the installer, or if you have homebrew installed, you can run the following command to install it:

  brew install heroku

After installing,open up your terminal and login to your Heroku account.

    heroku login

Awesome! Now we have Heroku successfully installed on our local machine, and can now get started preparing our Django web app to be deployed to Heroku.

The next step is to create a requirements.txt file in the root of our web app. We need to have this requirements.txt file to let Heroku know our application is a Python(Django) project, else it won’t be recognized. Even if your web app has no dependencies, you can simply create an empty requirements.txt file. The requirements.txt file helps lists the app’s dependencies alongside their versions, this allows Heroku know what dependencies to deploy and the appropriate versions.

To quickly generate a requirements.txt file if you don’t know what dependencies your app has, or you’re just too lazy to create one from scratch (like me), you would need to start your virtual environment and in the root of your app, run in terminal:

    pip freeze > requirements.txt

The above command will get the list of your dependencies from the command â€˜pip freeze’ and copy them to the requirements.txt file, this automatically generates for you if it does not exist.

Once that has been successfully generated, we need to generate a Procfile in the same project root. This file defines process type and tells what command should execute to enable your app start. It will look something like this:

# Procfile
    web: gunicorn blog.wsgi –log-file -

The only difference between my Procfile and yours, would be the part before the â€˜.wsgi’. This part would basically be the name of your project, because the wsgi file resides in your project’s folder.

Next, we need to create a runtime.txt file. This file will carry explicitly the specific version of Python your projects makes use of. To achieve this, I’m sorry there’s no shortcut for this, you have to create a â€˜runtime.txt’ file in your Django project root and put in the exact version of Python you are making use of in the following format:

# Runtime.txt
    python-2.7.12

To get the exact version of Python you are making use of, run the following command right in the terminal with your virtual environment activated:

    python –version

Next we have to set up our static assets so our app’s front end designs won’t break when deployed to the server. We would need to install dj_database_url and whitenoise before we proceed:

    pip install dj_database_url
    pip install whitenoise

Don’t forget to update our requirements.txt file after these has been installed:

    pip freeze > requirements.txt

To configure our app’s static related parameters, we need to get into our settings.py file and change some parts of the file or edit accordingly.

NOTE: If you already have any of these settings all set up and working without problems, you do not have to change it:

# Settings.py
    STATIC_URL = '/static/'

    STATICFILES_DIRS = [
      os.path.join(BASE_DIR, "static"),
    ]
    STATIC_ROOT = os.path.join(BASE_DIR, "static_cdn")
    STATICFILES_STORAGE = 'whitenoise.django.GzipManifestStaticFilesStorage'
    MEDIA_URL = '/media/'
    MEDIA_ROOT = os.path.join(BASE_DIR, "media_cdn")

Also, we need to change our database declaration in our settings.py to the following:

# Settings.py
    DATABASES = {'default': dj_database_url.config()}

While importing dj_database_url at the top of our settings.py file:

# Settings.py
    import dj_database_url

NOTE: We do not need to add the whitenoise we installed to our wsgi.py file which is based in our project directory,

After this step, our wsgi.py file should look like the one below:

# WSGI.py
    import os
    from django.core.wsgi import get_wsgi_application
    from whitenoise.django import DjangoWhiteNoise

    os.environ.setdefault(“DJANGO_SETTING_MODULE”, “blog.settings”)

    application = get_wsgi_application()
    application = DjangoWhiteNoise(application)

The last thing we need to edit in our settings.py file is the ALLOWED_HOSTS part. Here we would need to put in the domain name our users would be making use of to access our awesome web app, else it would throw errors when we finally deploy.

Also, we need to turn off the DEBUG option. Here is how both lines should look like after editing:

# Settings.py
    DEBUG = False
    ALLOWED_HOSTS = [â€˜example.herokuapp.com’]

Finally we are ready to deploy! yaah!, but before we finally deploy, it would be best if we built this app and run it locally to be sure we do not have any error when deploying.

NOTE: This step is optional but I always do it as it helps me see any error before hand so I can fix completely and just deploy correctly at once.

Run this command to install all your dependencies locally:

    pip install -r requirements.txt

Then run:

    heroku local

Your app should now be running on http://0.00.0.0:5000. If this works, it means you can now successfully push to Heroku without problems.

NOTE: You might come across an error which states something along the lines of â€˜one of the static file you are referencing is missing’, all you need to do to resolve this problem is to remove the reference to the static file.

Now, we can deploy to Heroku:

    heroku login

    git add .

    git commit -m “Added for deploy”

    heroku create â€˜name-of-app-without-the-quotes’

NOTE: you can always leave out the name of app out of the command and Heroku will automatically generate a name for you.

Finally Run:

    git push heroku master

Access your browser and voila! your web app is live and ready for users to interact in real time!.

Read The F’ing Error Codes Bro!

Samuel Raphael — Wed, 19 Apr 2017 09:08:24 +0000

Disclaimer: This post is going to be pretty short as it’s more of a rant than an actual post.

So, one thing everyone knows about developers is that we all run into errors, bugs and problems with our codes a lot. Like someone said, as a developer, you spend 80% of your time fixing bugs and errors and I’ve come to almost believe that statement.

As we all know there are mostly two types of errors you would always come across as a developer, namely:

Syntax Errors: Where there is an error with the syntax of your code and it throws errors telling you where the error originated from and what’s causing it. (Emphasis on the ‘telling you’)
Logical Errors: Where the program runs successfully without throwing any errors but it does not give the desired results. (These are errors you always want to be extra careful of)

I will be ranting more about syntax errors today as, in my little (not up to 6 months) career in tech, I’ve already grown tired of peeps coming across syntax errors in their code and not knowing how to solve it, like — the error code and the big G exists for a reason bruh.

When you come across a syntax error, your program does you well by giving you a run down of what’s causing the error, so kindly read through it and try fixing it by following through with what the error code tells you. The error code almost always points to what’s causing the error.

In the case where you don’t know how to solve the error, the big G is always there to help you out. There’s always a probability someone has encountered your problem and they have documented how they got to solve the problem, that should also provide a pointer on the solution to the problem for you.

Most times, when you get to ask people the solution to an error you are getting and they don’t have a ready response, they would also have to consult the big G before getting back to you.

So, to put a stop to my rants I would say —

READ THE F’ING ERROR CODES BRUH!