Monday, September 30, 2013

Learning to Build a Server with Puppet in (almost) a Day

My development environment is a complete mess. I have multiple versions of various stacks from Ruby to NodeJs and I've run into so many issues trying to keep things compatible that I need to start splitting environments up by project. Its something I knew I would have to do but just didn't want to invest the time setting it up. What I needed was a easy way to spin up a base environment and, by project, describe what the environment should look like. Some research led me to several options like Vagrant, Razor, Capistrano, Chef, and Puppet. Ultimately, I chose to keep it simple by using Puppet in standalone mode to describe the configuration and use a combination of bootstrapping and git to deploy a new environment. As a side benefit, my fellow developers could easily replicate the same environment and these configurations could serve as a basis for building staging/production servers. In theory, the challenge should have been learning the syntax of a Puppet manifest including what modules existed that would do a lot of the work for me. However, as it turns out, I had a lot of problems just getting the puppet command line program to even run. In total, I spent about 3 days building a base VM image, installing the minimum environment to run Puppet, and writing my manifest.

Monday, September 23, 2013

Controlling the Container Element for Backbone Views

I always like when there is more than one way to do the same thing. Flexibility and choice is always good. It can, at times, be confusing which approach to use - especially for beginners. When starting out with Backbone, I spent a considerable amount of time trying to determine the "best-practice" to rendering a view and adding it to the DOM. It was clear in the documentation that more than one method could be used, but after reading through some examples, the following scenario seemed the most common:

Monday, September 16, 2013

Integrating Socket.IO into a BackboneJS Project

There's a lot of opportunities to add real-time features to an application. Since Backbone already has an excellent notification layer built into its models, it seems only natural to apply incoming changes from a Socket.IO connection to a view's bound model or collection. Instead of fetching all the data periodically, the server pushes changes down to your application and you apply them to the data.

As a simple example, suppose our server will emit a "changed" event when something important changes in the data we're displaying. The data sent in the event contains the pertinent record we have in the model/collection. In this case, the model has a few fields and contains a collection of "places" that could be added to as part of the update.

Monday, September 9, 2013

Using SVG Filters to Create Outlines of Shapes

I needed a quick way to add an outline around an SVG shape without having to create one for all the shapes I was using. I knew I could use a filter for a drop shadow effect so figured that there must be something that could make this possible.

I finally found the solution using the dilate operator of the feMorphology filter. This made a copy of the object and expanded out a certain radius. Next, I remapped all the colors so the expanded shape was yellow. I blended that behind the original shape to produce my outline:

Apply it to any shape to create a yellow outline around it:

`


That seemed pretty easy except when you'd like to have more control of the color of the outline. Using the feColorMatrix to remap the input shape's color to a single color that will represent the outline is somewhat difficult. If you want simple primary colors, you're probably fine. Outside of that, and its not as easy.

Tuesday, September 3, 2013

Addressing the Subtle Differences between Socket.IO WebSockets and XHR Polling Transports

I was quite excited to see my game working with WebSockets in my development environment only to be disappointed when I deployed to Heroku and found the Cedar stack does not currently support WebSockets. Once I switched to XHR Polling, I started having some odd issues that took some time to track down the actual problem. Essentially, the game would start and players could interact as expected. After about a minute, players would start showing as leaving the game when they actually did not. This implied that the disconnect event fired on the socket which caused it to update the player record and emit a "left" event. Looking through the logs confirmed the drop so I started looking at the different timeouts and suspected something was not working properly with the "close timeout".

After exhausting that angle, I stared at the logs more and finally noticed that the socket ID being disconnected wasn't actually the one doing the polling. It turned out that if a player refreshed the browser, the socket didn't actually disconnect like it did with WebSockets. Instead, it hung around until the close timeout and then the server dropped it. The problem was that the player had a new active socket and their old one disconnected and subsequently marked them as leaving.