• Ghost/Github Blog
• Deck of Cards API vanilla node app
• Record Cataloger Meteor App
• Meteor 1000 Books by Kindergarten Meteor App
• Sudoku Solver
• Freeflow Solver
• Crafty Spending App with Charlestronauts

So the big question is...

What have I been working on?

And the winner is, none of the above! At my job at Blue Acorn, I have had the priveledge of working on some side projects with @BriceBurgess, our resident Dev-Ops aficionado. Dev-Ops has been a personal goal of mine over the last year to contribute more to Blue Acorn. One of our major company initiatives has been to coordinate the automation process for building better websites, with continuous integration testing which will result in more robust deployments. It has been great fun with I am learning a lot.

How does this relate to log4js-node?

One of the resources that we use at Blue Acorn is the Atlassian product, Hipchat. Hipchat is slowly being adopted as our company chatting tool, but also as a source of logging and recording for our different Dev-Ops tools. For our un-hipchat-integrated internal apps, we have been using the log4js-node library, which is the node version os log4js, which allows a user to set log levels for better logging information for your application to log to your console. However, another feature of the log4js library is the concept of Appenders.

Finally just tell me what the point is

I decided to extend the log4js library to support logging to the hipchat client, using both log4js-node and a new node library hipchat-client with an appender specific to hipchat. Hipchat-client implements the hipchat V1 api to connect to hipchat, allowing you to post messages or notifications to specific rooms. Thankfully there were a number of examples provided with the log4js-node github repo but the most useful resource I was able to use was the mailgun.js, which functions to allow lof4js to send it's log through a registered mailgun account.

Lets look at hipchat.js

The file is relatively straight forward. Every log4js appender needs to have 2 distinct functions that the log4js-node library looks for:

exports.name = 'hipchat';
exports.configure = function(){[...]};
exports.appender = function(){[...]};

These functions inform log4js how to configure the new appender, or logging service, within the log4js library. An example of how to use the hipchat appender might better inform how these functions work:

var log4js = require('log4js-node');

log4js.configure({
  "appenders": [
    {
      "type" : "hipchat",
      "api_key": 'Hipchat_API_V1_Key',
      "room_id": "Room_ID",
      "from": "Tester",
      "format": "text",
      "notify": "NOTIFY",
      "category" : "hipchat"
    }
  ]
});

var logger = log4js.getLogger("hipchat");
logger.warn("Test Warn message");//yellow

When configuring your log4js instance within your application, when you declare your appenders in the json, the log4js module will loop over all the appenders listed in the appenders: [ ] and load them into the library instance by their type, which should match the exports.name provided in the appender, found here. It will bind the above configuration to the appenders exports.configure method based off of the category provided. Then when .getLogger('hipchat') is called, it will load an instance of the saved appender with the bound configuration provided from the json object. When the form of log is called, logger.warn('Test Warn Message') or logger.error("Test Error Message"); this will call the exports.appender method.

Important appender functions

exports.configure

Here is our exports.configure function.

function configure(_config) {

    if (_config.layout) {
        layout = layouts.layout(_config.layout.type, _config.layout);
    }

    hipchat = new HipChatClient(_config.api_key);

    return hipchatAppender(_config, layout);
}

Basically stated, this function configures the appender instance to set the custom layout for the appender if a layout was established in the json configuration. It then instantiates the hipchat client for this loggers instance which will connect to hipchat with the specified api_key. It will then return an instance of the hipchatAppender which informs log4js where to render the formatted text for hipchat.

exports.appender

function hipchatAppender(_config, _layout) {

    layout = _layout || layouts.basicLayout;

    return function (loggingEvent) {

        var data = {
            room_id: _config.room_id,
            from: _config.from,
            message: layout(loggingEvent, _config.timezoneOffset),
            format: _config.format,
            color: colours[loggingEvent.level.toString()],
            notify: _config.notify
        };

        hipchat.api.rooms.message(data, function (err, res) {
            if (err) { throw err; }
        });
    };
}

This function establishes the layout/formatting function for the log4js event that occurs when the LoggingEvent is registered for the appenders function. If no layout is specified for the then the log4js basicLayout is used, which just generates a string with the format of [DATETIME][LOG_LEVEL]category - log text.

Then everytime a LoggingEvent is registered for this log4js instance it will trigger function which will build the var data from the registered configuraton for the appender, and the layout established, and pass the data to the hipchat.api.message function which logs the message to the hipchat client.

Notables

var colours has been appended to this appender since the hipchat colors are more limited than the default log4js colors.

package.json needs to include hipchat-client or when trying to log to hipchat an error will be thrown that will declare the hipchat module is not found.

Working Hipchat logger

To Be Continued

This was the first step to get logging to hipchat for BlueAcornInc, but I decided to try to give back to the greater node community by trying to create a pull request back into the original node4js repo.

This required me to learn the javascript library vows. See you next time.

A few of the things on my list:

• Ghost/Github Blog
• Deck of Cards API vanilla node app
• Record Cataloger Meteor App
• Meteor 1000 Books by Kindergarten Meteor App
• Sudoku Solver
• Freeflow Solver
• Crafty Spending App with Charlestronauts

How was this blog built?

This blog was built using ghost-render.
Using github's pages to render the final blog, locally I am writing these posts in markdown, which is ideal. It was rather tricky to set up however. There were a couple unintuitive things I needed to do in order to get the repo working perfectly. I will try and review the process I went through. Some steps may be basic, but it will be best to be thorough for all audiences. (that's being optimistic!)

Step 1: Create username repo

Since I wanted to host the blog with github, this step was the easiest. Creating a repo called username.github.io will automatically created a hosted static website to display your website.

Step 2: Setting up the local environment

git clone <username.github.io repo>
cd <username.github.io repo>

Once inside this repo follow the instructions for ghost-render. I decided to do the entire process within a folder called chris_potter_blog/ in the repo.
I will recount them here for good measure.

npm install -g ghost-render
ghost-render --init > settings.json

Themes

I decided the theme(s) should be organized into their own folder for cleanliness. I decided to try and jump between themes for testing. Each theme I decided to fork into my personal repo so that I could make changes and commit those changes to my own theme.

Build process

I decided to write my own bash script to compile my blog. Creating the script is simple:

touch compile
chmod +x compile

within that file I added the following code:

#!/bin/bash

ghost-render --input ./blog/ --settings ./settings.json --theme ./themes/Swaggy-Bastard --output ./rendering

running sh compile within the chris_potter_blog folder will create the rendering/ folder with the contents of the blog. Once this is complete, from the base folder of the repo, run

ln -s chris_potter_blog/rendering/* .
touch .nojekyll

I decided to symlink the information in the rendering folder to try and keep the repo relatively clean and tidy for the build process. If you feel this is overkill, then don't do it!

The final issue lies with the themes repos declared under the themes folder. Git considers these sub-repos of the blog. So I needed to touch .gitmodules and within that file have:

[submodule "chris_potter_blog/themes/Swaggy-Bastard"]
    path = chris_potter_blog/themes/Swaggy-Bastard
    url = https://github.com/cpotter/Swaggy-Bastard.git