Artifex Contra Mundum

A Developer Against the World

AWS Elastic Beanstalk… what the walkthrough failed to mention

I’ve been pounding my head against the wall for the last week trying to get a handle on building Rails apps on AWS’s Elastic Beanstalk. In theory, its a pretty cool system… you can very easily spin up a Linux environment and deploy your code right from git, using a nice set of command line tools that were only mildly irritating to configure.

That’s the theory, anyway. After a week’s effort, I have yet to deploy even the most trivial Rails app (other than the Amazon sample app, which naturally works perfectly fine). You can read the entire saga at Stack Overflow, but the TL;DNR version is that, even though I have followed Amazon’s tutorial with the scrupulosity that is the very hallmark of my creed, I cannot get my own Rails app to run on Elastic Beanstalk. Thankfully, this problem has been confirmed by a couple of third parties, so I take comfort in the fact that I am not a total idiot.

As an experiment, I attempted to get a Node.js/Express app running on Elastic Beanstalk as well, following this tutorial. I was successful and found myself intrigued by the possibilities of express. I like MVC-ish frameworks with good package management and good community support, which is what was attractive about Rails… perhaps node and express could fit the bill as well.


XCode Asset Catalog Weirdness

I have an iOS app that has mutliple targets. 23 of them to be exact and each one of them is an separate app in iTunes. That means lots of icons and lots of launch images. When asset catalogs came on the scene, I thought they were the answer to all my hopes and dreams. Maybe this isn’t the way they’re intended to be used, but what I did was create a separate asset catalog for each target and then assign the icons and launch images as needed.

As I was going through this herculean task of creating new asset catalogs, I noticed something weird.. by default, when creating a new asset catalog by migration (that is, migrating from the old “magic name” method of managing icons and launch images), XCode creates assets named “LaunchImage” and “AppIcon”. After setting all the icons and launch images for several target, I wanted to go back to a previous target and double check that I’d chosen the right image. I noticed that in the asset catalog dropdown on the “General” page of the project settings view, the proper asset catalog was not selected. Rather, the most recent one I’d configured was. I discovered that if I then changed it to the correct one, the next target I inspected was set to the one I’d just changed. In other words, all the targets were set, at least according to the dropdown, to the last one I’d modified.

After a lot of panicking, I realized that this was because, while I’d changed all the names of the *.xassets files, I’d left the default names of the assets (i.e., “LaunchImage”, “AppIcon”). If I gave these files unique names (i.e., “TargetALaunchImage”), however, the selection in the dropdown “stuck.”

I’m not sure if it was just the XCode UI that was messed up or if the wrong assets would have actually been used when archiving, but from now on I will be sure to give these assets unique names.


Getting Started with CocoaPods

How familiar is this scenario:

You show up for work one morning, filled with optimism and brimming with anticipation at the prospect of all the amazing code you are going to write in the next 9 hours. Ones and zeroes will be bullied into submission, incredible feats of logic will bend the very fabric of reality and the world will be vastly improved by the helpful and elegant programs you will create. Wealth, beyond the dreams of avarice, are just one App Store submission away.

You make your morning cup of coffee, wiggle the mouse back and forth a couple of times to wake your sleeping computer and crack your knuckles. You pull the latest code from the VCS, already thinking of the first line of code you will write. Your fingers, hovering just inches above the keyboard, tingle with anticipation. You are like a thoroughbred in at the gate, awaiting the starter’s bell. Your IDE loads the project. You are ready to code.

But then the unexpected happens… red, squiggly lines of death pop up in open implementation files and errors fill the message log. You check the VCS commit log and see that your nemesis, err, “colleague”, added a fancy pants library from GIT to the project that he just had to have to bring his vision to life. To your horror, you see that he forgot to add the files into VCS. Firing up Skype, your heart sinks as you see that this fiend in human form’s last message was “Leaving on an African Safari… see you in six months!”

Your gentle spirit is crushed beneath the weight of a thousand unresolvable dependencies as you realize that it is going to be a very long morning. Your mind, contemplating the soul destroying prospect of the next 4 hours, turns to the image of the snake devouring itself. You know now that you are caught in a cycle of eternal return, doomed to repeat the same sisyphean exercise for the rest of your career.

Or are you?

Enter Package Management… from NuGet to RubyGems to APT, there seems to be a flavor of package management for every platform and Cocoa is no exception. Gaining support in the cocoa development communities, many of the libraries that FTW use on a regular basis have official support, such as MapBox, while others still are expected to in the future, such as Parse. But even those libraries lacking official support have packages (or ‘pods’) maintained by the community. XCode 5 will even have a cocoapods plugin.

Here’s how I got started with cocoapods:

OPTIONAL – Even though Macs come with Ruby installed, it uses a fairly old version. I recommend upgrading and using RVM. An easy way to do this is via RailsInstaller

http://railsinstaller.org/

It will install Ruby 1.9.2, Rails 3.2 and, more to the point, RVM. Its easy.

1) Assuming you have followed my sage advice and upgraded Ruby and installed RVM, to install CocoaPods, run the following in the terminal (f you are not using RVM, you will need to run the command using sudo):

1
$ gem install cocoapods

TIPS FOR YOUNG PLAYERS: CocoaPods is under active development and new releases are a regular occurrence. To update, run the following command in the terminal, using sudo ONLY if you are not using RVM:

1
$ gem update cocoapods

2) Run the following command in the terminal window:

1
$ pod setup

CocoaPods is now installed and configured! Go buy yourself an ice cream sundae for your efforts.

3) Pods are managed through a file called a ‘Podfile’. At its simples, a Podfile could look as simple as something like this:

1
pod 'ObjectiveSugar', '~> 0.9'

This would add the pod ObjectiveSugar to your project. It also uses the optional version specifier, in this case version 1.0. If you do not specifiy a version, it will install the latest available.

TIPS FOR YOUNG PLAYERS: The version specifier in the example above would install the latest possible version of the app where the version is 0.9.x. It would not install 1.0. If you are feeling bold, you could write the following to get the head of the repository.

1
pod 'ObjectiveSugar', :head

4) Save your Podfile in the top level of your XCode project and be sure to call it ‘Podfile’. Now run the following line:

1
$ pod install

This does several things: In addition to downloading all required dependencies, it creates an xcode workspace file, it adds your project to the workspace and makes several configuration changes to a newly created target.

5) Hopefully, you saw your dependencies being installed magically. Now, to use your CocoaPods with your project it is of uptmost importance that, when opening your project in XCode or AppCode, you DO NOT open the xcode project file, but rather open instead the newly created workspace file. This is what we will develop and debug in, and this is what we will build from. For more information on XCode workspaces, read this:

http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/

Having opened the workspace in our IDE, we can now import our dependencies and start coding:

1
#import <ObjectiveSugar/ObjectiveSugar.h>

For more info and to find CocoaPods packages, visit your local library… or better yet, go to the CocoaPods page itself.

For installation troubleshooting, check their handy guides.

There are Pods for these perennial favorites:

TestFlight Parse MapBox UrbanAirship

Uninstalling Pods couldn’t be easier: Simply remove the pod from the podfile and run ‘pod install’ again. Updating pods is much the same… simply re-run pod install.


A map renders

One of the things that really attracted me to the rot.js framework is the ability to use hex maps. As an old school Avalon Hill board gamer, I had to be dragged kicking and screaming into the modern age of area and point-to-point map systems and, while I’ve made my peace with those topologies, to my inner geek hexes just scream hard core.

Most roguelikes use a square grid map and that has loads of plusses, especially in the ‘ease of programming’ category. Hexes offer a distinct advantage, however, in that the distance between all hexes is constant. The downside is that orthogonal movement in some directions involves zig-zaging. Addtionally, indexing presents its own special problems.

The original Source of the Nile game was hex based and that’s how I want to do it too, challenges be damned. To get this map rendering, here’s what I wanted to do:

1) Read in a map from a file and render to the rot.js console 2) Only show a portion of the map on the display, panning the map as the user move’s the ‘@’.

My first thought was have map data stored in a text file like this

1
2
3
…….###……
……#####…
……#####…

However, to read a text file in javascript it seems you have to do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
path: 'maps',
get: function(name){
    var path = 'js' + "/" + this.path + "/" + name + ".txt?" + ROT.RNG.getUniform();
    return Promise.request(path).then(function(data){
        var map_data =  this._mapFromTemplate(data);
        return map_data;
    }.bind(this)).then(null, function(){debugger;});
},
_mapFromTemplate: function(data){
    console.log(data);
    return data;
}

The problem is I suck and the various asyncronous calls I had to wait on to get the map to the screen were messing with my chi, so I decided to go with a lamer approach:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
map: function(){
    var ret_map = [];
    var map_arr = ['????............................................................................',
        '??..............................................................................',
        '..?.............................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................',
        '................................................................................'
    ];//.join('\n');
    for(var y = 0; y < map_arr.length; y++){
        var line = map_arr[y].split('');
        ret_map.push([])
        for(var x = 0; x < line.length; x++){
            //console.log(x+ ", " + y + ": " + line[x]);
            ret_map[y][x] = line[x];
        }
    }
    return ret_map;
}

Obviously, instead of a map that is empty except a few spaces in the upper left, this will eventually be a map of Africa. To make sure I have some lousy code to refactor later, I created another array and looped over the first array to figure out what sort of tile I’m dealing with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
   var map = [];
    var mapHeight = 80;
    var str_y = 0;
    for(var y = 0; y < 24; y++){
        map.push([]);
        var str_x = 0;
        for(var x = y%2; x < mapHeight; x += 2){
            //map[x].push(Game.Tile.nullTile)
            if(str[str_y][str_x] == "."){
                map[y][x] = Game.Tile.floorTile;
            } else {
                map[y][x] = Game.Tile.wallTile;
            }
            str_x++;
        }
        str_y++
    }
    this._map = new Game.Map(map);

To render to the screen, I simply loop (again!) on the map array

1
2
3
4
5
6
7
    for(var y = topLeftY; y < topLeftY + screenHeight; y++){
        for(var x = y%2; x < topLeftX + screenWidth; x += 2){
            var glyph = this._map.getTile(y, x).getGlyph();
            //console.log(y + ", " + x + ": " + glyph.getChar());
            display.draw(x - topLeftX, y - topLeftY, glyph.getChar(), glyph.getForeground(), glyph.getBackground());
        }
    }

The end result is that I ended up with this

What this screenshot does not show is that the ‘@’ can move around the map and the map pans with the user. Which is all great until you run into one of several, literal, edge cases:

Notice where our hero is? When using the “odd shift” method of indexing, odd lines are shifted to the right by half a cell. So, when I attempted to move due east on an odd row (zero indexed) against an edge, our hero ended up half way in no-mans land instead of having his movement blocked. To avoid those edge cases, I wrote a lot of really crappy code along the lines of (in the case of moving west)

1
2
3
4
5
6
7
   if(this._centerY == 0){
      this.move(-2, 0);
  } else if(this._centerX == 1 && this._centerY%2 == 1){
      this.move(0,0);
  } else {
      this.move(-2, 0);
  }

That’s ugly. So ugly, I’m not going to horrify you by showing what I did for the intercardinal directions.

I’m running this project loosely in 2 week sprints. For the 10.2 sprint (10/15 – 10/31), I wanted to accomplish the following

  • Render the main ui
  • Read a map from a file and display it in the rot.js container
  • Move an avatar around the map, panning the display as it moves

I accomplished these goals with time to spare and a lucky thing, too, as my work/life balance has made fiting in JavaScript vanity projects more challenging. However, I am determined to soldier on and get this game into at least a playable state before I am attracted by the next shiny object to flit before my eyes.

Also, before I forget, a big h/t to Dominic at Coding Cookies, whose excellent rot.js tutorial I have used a starting point for this project.


UI of SotN

First, a couple of notes on my tool stack… I’m developing my Source of the Nile port (SotN) on Mac OSX, using PHPStorm for the web/javascript editing and Trello to keep myself organized. I’m doing what few mockups I’ll need using MyBalsamiq.

Speaking of MyBalsamiq, here is the mockup of the UI that I came up with:

Mockups are a great way to design your apps and MyBaslamiq even lets you make a kind of prototype by adding links to various ‘hotspots’ on your mock, which you can then use to simulate various user events.


From Cocktail Napkin to Complete

As a boy, I loved the “bookcase” games of the once great Avalon Hill game company. Playing games like The Guns of August, Rise and Decline of the Third Reich and Luftwaffe with my cousin are some of my favorite geek memories.

A game I particularly liked was Source of the Nile, a game that put you in the role of a 19th century explorer leading an expedition into the heart of the dark continent. It featured a map of Africa that, aside from costal areas, was unexplored. When your expedtion entered an unexplored hex, its contents, including terrain, natives and flora/fauna, would be procedurally generated via card draws and die rolls. The goal was to make your way across Africa, making as many discoveries as possible and hopefully finding, you guessed it, the source of the Nile.

The concept was cool and the game play was fun and it seemed ripe for a port. I immediately thought of doing it as roguelike. I’d built a few (ok, half built) in the past, mainly using various flavors of libtcod and it seemed like a natural fit for the game. When I stumbled on the rot.js project, I knew I’d found the right framework.

In a way, this is not a natural choice… javascript is my least favorite technology, even more than regular expressions, and I say this as a guy who worked as a MUMPS developer. When I saw the book Secrets of the JavaScript Ninja, I remarked that “The first secret is to not use JavaScript”. But as much as I hate to admit it, javascript has come a long way since I last had to seriously deal with it back in the day. At work, there are ominous conversations about node, backbone and angular and the host of other nightmarish javascript frameworks lurking around out there and it seems that what was barely ready for prime time in 2003 is now a force that I will have to reckon with.

What better way to beard the lion in his den than to write a game with my least favorite language ever. I’ll have a pretty great framework in rot.js to help along the way, so I can concentrate on making a game and not having to re-invent all the wheels it takes to get a game from cocktail napkin to complete.

We’ll see…