Integrate Testflight, Flurry and Corona SDK


I use Testflight to coordinate pre-releases of software I develop for the iOS platform. Testflight is an amazing tool and I’m surprised Apple hasn’t bought the company yet. You simply create a group of people, send out invites and have them register their devices with Testflight. Unfortunately, the provisioning profile in the iOS ecosystem is a huge clusterf*ck, so you have to manually and not to mention painfully add these identifiers to your provisioning profile in the Apple Developer Portal.

When the profile is updated with the correct devices, you upload the .IPA to Testflight and add some release notes and hit send. The people participating in your beta release will then get an email that they can download a new version.

Testflight and Corona SDK

At work, we use the Corona SDK to develop multi platform games. Corona Labs describes their product as follows:

Corona SDK is the leading mobile development framework. Build high-quality apps and games for iOS, Android, Kindle Fire and Nook in record time.

It works remarkably well, not too much problems and it’s easy to deploy. Anyway, to integrate Corona SDK and Testflight you need to do a couple of things:

  • Build your software and generate the application and it’s zip file
  • Create a new folder called ‘Payload’ and move the application file into it
  • Compress that file and change its extension to .ipa instead of .zip
  • Upload the IPA to Testflight


Screen Shot 2013-02-10 at 13.48.39
Flurry’s error log

Flurry is a great tool for gathering statistics, I’ve used it in all applications I’ve created for iOS and made sure its been used on Android as well. One of the best features for me as a developer is the fact that I get access to the crash reports (see the picture below).

To use Flurry with Corona, you use their analytics library.

-- Import library and initialize with personal application key 
require "analytics"
analytics.init( "YOUR_APP_KEY" )
-- Log event ID
analytics.logEvent( "Event ID" )

One thing I sometimes wish I would’ve implemented earlier in the project, is a log inside the app. The log should save the current state and the roadmap with the relevant server/client calls that took them there. It should also include the option to send this log to the developer.

2013-02-10 13.45.02
Evernote’s log

Evernote has implemented this very neat and it could be of tremendous help when debugging the communication between the server and the clients.

Game of Life implementation in Erlang


The universe of the Game of Life is a two-dimensional grid of square cells, each of which is in one of two possible states, dead or alive. Each cell interacts with its eight neighbors, those cells that are horizontally, vertically, or diagonally adjacent. At each unit of time the following transitions occur:

  • Any living cell with fewer than two living neighbors dies, as if by under-population.
  • Any living cell with two or three living neighbors lives on to the next generation.
  • Any living cell with more than three living neighbors dies, as if by overcrowding.
  • Any dead cell with exactly three living neighbors becomes alive, as if by reproduction.

For an assignment at school, my classmate Jonatan and I were to implement this in Erlang.


This video demonstrates the finished game and two examples called a pulsar and a glider.

Source code

First off, here is the main program. If you would like some more information before seeing the code keep scrolling.

Data representation

The input to our program is represented as a list of {X,Y} tuples containing coordinates. Our internal data is represented as a single list using the indices of the list as a one-dimensional representation of the grid. This was chosen over representing the game and its input as multi-dimensional arrays for simplicity.

Note: the worst random access time of a list compared to an array is negligible as random access is only required once during the setup.

Each cell contains information about its coordinate, current state (dead or alive), list of its neighbors, and information about them such as number of living neighbors.


To keep our game in sync and avoid race conditions we use a “master” process to notify all cells when a new unit of time (tic) begins. Each cell responds by sending its current state to all of its neighbors then waits for its neighbors to send their current state. When all current states have been collected the new cell state is updated and drawn. This avoids synchronization issues by making sure all processes start at roughly the same time.

Source code for supporting files is available in this Gist.

To run the program:


Open a browser and go to the URL http://localhost:8088/

Known bugs

The update rate for the browser is not in sync with the actual game update. This causes some irregular behaviour in the visualization of the game.


I would like to try to make a version of Game of Life in Node.js and see what advantages Node.js brings to the table in a GoL-implementation.

Running PHP applications on Heroku

These last weeks I’ve been working on trying to organize my domain names and web hosting accounts. I’m running this blog and several other websites on a VPS as a WordPress multisite. The other applications that I am running are small PHP applications. I’ve been looking into running the other applications on Heroku. By moving these away from my current web hosting account I can cancel that account and use it for domain names and their DNS control panel.

If you would like to try running PHP applications on Heroku I suggest you create an account and create a new app at the Cedar stack (for PHP support). Then sign up for an account at Amazon S3. I use Amazon S3 for their cloud storage and keep my transfers and data (less than 5 GB) beneath their free tier to keep my costs minimal. To stay at Herokus free tier you can’t store more than 5 MB for the MySQL database and not more than 10 000 rows on the Postgres database. The PHP applications I’m running at Heroku is using MySQL as a database backend and databases at Heroku can get costly fast, especially when using several dynos.

If you’re not running your PHP application in the webroot, take a look at for instructions on how to change the webroot at Heroku.


  • Easy to deploy, my old hosting service didn’t support SSH access or any other way to do a proper deployment.
  • Cheap (maybe even free…?) for small applications.
  • Minimal maintenance since I don’t have to administer a VPS.


  • If you start adding dynos, it gets really expensive.
  • Your Ruby on Rails applications on the free account winds down after idling for a while and has a startup time that feels like forever. That doesn’t happen for the paid accounts. This doesn’t apply on PHP applications though.

After doing this test run, I will definitely look into running this WordPress Multisite at Heroku instead of having my own VPS.

Inspect SQL queries generated by Ruby on Rails

I’m currently working on a rewrite of XCStorm, my website dedicated to crawling the web for news about cross country skiing.

Preview of the new filter system at XCStorm

I’m using Heroku for hosting and for development I’m running SQLite and for staging/production its Postgres (I know its bad practice to mix…). Anyway, I found myself in a situation where I needed to compare SQL queries generated by the ORM.

Create a file named .irbrc and put this into it:

ActiveRecord::Base.logger =

Afterwards, start your Rails console and enter your query.

The reason I’m mixing database adapters is because at this point it doesn’t matter since the data won’t be complex and its easier for my partner to setup and interact with the database.

Realtidssystem med OSEK och Lego Mindstorms NXT


Ännu en gång har vi fått leka med Lego på skoltid, första gången var i en tidigare kurs i Distribuerade System för cirka ett och ett halvt år sedan. Senast så utförde vi projektet med hjälp av Lejos NXT och Java, den här gången använde vi nxtOSEK och programmeringsspråket C.

Vår uppgift var att genomföra lite småuppgifter med en robot som vi konstruerade och avsluta med att göra en robot som följer ett streck på marken. I och med att det är en kurs i realtidssystem så måste det finnas något moment av realtid i det hela, så samtidigt som den ska följa ett streck ska den hela tiden avläsa avståndet till en robot som kommer köra framför och hålla 20cm avstånd.

OSEK är en implementation av ett RTOS (real time operating system) som är skapat av ett samarbete av tyska biltillverkare. NXT-implementationen hjälper sedan till med kopplingen mot hårdvaran, dvs sensorer och motorer.

Programmen skrivs i C och har en tillhörande .OIL-fil som innehåller en beskrivning av systemet med alla events, timers osv. Du använder sedan en rad verktyg för att kompilera ihop dessa och få in den på din Lego Mindstorms NXT.

Vår uppgift

Den ska som sagt följa ett streck och samtidigt hålla ett konstant avstånd till roboten framför. Uppgiften var hyfsat enkel att genomföra när vi fått klart för oss hur nxtOSEK fungerade, kommit ihåg hur API:erna till roboten fungerade och vilka saker man ska tänka på.

För att nämna några av utmaningarna vi har haft:

  • Hur definieras mörker?
  • Hur hanterar man en bana som har kurvor? (Skarpa och/eller långa?)


Vår algoritm för att hålla oss på banan är mycket enkel och bygger på att vi har en fast arm som vår sensor sitter fast på.

  1. Vi har ett task (LightTask) som läser av ljuset mot backen
  2. Har ljuset ändrats sedan sist? Isf, läs av och kolla om den är högre eller lägre
  3. Är det ljust så ändra så ena hjulet (hjul 1) går exempelvis 50 och det andra hjulet (hjul 2) går 20
  4. Är det mörkt så ändra så hjul 1 går i 20 och hjul 2 går i 50.
  5. Börja om

Vi har gjort lite justeringar på detta så att den kör med en faktor när den räknar ut hur fort den ska köra. Detta för att den ska ha möjlighet att “smyga” framåt om det är ganska nära.



Finns på GitHub