Posted on May 18, 2016 by Chris Harrington

Developing with Docker and Webpack

One of the big advantages of using containers in general is that you can keep your environments (whether that’s dev, test, staging, prod or even another developer’s machine) the same, which helps in tracking down those “prod only” bugs. Because of that, I won’t be using webpack-dev-server. I know, I know, but I’m really interested in making sure that my development environment matches the others as closely as possible, and webpack-dev-server is definitely not a production ready server. So, here’s the plan:

Continue reading

Posted on October 19, 2015 by Chris Harrington

Tutorial: Build a Time Picker with React JS

I recently wrote a tutorial on how to build a date picker with React JS, so I figured I’d expand upon that and detail how to write a time picker, too. First things first: just like last time, I’ve put the code up on GitHub if you want to see the full monty. I’ve also made an npm package and a bower package for the time picker in case you want to use it on your site somewhere.

Note: The code is far from production ready, so use at your own risk.

If you’d just like to take a look at the time picker in action, I’ve also put together a (really simple) demo page. Take a look!

Continue reading

Posted on September 21, 2015 by Chris Harrington

Tutorial: Build a Date Picker with React JS

I’ve recently been a pretty big fan of React JS and have been building most of my newer projects using it in combination with LESS and Webpack (both of which are awesome, although I hear the former is a little out of fashion in lieu of SCSS these days). Today, I’m going to be writing about how to create a date picker using React. I’ve made the source available and even published an npm package and a bower package in the event you want to use it in your fancy new React project. I wouldn’t call it anywhere near production ready, though, so be warned! For those of you who just want to see the date picker in action, I’ve put together a simplistic demo page that shows what you’re getting into. Anyway, on with the show!

Continue reading

Posted on September 7, 2015 by Chris Harrington

Implementing Sign in with Twitter for Node.js

More and more recently, I’ve been seeing small applications implementing sign in with Twitter, Google, GitHub, LinkedIn, etc. I think this is a great move for a number of reasons. First, so I don’t have to sign up for yet another account at yet another site, and secondly because app developers no longer have to implement their own user sign up scheme with all the trimmings: forgotten passwords, activation emails, and so on. I’m sure a lot of developers out there have those pieces of code as part of their toolbox, but for those who don’t, OAuth sign ins are so much easier to build. I’ve written a guide today that describes how to implement sign in with Twitter. And because I’m really into Node.js at the moment, it’s going to be written with JavaScript.

For those of you who just want to cut to the chase, I’ve made the server-side code available here.

Continue reading

Posted on August 5, 2015 by Chris Harrington

6 Reasons Why You Should Be Unit Testing Your Code

Most of the stuff I write here is code-heavy. I typically set out with a specific goal that I want the reader to accomplish by reading my articles, and most of the time, the posts I write take on a “how to” sort of format. I’m going to change things up a little today and focus more on the big picture with respect to unit testing. I think most coders out there have been preached to about the benefits of unit testing and how important it is, and I suppose this article is just another version of that.

So what is unit testing, exactly? Unit testing is writing code to test your code. It involves writing (or receiving) a test case in non-code which describes the input and the expected output for a small portion of a codebase. Once the test case is well understood, the coder can then build the test around it. A test is run using what’s called a “test runner”, unsurprisingly, which indicates the result of a test or group of tests (almost always “pass” or “fail”). A failed test will typically have a reason for the failure (for example, “expected 4, but got 5″) along with a stack trace. There are many, many different ways of writing unit tests, with many different libraries to make it easier, but the reasons for doing it are the same. Here’s six reasons why you should be unit testing your code, in no particular order.

Continue reading

Posted on July 4, 2015 by Chris Harrington

Creating a Simple Application Using React JS and the Flux Architecture

I’m going to talk about how to create a simple todo application using React JS and the Flux architecture. React JS is making some waves in the community recently due to its alleged performance increases over other heavy favourites (like Angular JS), especially when it comes to writing out lists. I’m not so concerned with performance, but I am interested in how to write an application that’s easy for the user to use while at the same time being quick to get off the ground.

Continue reading

Posted on June 9, 2015 by Chris Harrington

Clean promise chains using a pipeline

A few months ago, I started working on a project with a friend of mine who turned me on to the idea of channeling various asynchronous tasks into a pipeline. The idea is that, instead of polluting your local function with a bunch of .thens, you put each of them into a separate module, and then require them into a unifying function that does all the heavy lifting for you. I’m going to walkthrough my implementation of just that right now in a quick Node JS application.

Continue reading

Posted on May 11, 2015 by Chris Harrington

Testing a React project with Karma and Webpack

I’m a new fan of Webpack. It’s a great tool for intelligently bundling all of the packages your project needs and its watch feature is super quick. I’ve been playing around with it a bunch for my latest project which uses React (see here: Webpack with LESS and React) so I figure it was about time for me to start writing some unit tests to back up all that fancy code. I did a quick search for running Jasmine unit tests via Gulp that utilize Webpack’s bundling while also allowing for transformations of JSX files into raw JavaScript, but I didn’t have much luck there. I quickly settled on a Karma implementation, as there’s a plugin built especially for that purpose.

Continue reading

Posted on May 7, 2015 by Chris Harrington

Webpack with LESS and React

I’ve recently been playing around with Webpack and I really like it. It has the benefits of Browserify in that you can specify an entry point that’ll pull in all of your required modules into a single bundle with optional minification, while also letting you bundle your style together in your modules. For example, I can require a style file for a particular module right from the module itself, which allows me to somewhat limit the global nature of CSS rules. On top of that, Webpack allows us to leverage LESS in these included style files, too, that get compiled down to CSS. I’m a huge fan of this, as it allows us to create less coupled modules in that each style file can be tied directly to a module, and only gets pulled in when its required. Webpack also utilizes what they call “loaders”, which are basically preprocessors that perform various tasks. For example, there’s a LESS loader to convert LESS into CSS, and a JSX loader to perform a similar conversion for React classes.

Continue reading

Posted on January 26, 2015 by Chris Harrington

Performance of AngularJS, ReactJS and KnockoutJS Compared

I’ve recently written an article comparing React JS and Angular JS, and it’s been getting a fair bit of attention, so I figured I’d go one step further and show how well each of the two perform. I’ve also added in Knockout JS to the mix here just for comparison’s sake, and also some raw JavaScript DOM manipulation to give a base line as to how well things work across the board.

I’ve put together a quick page that allows you to see the rendering time difference between the three frameworks, plus the raw DOM manipulation. It’s what I’ve been using to figure out how long each framework takes to render large lists, as seen in the results table below. Take a look here.

Continue reading

Posted on January 23, 2015 by Chris Harrington

Creating custom social share buttons

At the top of this post, you’ll be able to see the Twitter, Facebook, Google Plus and LinkedIn share buttons I’ve made for the blog. All of them work the same way, and that’s by opening a popup window that allow you to sign in and share the current page you’re on to the appropriate network. I spent some time trying to get this to work in an iframe in a fancypants modal dialog, but I had no luck with that due to security constraints. Each of the four networks has a url to point to that’ll let you prepopulate a share widget with the url of the current page. I wasn’t able to find a repository of these urls online, so here it is.

Continue reading

Posted on January 21, 2015 by Chris Harrington

Optimizing meta tags for social sharing

I’ve spent the past few hours attempting to figure out exactly which meta tags I should include for my blog, and what the content should be. Ideally, I’d like my blog’s links to show up with fancy cards on Twitter, Facebook, LinkedIn and G+, and I’ve accomplished that. Here’s a breakdown of what I’ve added.

Continue reading

Posted on by Chris Harrington

Testing a Browserify project with Jasmine and Grunt

The WordPress theme for this site has been built (read: over-engineered) with Browserify and React. Most of it is pretty straightforward, but the widgets on the right are a little more complicated. I’ve only just started working with Browserify in general, so I had a relatively difficult time setting up a workflow for testing some of my modules. If you’re unaware, Browserify works by bundling up all of your CommonJS modules and any modules in your node_modules folder for easy use throughout your application using require. You provide the entry point to your application, and Browserify will step through all of the require statements to pull in all the appropriate files and modules. It’s a neat system and, in general, I’m a big fan of it, but I had to change the way I usually test my JavaScript files. I’m using Grunt for my build tool, so the goal here is to be able to type grunt test from the command line and have all my specs run as per usual.

Continue reading

Posted on January 20, 2015 by Chris Harrington

Concurrent watches with Grunt

I’ve been using Grunt with Browserify recently to build the theme for this blog ( and I’ve noticed that using grunt-contrib-watch in conjunction with Browserify is pretty slow: on the order of 1500ms on a JavaScript code change, which I felt was unacceptable. Watchify is a tool used to bundle Browserify modules on change that works much faster because it only rebundles files that have changed. This is great, but I run into a problem if I’m watching my LESS files at the same time, as each watcher will block. I’ve put together a quick Gruntfile that’ll allow you to run multiple watchers using grunt-concurrent, a Grunt task that’ll let us to run multiple blocking tasks at the same time.

Continue reading

Posted on January 16, 2015 by Chris Harrington

Comparison: AngularJS vs ReactJS

I’ve been wanting to write an article comparing the latest and greatest front-end JavaScript frameworks for a while now. I’ll be writing about Angular JS and React JS. Angular is the big dog in this fight, as it’s been around for a while longer than React has, but React brings increased rendering performance to the table.

The purpose of this article is to go over building some simple functionality using Angular and React to give you an understanding as to what it would take to get an application off the ground. It’s not meant as an in-depth tutorial on either of the frameworks. As such, I’m not going to go into great detail for a lot of this stuff. If you ever feel as though you need more clarification on a topic, either throw me a question via Twitter or comment below. The documentation for Angular and React is also pretty good. I’m hoping that after you read this, you’ll have a greater understanding as to which framework is right for you to use on your next project. At the very least, you should have a grasp on how JavaScript UI frameworks operate in general.

I’m going to walk through how to create the typical coding example using each of the frameworks. Once I’ve done that, I’ll move on to some more complicated UI controls, building up our little app as we go.

Continue reading

Posted on December 13, 2014 by Chris Harrington

Angular JS calendar using Moment and LESS CSS

Today, I’m going to talk about how to create a calendar control using Angular JS, LESS CSS, Font Awesome and Moment. I’m going to assume you’re at least halfway familiar with these tools, but if you’re not, I suggest you take a look using the links above. The calendar itself will be an Angular JS directive that allows the user to select a date, which is set on a controller’s property. I’ve styled the calendar, and I’ll include that style in this tutorial, but you can obviously feel free to tweak how it looks to your heart’s content. If you’re the kind of reader that prefers to view a completed product and just check the source yourself, I’ve put together a demo page which shows off the calendar. You can see it here.

I’m going to break down the write up into a couple of different sections. First, the HTML. It’s pretty straightforward, as it’s just the calendar directive HTML. Then, we’ll walk through the JavaScript code, which shows how I’m using Angular JS to update the directive’s state which, in turn, updates the calendar view. Finally, I’ll describe what I’m doing with each of the CSS rules that style the calendar. While most of the CSS is simple, there are few things I’m going to go over that might be new to the reader.

Continue reading

Posted on October 27, 2014 by Chris Harrington

Building a sliding modal dialog with Angular JS

The more I use Angular JS, the more I like it. I’ve been playing around with Facebook’s React recently, and I went back to Angular, primarily because I found React a little more restrictive with respect to two way bindings. I’ve built a modal dialog control in Angular which I figure you guys might find useful. The modal dialog itself is an Angular directive, and I’m using LESS for some of the slightly more complicated CSS rules. I’m going to assume you’re relatively proficient with both, but if you’re not, I highly recommend you check them out before plunging into this tutorial.

If you’re the sort of reader who just wants to see the whole thing in action, feel free to take a look at the demo page I’ve put together that shows off the whole thing. Viewing the source on that page should give you a pretty good overview of what’s going on.

Continue reading

Posted on September 29, 2014 by Chris Harrington

Animated rotate directive with Angular JS

I’ve recently been playing around with Angular JS and I like it, and so decided to spend a bunch of time converting Leaf from Knockout to Angular. It’s not that I think that Angular is substantially better than Knockout (that remains to be seen) but rather that I figure this is a good way for me to figure out the ins and outs of a new framework. One of the things I really like about Angular is building custom directives. I’ve only been tinkering for a week or two, but I already have dozens of custom directives for all sorts of situations and code snippets. They’re very, very handy.

So in that vein, one of the directives I’ve built revolves around rotating an element based on an Angular scope variable. My first use case for it was for expanding a sliding drop down. In the collapsed state, there’s a Font Awesome angle down icon that indicates to the user that it can be expanded, and after expansion, it changes to an angle up icon to indicate that the user can click again to collapse the panel. The following rotate directive is used to animate a rotation from up to down.

Continue reading

Posted on June 18, 2014 by Chris Harrington

Setting up a Node web server on an Amazon EC2 instance

Up until recently, I’d been hosting Leaf on Heroku. I had a pretty good experience with Heroku and would recommend it to anyone whole heartedly, especially if you’re just getting into the Node space and want to play around a little. It has a free sandbox plan, it’s really easy to get started. That said, however, when you’re getting a little more serious, the cost of Heroku’s offering is almost twice as much as what Amazon offers. Prices today sit at $34.50 for two “drones”, which are the equivalent of two EC2 instances, while the EC2 instances themselves can be purchased for as little as $9 a month (or $18 for two instances). On top of the price difference, EC2 instances have the benefit of being almost 100% configurable, so I can poke around and do however I please.

From here on out, I’ll assume the reader is familiar with Amazon Web Services and have already spun up an EC2 instance with SSH capabilities. I’m using an Amazon Linux instance, but any of the *nix based instances will do the trick.

Continue reading

Posted on by Chris Harrington

Shim to customize output strings for date inputs on mobile browsers

I’ve recently been playing around with the HTML 5 date input controls. They’re pretty robust, especially in the mobile space, as all of the major mobile players have excellent support for most HTML 5 tags. One of the downsides that I’ve come across, however, is that the date controls don’t support the placeholder tag, or any custom display strings. So if I want to show a date in a particular format, I’m out of luck, as I have to stick with the standard “yyyy-MM-dd” format that most browsers natively display the date in. For the most part, that’s ok, but I spent some time coming up with a solution that provides both placeholder and custom date format support to the input date control.

A note here: each browser handles the date controls a little differently. Chrome on the desktop, for example, shows a bunch of different options for setting the date, including typing the numbers for each of the year, month and date fields, while also providing an arrow which opens up a date picker. Mobile browsers all open up the date picker while tapping on the input, which is great for this solution. However, this solution won’t work for desktop browsers, as the date picker doesn’t show until the user clicks on the little arrow, which is invisible.

Continue reading

Posted on May 5, 2014 by Chris Harrington

Using document fragments to append html to the DOM with JavaScript

The Problem

I’d recently been asked to solve some performance problems with a page that had previously been built. The page is responsible for allowing the user to choose an airport. It has some other fancy stuff going on, like favouriting airports and such, but the bottom line was that it was simply a list of airports, one of which the user would select. We saw some unusually high rendering times for the page and when I dug into the code, I saw that the page was being generated dynamically by using JavaScript to iterate over a JSON list of airports and building the view from a template. That list of airports was retrieved asynchronously, which is why the page is built using JavaScript instead of being rendered on the server. There’s a couple of ways to build pages in JavaScript with jQuery.

Continue reading

Posted on April 28, 2014 by Chris Harrington

Page change progress bar for jQuery-enabled single page applications

Leaf is a single page application, which means that only a portion of the page changes when navigating between pages. This has a number of benefits that I don’t want do delve into at the moment, but suffice to say it trades (optionally) longer initial page load time for speedier navigation and potentially fancier page transitions. One of the downsides, however, is that the developer has to build his or her own method of informing the user that a page change is taking place. I’ve noticed recently that YouTube does an excellent job of this. It puts a “line” progress bar at the top of the page that shows up when you click on a YouTube video to watch. The line behaves like Safari’s progress bar; it jumps a little at first to say, “hey, your page load progress is here!” and then completes as the new content loads. It’s slick and subtle and I like it, and I’m going to show you how you can do it yourself.

To start with, I’m using the excellent Nanobar library. It’s what lets you put the progress bar at the top (or wherever) of the page. First, obviously, include the Nanobar javascript file in your SPA’s root page.

Continue reading

Posted on April 15, 2014 by Chris Harrington

Stubbing included functions with Sinon while unit testing in Node

I’ve recently been on a unit testing bender with Leaf; I was able to get to 100% code coverage. I understand that while I might have 100% coverage, I might also have shitty tests, but I feel the inverse is also true: if I have 0% coverage, I most definitely have shitty tests. Either way, I ran into a few hurdles while writing all of these unit tests and I’d like to share how I got around one of them in particular. Most of the libraries that I require in Leaf expose a number of methods for me to use, which is great, because they’re easy to stub using Sinon, as such:

var getStub = sinon.stub(obj, "get");

Continue reading

Posted on April 10, 2014 by Chris Harrington

Securing configuration files with Node for Travis and Heroku

I’ve recently been building an issue tracker using Node called Leaf. It’s a fun project that lets me dive into Node and learn its pros and cons. It uses a number of services that require either API keys or username/password combinations and I ran into the problem of how to secure these sensitive bits of information so that anyone browsing my Github repository wouldn’t be able to sign into those accounts for nefarious purposes.

Leaf is using a couple of different services. It uses Travis for continuous integration and Heroku for scalable hosting (both are excellent, by the way). The convention for configuration variables in Node is to use environment variables, which means that for every environment that builds and runs the application, we have to set the environment variables that correspond to each of our configuration variables. It’s quite the pain in the ass. I’ve broken down this post into three sections, one each for setting the appropriate environment variables locally, for Travis and for Heroku.

Continue reading

Posted on January 23, 2013 by Chris Harrington

Caching using aspect oriented programming with PostSharp

I’ve been hoping to add some caching to an application recently. It’s not a slow app, per se, but I figure that some caching is probably better than no caching and I’m expecting the app to grow, so it’d be nice to have the extra scalability available in the future.

My solution makes use of aspect oriented programming through PostSharp in C#. If you’re unfamiliar with AOP, the gist of it is that we’re modifying the behavior of methods before and after they’ve been called. In this case, I check a globally accessible cache before the method is executed to determine if I’ve got a cached result and, if so, return that instead of calling the method. After the method has been called, the result is stored in the cache so that the next time it’s called, we can use the stored value instead of executing the expensive method a second time.

Continue reading

Posted on January 21, 2013 by Chris Harrington

jQuery, widths and hidden elements

I’ve recently been doing some front-end work which involves modifying widths of DOM elements using jQuery. The standard method of modifying the width of an element is as such:

$("some sort of fancy selector").width(100);

As of jQuery 1.8, users are now able to set the outer width, which is defined as the width of the element plus any padding and borders. An optional flag allows you to set the width including margins, too, but only for the getter.

$("fancypants selector").outerWidth(100);

If, however, you need to read the width of an element that’s hidden, jQuery will calculate the width of a hidden element to zero in every case. This makes sense, as the element is hidden and taking up no room on the page. It’s kind of a pain in the ass, though, as in my case, I needed the current width of the element to calculate what the width should be. A handy trick for solving this problem is to set the display’s opacity to some small amount, showing it, then measuring the width. Afterwards, the element can be hidden and its opacity restored to 100%.

Continue reading