Saturday, October 6, 2012

Android + Erlang for Great Good: Cowboy Setup and Account Route

Please read Android + Erlang for Great Good: An Introduction if you haven't already done so.

Now that I've selected my webserver and defined my client its time to get started.  Since I don't know much about Erlang, Java or Android development I decided to start with a problem I'm VERY familiar with, all that standard account & authentication goop that you somehow have to rewrite every time you change languages, platforms etc.

Since my client is on an Android, we already have an authenticated user, we just need to somehow confirm their identity.  Fortunately the big players in the web have finally pretty much centered on the Oauth2 protocol to handle this problem.  What I need to do is pretty simple, get a token of some sort from the validating authority (in this case the players phone) and send that token + the players email address to my server.  My server can then validate the token via a call to a google server and return one of the following:
  • Invalid token: return 401 and note the oauth2 authority.
  • Token expired: return 401 and note the oauth2 authority.
  • Valid token, user does not exist: return 404.
  • Valid token, valid user: return 200 & json payload containing account details.

On the server side it looks like the account handler will need to become a standard REST + json resource, supporting GET, PUT and DELETE operations.  This post will walk through initial server setup and setup the route to /account.

Create a directory for this application and then copy the rebar script from basho into the new directory.  Next we'll want to create an application skeleton using ./rebar create-app appid=my_game.  This creates a very minimal app skeleton for you.

Now lets get cowboy integrated into our application.  For this we'll need to create a rebar.config file and put the following into it:

{deps, [
  {jiffy, ".*", {git, "git://", {branch, "master"}}},
  {cowboy, "0.6.1", {git, "git://", {tag, "0.6.1"}}}
The jiffy dependency will come in handy later on when we need to encode/decode json.

./rebar get-deps will download these dependencies and ./rebar compile will compile them and your application code. We'll want to do this now to be sure we didn't make any mistakes thus far.

Now its time to define our application start point. When you start erlang with the -s file_name syntax erlang looks for a start/0 function within that file and executes it. We'll use the my_game_app.erl for this as well as the standard supervisor start/2, stop/1 functionality. Within start we'll need to start cowboy and my_game. The complete function is:
start() ->
  reloader:start(), %Makes debugging simple...
  ok = application:start(cowboy),
  ok = ssl:start(),
  ok = inets:start(),  
  ok = application:start(my_game).
inets and ssl are required when actually validating the auth token with google so we'll need to start both of them when our application is started as well.

Reloader is a very useful code snippet from the guys at Basho that allows for hot code upgrades within your running server.  This is particularly useful for debugging.  Simply add the erl file located here to your /src directory and going forward almost all code changes will be reloaded automatically whenever you ./rebar compile the app.  As far as I can tell, only changes to start/0 are not automatically reloaded as that particular method does not utilize the standard erlang supervisor pattern.

By default cowboy does nothing, so next we have to tell it about our end point.  This will simply be /account/  To set this up we need to edit the start/2 method. Putting it inside the start/2 method will allow us to upgrade the routes within the running server later on if needed. One more item to note is that cowboy uses binary strings so make sure you place << >> around your strings or the patterns will not match properly. The complete start/2 method looks like this:
start(_StartType, _StartArgs) ->
 Dispatch = [
  {'_', [
   {[<<"account">>, email], account_handler, []}
 {ok, _} = cowboy:start_listener(http, 100,
   cowboy_tcp_transport, [{port, 8080}],
   cowboy_http_protocol, [{dispatch, Dispatch}]

Finally lets setup our script to automate starting the server.  You can't actually run the server yet as the account_handler referenced by the dispatch does not yet exist, but you can start it up and get your first taste of error messages from the cowboy server.

Our is extremely simple and contains only the following line:
erl -pa ebin deps/*/ebin -boot start_sasl -s my_game_app

 Stay tuned for the actual account_handler implementation.

Android + Erlang for Great Good: An Introduction

I've recently begun working on a multiplayer Android game that will communicate with an erlang server.   The erlang server will contain at least 2 endpoints, a REST account manger and a Websocket which will push erlang server events from the server engine and receive all player commands.

My experience in both erlang and android development is extremely limited, essentially I've read (some of) the manual and written a few lines of demo/tutorial code in each.

I began by looking for a proper web server for erlang.  I reviewed the following:

  1. Webmachine.  Great implementation of a RESTful server, layered on mochiweb.  Their RESTful diagram is a great resource for people wanting to understand REST better.  No built in support for Websockets as of yet.
  2. ChicagoBoss.  Very new, looks extremely interesting.  An MVC framework for erlang, it utilizes Django style templates which are actually compiled into erlang bytecode for speed.  Recommend reviewing it if you want to write a standard MVC application or a RESTful webserver for a client side MVC framework.  Supports Websockets via Cowboy. 
  3. Cowboy.  A brand new http server in erlang.  Cowboy is technically more of a tcp/ip connector pool/manager with out of the box support for http, https, REST, and Websockets. 
After doing a POC of a websocket implementation in ChicagoBoss I realized that most of what I needed was in Cowboy and ChicagoBoss, while cool, didn't really add all that much to the equation. It's a great framework for an MVC application, but doesn't really fit my use cases.

One item I lost when I removed ChicagoBoss was the transparent encoding/decoding of json that make RESTful interfaces in ChicagoBoss so simple.  After a bit more searching I found jiffy which appeared to suit my needs.  It transforms json objects into erlang proplists.  Additionally its written in C and utilizes binary strings for improved performance.

On the Android side I looked into using phonegap or appcellerator or just an HTML 5 webapp, and I decided that I wanted to actually learn to code on the Android platform.  So the client will be Java targeting Froyo (API 8).

Before continuing you'll want to get Erlang installed and working on your system.  For Ubuntu I recommend this gist.  You'll also want to familiarize yourself with rebar, the build system for erlang.

Erlang server source code at brocksamson/my_game

Newer posts:

Sunday, January 30, 2011

IoC / Dependency Injection


The basic idea behind Inversion of Control in context is dependency injection; you want to remove dependencies from your application and that dictates need of a tool to plug in these dependencies.
Other terms you might have heard floating around in this context is Contructor, Setter and Interface Injection; which is way of programming where and how dependecies are injected.
In example below; your car listing service depends on car repository whcih connects to db and gets you data.

public class CarLister
      ICarRepository _repository;
      public CarLister(ICarRepository repository){
            _repository = repository;

There are numerous dependency injection frameworks available; I have used structure map and find is sufficient for needs of application. Idea is to scan assemblies and generate plug in graph for all objects; this allows structure map to contruct objects on demand.

Below is how to configure structure map; configuration below would allow you to scan all assemblies and register all declared registries.

 public class Bootstrapper
        public static void Bootstrap()
            //Initialize StructureMap
            ObjectFactory.Initialize(r =>
                r.Scan(assembly =>
                    if (assembly == null)
                    assembly.AddAllTypesOf(typeof (IStartupTask));                                                            


       /// <summary>
       /// Helper method to determine the project's assemblies to scan
       /// </summary>
       internal static void ScanProjectAssemblies(IAssemblyScanner assembly)

You can declare registries as per your need:

public class DomianRegistry: Registry
                  public DomianRegistry()

C# - Elegant Sorting and Paging Solution

Paging is so simple that it doesn't warrants a discussion anymore:


Sorting is still tricky; I have a simple utility for it. Utility would allow to sort any object collection on any property defined in type safe way.


1. Sorting:
var orderedResults = SorterUtility.Sort(viewModel, sortColumn, sortDirection);

2. Generating sort column delegate type safely:
sortColumn = SorterUtility.GetPropertyName<ViewModel>(x => x.Description)

Utility Code:

public class SorterUtility
        public static IEnumerable<T> Sort<T>(IEnumerable<T> list, string sortColumn, SortDirection direction)
            return direction == SortDirection.Ascending
                       ? list.ToList().OrderBy(CreateSortField<T>(sortColumn))
                       : list.ToList().OrderByDescending(CreateSortField<T>(sortColumn));

        public static string GetPropertyName<T>(Expression<Func<T, object>> expression)
            MemberExpression memberExpression = null;
            if (expression.Body.NodeType == ExpressionType.Convert)
                var convert = expression.Body as UnaryExpression;
                if (convert != null)
                    memberExpression = convert.Operand as MemberExpression;
            return memberExpression == null
                       ? ExpressionHelper.GetExpressionText(expression)
                       : memberExpression.Member.Name;

private static Func<T, object> CreateSortField<T>(string fieldName)
            //returns m => m.FieldName where M is the type & FieldName is a property name
            var classType = typeof (T);
            var param = Expression.Parameter(classType, "m");
            var memberInfo = classType.GetProperty(fieldName);
            var expr = Expression.MakeMemberAccess(param, memberInfo);
            var convert = Expression.Convert(expr, typeof (object));
            return Expression.Lambda<Func<T, object>>(convert, param).Compile();

Choosing your DB

A free one!

To begin developing an application its not important to pick the db; whats important is to make sure it doesn't matter. If you are working in well financed organization you would be able to buy good DBMS; DBMS concern should be to facilitate storing, backing up, recovering, secure access and such. These concerns are important; however does not matter as far as application development is concerned.

To build in anti corruption layer and decouple DB we require two things;

1. Bid "Goodbye!" to SQL programming; no more stored procedure for you.
2. Pick an ORM which publishes APIs capable of interacting with db the way your application need.
3. Any good ORM would let you switch our DB type; make sure yours does.

MVC for User Interface layer

Benefits : The biggest benefit has to be decoupling of presentation; MVC allows presentation (UX or UI) to work in isolation and establishes boundaries. Specialized developers can work on UI without having to worrying about how domain entities are structured and vice-versa.

There are of course lot of other benefits which come with ownership of UI artifacts by UI developers.

a. Device dependent presentation layer stays out of your code base.
b. Accelerates development and changes to presentation layer.
c. Facilitates automation testing of everything beneath presentation. UI based automated tests are harder to write and expensive to maintain; MVC would allow to write tests on view models, controllers and domain layer; giving you bigger bang of your buck.
d. Accelerates development of business logic by freeing developers from UI concerns.

Typical Microsoft MVC set up doesn't take much; just start by creating a MVC application in Visual studio.

1. Set up views - Html, javascript/jquery and style sheet. Utilizes view model to interact with domain. Views setup requires at least four folders in web application folder; set up Views, View models, styles and scripts folders.

View models concerns - Typical view model exposes properties required by view; houses logic for conversion of domain entities to view model. Look up auto mappers.

2. Set up Controllers - Controller should have there own folder. Controllers and view models do not need live in web application assembly; I would leave there unless there is compelling reason not to. This is where MVC ends.

Controller concerns - Interact with domain; pass on data back and forth between domain and view. Code layout of controller is typical facade pattern if anything. Controller commands domain to process view interactions and view model to process domain entities to formulate a view.

NOTE: I find its important to come up with clean folder organization; I have seen following same structure with in each artifact folder works very well.

Setting up enterprise level web application

A modern web application today can benefit from decoupling; setting up each layer as self contained and treating dependencies as such seems to be the key. Many of us have seen technology come and go with our years in development. Open source revolution is picking momentum; products are being published faster and competition is struggling to keep up. APIs are deprecated and new releases are being published with in months not years. You need to be free to take advantage of all the advancements without paying a big price for changing your mind.

My experience is strictly in Microsoft and open source products which work with Microsoft. I will like to talk about the technical stack and how to build infrastructure pieces with anti-corruption layers and start developing application fast!

MVC for User Interface layer

DDD for Domain layer

ORM for data access layer

IoC / Dependency Injection

Automated Testing

Automated Build and publishing Setup

Choosing your db