Andrew Scripts

Musings about Programming and Programmer Life-Skills

Category: JavaScript

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.name = 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.name = this.rank + " of " + this.suit
    this.graphic = '' // TODO
  }

  listItem() {
    var el = document.createElement('li')
    el.innerText = this.name
    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 Card.name.

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 – Oliver.prototype.blog

Use verbose naming in JavaScript – Oliver.prototype.blog.

Hallelujah!

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: