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!
Top comments (0)