Andrew Scripts

Musings about Programming and Programmer Life-Skills

Category: JavaScript

Making a Card Game in JS, pt. 2 – The Surprises

This is the second part of my series on creating a card game based on Dungeon Solitaire by Matthew Lowes. You can find the first part of this series here.

The Surprises

Since my first post in this series, I ran into a very strange occurrence of events which led to the setup I had been working with falling apart to the point that I could no longer use it. As such, this post is going to focus briefly on some of the backend infrastructure changes I’ve made along the way.

In the Beginning, there was a Glitch, and it was Good

From the very beginning, I had envisioned this game being a Single-Page Application (SPA). There’s nothing about this game that will require being backed by a database, nor is there any calculation so complex it can’t be handled by the front-end. Knowing these things, I decided to start this app in Glitch, an online IDE of sorts that allows you to code in the browser. While there are many things that make Glitch awesome, what I like best is the live-reloading combined with auto-save, so you instantly get an online, up-to-date app that you can test as soon as you write a line of code. (Remixing someone else’s app so you don’t have to do all of the boilerplate yourself is also really really nice.)

This was a fine setup until I ran into two issues which have more to do with me than they do with Glitch itself. The first was intermittent saving issues due to a spotty internet connection. Word to the wise: never do anything critical online over public Wi-Fi (looking at you Panera). This was tolerable until the time I lost 20+ minutes worth of work to it.

The second issue was ES6/ES2015 support. I wanted this app to be as cutting-edge as plain JS can get, so I wanted to make use of all of the bells and whistles of ES2015. Glitch’s built-in ES2015 support is limited to whatever Node supports, which meant that while most things worked, I couldn’t make use of import or export statements to make my classes modular (this was way back in the time before Node added module support). While there are workarounds to this, I decided if I was going to go to all that trouble I would probably be happier just running it all locally.

CodeKit is It – Until I Break It

My favorite tool for running local projects is CodeKit. It’s one of the easiest-to-use tools for handling all of the finicky backend server stuff and preprocessors that are annoying to configure and set up. Think of it like a GUI version of Grunt or Gulp. Usually, it works great. But because I can’t leave well enough alone, I tried to mess with one too many settings while trying to get the import/export keywords to work and ended up breaking something bad enough that I couldn’t get it to work anymore. Again, I’m sure this is another PEBKAC error, but I decided again that if I’m going to go to all of the trouble to try and fix what I did, I might as well bite the bullet and start over entirely with a hand-coded task-runner setup.

A More Modern Setup

Because I almost never start things from scratch well, I decided to look up tutorials on what others recommend. I found this article from Gina Trapani which echoed a lot of frustrations us web devs have over the moving-target which is JS development these days. That article led to this extensive guide from Jonathan Verrecchia (works at Yelp), which I followed as closely as I could.

The one step that blew me away was enabling Airbnb’s styleguide on my code via ESLint. I consider myself a pretty good developer, so I was shocked by how much sloppiness I had in my code.

All’s Well That Ends…

Okay, so now I’m back on track. NEXT time I’ll get back to the actual code at hand!

Making a Card Game in JavaScript, pt 1 – The Setup

I haven’t written here in a long, long time, but I think now’s as good a time as any to get back into it. I recently found myself looking for a new job; as part of the search, I created a portfolio website for myself here. But I found myself with a problem: I had no non-proprietary code I could show off on my portfolio. I decided I would make a game, one which I’ve been wanting to make for some time.

I’ve been playing this solitaire card game for awhile now called Dungeon Solitaire by Matthew Lowes. The game simulates deep diving into a tomb searching for the treasures buried there along with four kings. What I’ve always loved about this patience-style game is that it has simple-to-learn rules, uses a standard deck of cards so it can be played anywhere, and yet brings a rich story element to what would otherwise be ‘just another solitaire game’.

The Setup

I made the choice early on to create this game using plain, pure, vanilla JavaScript. I’m a front-end engineer by trade, so I figure making this game in plain JS would give me the broadest appeal to potential employers. I’ve used and liked Ember and React, and I’ve even tried Angular, but I have always felt MVC frameworks often are overkill for most applications.

The first iteration of this game is going to be text-based, with few or no graphics. A proof-of-concept. One of the first things I did was create a helper for DOM manipulation:

function getById(_id) {
  return document.getElementById(_id)

I could have made an alias to document.querySelectorAll(), but my general preference is to use IDs for JavaScript hooks, so if I know I’m going to have a unique ID for the majority of actions, then there’s no reason not to use getElementById.

The first object type I created was a Card object since this is a card game. JavaScript prior to ES6/ES2015 didn’t have a real ‘class’ system, so my first instinct was to create a plain object, especially since the Card object was going to be a very simple one. Here’s how it looked at first:

var Card = function(data) {
  this.rank = data.rank;
  this.suit = data.suit;
  this.value = data.value; = this.rank + " of " + this.suit;

This would have been fine, of course, but as I refactored some things as I went I reconfigured it into a class. Here’s what it looks like now:

class Card {
  constructor(data) {
    this.rank = data.rank
    this.value = data.value
    this.suit = data.suit = this.rank + " of " + this.suit
    this.graphic = '' // TODO

  listItem() {
    var el = document.createElement('li')
    el.innerText =
    return el

As you can see, not very different, but the class syntax does make some of it a little bit simpler to read. Also, I dropped the semicolons at the end of every line; again, for readability.

The second thing I added was a listItem() method. This gives me a quick and easy way to display this card in the DOM, similar to the convenience property for

That’s it for this post. Next time, I’ll start looking at the Game object and the Level object, as well as give you a look into the HTML structure of the app.

Use verbose naming in JavaScript –

Use verbose naming in JavaScript –


DailyJS: The State of Node and Relational Databases

DailyJS: The State of Node and Relational Databases.

Before I get started, let me say that if you’re into JavaScript development, you need to be subscribed to DailyJS. EchoJS likewise is an invaluable resource for the latest and greatest in JavaScript news.

I am a big fan of relational databases, having used them for many years now. I’m slowly trying to get my head wrapped around NoSQL options, and in fact have to work with CouchDB (now Couchbase) and Elastic Search at my job. But for most applications, I can ‘make sense’ of using a relational database over a non-relational one more often than not.

I’m also slowly getting into Node (server-side JS) more and more, but I haven’t dived completely in yet. So this article was very interesting to me, to get a broad overview of the options. Alex Young, the author, breaks up the various options this way (along with examples for each):

  • Driver – mysql and pg
  • Abstraction Layer – relational, any-db, and massive
  • Validator – jayschema, validator, and conform
  • Query Generator – sql
  • Schema Management – Sequelize and db-migrate

I’ve not included links to each on purpose. I think you should read the whole article if you’re interested, or at the least give Alex the inbound traffic out of courtesy and respect. 😉

He concludes by stating that even though there’s a strong anti-ORM (Object-Relational Mapping, an abstraction technique that turns relational database entries into objects) sentiment amongst the Node community, there are still some interesting projects like relational coming up.

He mentions briefly the progress that PostgreSQL has made (included by default when using Heroku), and also that MariaDB exists as a drop-in replacement for MySQL and has a non-blocking Node module. The comments are also sure to be a treasure-trove of implementation notes from others.

It’s Alive: Prototyping in the Browser

It’s Alive: Prototyping in the Browser

Good article about rapid-prototyping websites, includes links to some very useful tools like Sass, Serve, and Susy.

Not mentioned but also extremely useful for local web design: LiveReload and CodeKit, both of which will dynamically compile/process your Sass, Less, CoffeeScript, etc. code AND live-refresh your browser window, every time you save changes to your working files. Why hit the refresh button a million times a day?

JavaScript MVC Frameworks Overview – Addy Osmani

Journey Through The JavaScript MVC Jungle | Smashing Coding.

Addy Osmani:

If you’re writing an application that will likely only be communicating with an API or back-end data service, where much of the heavy lifting for viewing or manipulating that data will be occurring in the browser, you may find a JavaScript MV* framework useful.

Excellent overview of some of the more popular options for JavaScript MV* Frameworks, as well as thoughtful questions and a “Pros and Cons” guide to help you determine which framework might be best for you – and if you need a framework at all.

Side Note: Huge fan of Addy Osmani’s writings. He’s doing so much to help further client-side applications, and the newest version of TodoMVC is just one part of it.

Callback Hell

Callback Hell. Easily one of the most confusing aspects of doing anything asynchronously in Javascript. Highlights:

  • Name your functions
  • Keep code shallow (each function should only do one thing)
  • Modularize – featuring a quick and easy intro to CommonJS!
%d bloggers like this: