Write Simple Code to Prevent Headaches Later

Consider the following code snippet:

someVar = false;

if ( anotherVar >= 1 ) {
 someVar = true;

Now, consider this rewrite:

someVar = ( anotherVar >= 1 );

Both snippets work as designed, so why is the second one better? It comes down to simplicity.

The first snippet includes an if block. It would be possible for another programmer to add logic into that block that, while not modifying the final result of someVar, increases the complexity of the code. This makes it harder to maintain in the long run.

The second snippet is very clear about what it does, and is more difficult to tack additional logic onto.

Work in progress on the Amtgard O.R.K.

I belong to an international live action role-playing game called Amtgard. I’m a relatively new player at the time of writing this, with less than a dozen credits in the game. However, I’ve been spending many dozens of hours working on a web application we use called the Online Record Keeper. While not the sole source of truth for Amtgard game records, it has certainly become a popular tool among players.

The application is written in PHP and is backed by a MySQL database. It doesn’t use a framework or a caching mechanism. The source code can be found on Amtgard’s GitHub.

It has great potential. There is a lot of awesome hidden in that code. But there’s also a lot of things that need to be fixed, and others that need to be iterated on.

After several months of working (on Saturdays, usually) on doing a complete rewrite of the UI from scratch in Laravel, I decided that the better move would be to fully own the existing code and bring it up to modern standards. By doing this, I get more buy-in from stakeholders and build trust for the future, but more importantly, gain a much deeper understanding of how the system is intended to work, not just how it appears to work.

One of the ways in which I’ll be doing this is by blogging about the work I’m doing on the ORK from time to time. This is the first such post.

There are three big issues which I’m concentrating on first. Continue reading “Work in progress on the Amtgard O.R.K.”

Get Going with Laravel on Docker

This post was updated May 14th, 2016 to significantly rework the tutorial.

Docker is slowly taking over the world of web infrastructure. It makes working with multiple different services easy, and the problem of “works in dev, not in prod” goes away, since you have the same environment on your local machine as you do in the production infra. It also makes things like trying out web apps without deploying them to servers really easy. Ever wanted to just check out a personal demo of, say, WordPress or Ghost? Docker makes that simple. Continue reading “Get Going with Laravel on Docker”

First Node.js Hackathon

My employer is hosting an internal Node.js hackathon. I’m organizing it, but I’ll also be participating since it’s small enough that the logistics side is not going to take up all of my time.

Everyone is charged with producing a Node app within 11 hours, and presenting to the group after that. For my project, here’s what I’ve decided to go with.

There are a few options out there for external commenting systems. You’ve probably heard of the big ones – Disqus and Livefyre. There are a handful of others, including Viafoura, Vicomi, and Instant Debate, but it’s a space that doesn’t see a lot of differentiation between the players.

I propose, as my project, a commenting system that doesn’t just facilitate discussion about a particular page, it uses meta information about that page to suggest similar discussions going on elsewhere on the site. Yeah, it’s a little bit of a walled garden in that it focuses on only one particular site, but for commercial applications that seems ideal.

Things that I’ll need to account for:

  1. User authentication. I think I’ll skip this entirely for the Hackathon, and just let users post anonymously.
  2. Retrieving meta information. I’ll need to automatically populate a datastore with information on other pages. Since I only need to worry about pages that have discussion on them, this can happen when the first comment is submitted for a given URL.
  3. A rapid datastore. Commenting systems generate a lot of content very quickly, and speed is more important than integrity.
  4. A real-time widget. The front end for this needs to be real-time, but gracefully so. Websockets are necessary.
  5. Standard interactions. The widget needs to account for what are now standard interactions for commenting – replying to a previous comment, flagging a post as spam, upvoting, and downvoting.
  6. A moderation back end. An admin interface, initially accessible without authentication, needs to let admins review posts held for moderation… and approve or deny them in real time. It also needs to let admins know if a particular page is missing meta tags. Again, websockets are necessary.
    Planned Components


I decided to go with RethinkDB as my datastore of choice. It’s very new and hence not production-ready, but its ease of use and blazing fast interaction suit this project well. The big problem to watch out for here is that Rethink loves eating up RAM with the current cache manager.

Frontend Framework

My focus lately has been on ReactJS by the Facebook team. It’s documented better than AngularJS, which was my go-to framework before this. It also has a more granular way of handling data binding that speeds up everything when dealing with a lot of elements on one page.


Definitely going to be using SockJS. Socket.io’s on its way out.

Web Framework

Express.js. I would love to use the newer, promise-driven Koa.js, but it relies on an unstable version of Node.

Task Running

Since the advent of Gulp, I have completely ceased to use Grunt. Gulp is just a better system, period. The only reason I’ve found to still use Grunt is if you need to use Yeoman to scaffold a project. So, with all that in mind, I’m using Gulp for this project.

Package Management

I use Bower. It has its issues (security?), but I’ve never used anything else and have no real reason to find another option.

Stylesheet Preprocessor

Sass. I’ve used both LESS and Sass, and Sass seems more reliable and predictable to me.

Unit Testing

If I have time to do unit testing (yes, yes, I know), I’ll be using Mocha. For assertions, I’ll use Chai. To handle checking test coverage, I’ll use CoverJS.

Other Components

I’ll be using RequireJS for sane modularization, Uglify for minification, and Twitter Bootstrap to style the whole thing quickly.