Slinging Mud: “Graceful” reboots in a Go world

I participated in MUDJAM on Itch.io last year around this time, putting together a very simple, low feature deliverable, BerkMud. If the title doesn’t tell you, it was How to Train Your Dragon themed. It wasn’t my first foray into building a mud but I wanted to do something new so I did it in golang which was completely new to me.

A year later, I got to thinking that there was a lot I had still wanted to do with it. One of those things was figuring out how some muds I used to play (DarkCastle) were able to reboot/upgrade the server without killing people’s connections.

Each player in a mud has their own permanent socket connection to the server. This socket is the sole medium from which the entire game is played. Normally when killing a process, all of the open sockets are closed, so rebooting the server to pick up any code changes would force all current players to have to reconnect

Carsforsale.com - Mobile app

Not a real technical post but still corresponding to something I’ve recently had a hand in (or two, writing roughly 25k lines in two weeks)…

Carsforsale.com released our first incarnation of a consumer facing (for all you car buyers out there) Android application. Check it out!

Publishing a NuGet JS library

First, this is a condensed version of a well written post that can be found here. I’m posting this as reference for myself and for those of you who just want the nuts and bolts.

I was recently working on an incomplete project that leveraged CKEditor for a WYSIWYG editor. The original developer had pulled in CKEditor via NuGet but was using the Auto Grow plugin and had manually added it. This is fine for development but murders the concept of dependency management. So, I found this post and quickly published an Auto Grow NuGet package.

Download and install the NuGet Package Editor
Open it up, click on “Create a NuGet Package” and fill our the left hand side (click the little edit icon to edit)
Add the files in the directory structure you want them output (using the project root as the base directory)

Note: Step 3 is somewhat tricky
Make sure you first right click and add a “Content”

Mobile Assets

Android Assets

Android devices come in all shapes and sizes and display resolutions. This means providing uniform assets across devices is tedious and somewhat complicated.

DP (Density Pixel)

Google created a special type of unit, dp (density pixel), to make dealing with assets easier.

How is that easier?

This unit generalizes all various display densities into a single display. What does that mean? It means a 100 dp x 100 dp will display the exact same on any device regardless of the device’s properties. So a 100 ppi device, 200 ppi device, 300 ppi device and 400 ppi device will also display the asset as the same size and same quality.

How does this magically happen?

It doesn’t

Assets must be created in a very special way to let Android do it’s thing. A designer needs to provide different assets for each generalized density type. What are these generalized density types and why

Oct 23, 2014

MEAN, Bower and Typeahead.js

Lacking time to write a full fledged post, I’ll only mention the quick tidbit I want to keep track of. Others might also find value in it:

Using the yo generator, angular-fullstack, I wanted to add Twitter’s Typeahead.js package via bower.

If all of this is greek to you, don’t worry, start with angular-fullstack and read through that page. You’ll quickly have a nice bootstrapped SPA running…

Back to what I was getting to. Typeahead.js breaks the Gruntfile script because of the “.js”.

Hashing dist/public/bower_components/typeahead.js...Reading dist/public/bower_components/typeahead.js...ERROR
Warning: Unable to read "dist/public/bower_components/typeahead.js" file (Error code: EISDIR). Use --force to continue.

Annoying and it’s more of an issue with the Gruntfile but an easy fix is to install Typeahead.js by providing a different name.

bower uninstall typeahead.js
bower install

Continue reading →

Austin Hanson

Read this first