Go Do

A few words on how I built our app Go Do and what I learnt from that.  

Warning also contains some highly subjective ranting.

So a quick bit of background. Go Do is an app that allows you to find events in your local area. You can get it here www.justgo.doThere are only two of us working on Go Do. I did all the development and Carl did the design. All in all it took about 7 months to build and launch on both ios and android. We chopped and change the design quite a bit in that time as well. That also includes the time spent on the backend but here i’m only going to cover the front end.

React Native

Go Do is built using React Native. I choose to use React Native simply because I already knew React and Javascript. I did consider using xamarin for a bit mainly because its C#. I even considered trying it with F# but the end goal here was to build something before I ran out of cash and learning something new would have set me back.

So it turns out React Native is a really good bit of engineering generally speaking it just works and so far I have written no native code at all. I did create the IOS splash screen in Xcode but that is literally all I had to do. The app has only a few lines of platform specific code in it, mostly to do with the android back button. This ability to deliver on both platforms from a single code base is just awesome 

   Tom’s Tips – for a single code base app

  • If you can design your app so it’s the same on both platforms. You can potentially half your workload this way. Yes they have different design principles and guidelines so just stay within both. Plus the “experience” will be near identical which is what you want
  • Design your app so it’s scalable and works on any screen size. This does take some careful thought and you will need to compromise but you have to do this on android anyway so why not get iPad thrown in for free on iOS?

The other good bits about React Native  –

Live/Hot reloading – Not having to recompile all the time means you can constantly be tweaking and testing and believe me you will do a lot of that.

CSS – This is so much better than web development. I just declare my style objects in with my components and they are even type safe! If i need to share them I stick them in a module and import them.

Code push –  Allows you to push out updates over the wire to fix bugs and tweak the app without going back though approval. It has its limits and it’s a bit hard to get set up but it’s worth it.

Community – For a young tech there are a lot of good github projects. I’m using AirB&B’s maps 

Performance – The performance is amazing it feels like any native app. You do however need to understand how to optimise react

and the not so good bits –

Updating – this seems to cause lots of issues every time I do this I have to reinstall all the react native modules im using.

Changing the project name – I started the project with a different name and tried to change it half way though. It was so painful I gave up.

Hot reloading – somehow I broke this and never got it working again. Which is a shame as it’s awesome.

Gesture response – The performance is great but the way this works seem very unreactive and rather complicated. I’ll caveat this that I have no idea how they could do it better.

JavaScript! – Understand that writing javascript is my job but its 2017 we could do better!  When you program you are building your own maze. When you program in JS you don’t even get a match to find your way around.

  Tom’s Tips – for surviving JavaScript

  • Use Typescript or Flow it can be a pain to set up but it will give you semi decent tooling which will save you time in the long run.
  • Use functional programming principles as much as possible. You don’t need to know what a monad is but you should understand the concepts purity and immutability. If you like this makes your maze 2d not 3d.
  • Avoid using “this” wherever you can.



First point you would do well to use stateless functional components wherever possible.  It makes you application easy to reason about. The ideal is you pass you view a single state object and it will render correctly. Keep that in mind and your on the right track.

For state management I don’t use redux. I have in the past but I have a few reasons for not using it on this project

  1. I don’t like making actions and dispatching them when I could just call the reducer function directly
  2. If you don’t use time travel or the redux dev tools you don’t need actions.
  3. It only does half the job. Setting state. Side effects are well.. side lined

Instead I use a modified version of this approach which is a JS implementation of the Elm architecture

It does more but with less boilerplate and I find it simpler. I also use Ramda a lot mainly for for mutating the state. I have used ImmutableJS in the past but i found it hard to debug and overly complex. It’s probably more efficient but in this app that’s never going to be the bottleneck. Ramda is great but it confuses the hell out of TypeScript at times.

In elm each “Action” is a pure function that takes the current app state – mutates it and returns it. However In addition it also can return an optional list of “Effects”. These are side effecty functions that return promises.

The beauty of this is approach is the core of you app is easy to test and reason about. As its only pure function that make up your app you can easily test that when this happens it should set the state to this and make this call to the server.

I started by using ramda a lot and just composing up functions. What I found however if that this mixed data structure of the app state and list of effects was not so easy to work with. The problem is you need to be able to compose pure “Mutators” that just act on the state on one level and “Actions” that also add effects on another. For example a “Load Data” action is both triggered directly from a refresh, or as part of the “Initialize App” Action

So I would end up with concise but hard to read code like this. Here the “Action” takes the app state but returns the state and a list of effects if any. 


const setLoadingStatusToLoading = (appModel:AppModel) => setLoadingStatus(Loading, appModel);
const loadEventResult = (model:AppModel) => makeResponse([loadEvents(model.mapLocation)],model);
export const loadEventsAction = pipe( setLoadingStatusToLoading, loadEventResult);

So instead I switched to a functor based approach. Don’t worry about the terminology the code is easy to read.

const setUserLocationAction = (location:Region):Action => (update) => {
   return update.map(setUserLocation(location))

Granted these don’t do the same job but stay with me and hopefully its enough to get the idea. Now “Actions” must always take and return an “Update” object. This has a few functions on it.

  • Map is just a mutation of the app state which i call model.
  • AddEffect adds an effect to the list by default this is always empty.
  • Chain is used to compose actions together.

I find this easier to read and follow


The Short

So to conclude I found React Native to be surprisingly trouble free. I would definitely recommend it. Yes its has a cost but it beats building the same app twice.  If you had something really technically complex you wanted to achieve then you may want to go native. Still I suspect even then a hybrid approach would save time.

Using a functional approach greatly simplifies things. It makes the code easier to follow and easy to change. Trust me I’ve built enough OOP MVC apps to know this.

And lastly the one size fits all approach to app design is a huge win if you can make it work.


So check out our app… oh and go and do something fun.





  Game created while learning Unity 3D. First person take on a classic.

 Play Online



  Solo project – cross platform game. Now available on Google Play and coming to the Apple app store.


    PixelMix – Solo project. Draw you own tunes with Facebook and Twitter integration.



Gambling portal website and games.  Created the client wrapper and 8 games.  http://lovejackpots.com



  Lead developer in the team building the BTvision video on demand portal on the YouView platform.


I’m going to start with a disclaimer this is not a fully fledged polished game engine more a proof of concept and hopefully something to show the way. If you want more features then please add them 🙂

So I wanted to create a little demo showing what Entity Systems can do for you and why you should care. Now they solve a lot of structural issues but also by there nature are data driven. This means by being a bit clever we can get automated serialisation. A fancy way of saying we can save the game state with out writing any special code. If we are a bit smarter still we can create an Editor that will magically work for any components we add. What’s more this editor works “in game” as you are playing you can tweak and save you levels. Arrow keys to move and E to bring up the editor.

This movie requires Flash Player 9

Obviously there is a lot missing both from the editor and the engine. But hopefully for those who don’t quite know where to start with Entity Systems this will be a nudge in the right direction.

The code for the demo is here on git hub. The code for engine is here and it uses Ember2


Well Its been a while but I’ve been busy in the back ground and finally have something to show for it all. In the shape of Ember 2 first up I need to acknowledge some major contributors. First Alec McEachran @alecmce and his take on things with xember. Second Richard Lord @richard_lord and his clever suggestions in how to get around the performance cost of removing items from a vector.

Although the new versions API is in many ways familiar although simplified it is a complete rebuild underneath with a much more test driven approach. Also while some of the changes are a bit more subtle there are two biggie’s. All in all I made the decision that it deserves the version 2 badge.

So the first big thing is Ember is now a Robotlegs2 extension. To pre-empt the reaction of some that robotlegs has no place in games it does. Its perfect for the UI and menu’s systems etc. the issue is that the MVC doesn’t fit real time game play which is where Ember steps onto the stage. For Ember2 I wanted something that solved the issues of integrating with the Robotlegs framework whilst still being able stand alone. I also wanted a way of being able to add any functionality required without having to bake it in. Lucky Robotlegs2 appeared and its new context where functionality is constructed from extensions rather than being built in was exactly what I wanted. So rather than doing It my self badly it made sense to use it and save me a lot of work.

Second on the list is some clever trickery. With some magic behind the scenes I have been able to ditch the cumbersome linked lists and still keep performance practically the same. The best part is the nodes are now in juicy vectors and they can now be injected directly into the systems. No casting and funny loops any more just inject and “for each” you way over them.

Other more minor changes are that Entities are now objects in them selves. This may sound like a minor thing but it allows for pooling of whole Entities which was previously impossible and can help performance. Also taken for Alec’s xember is the auto inspection of the node classes so there is now minimal typing required when creating your nodes. All these things add up to make Ember 2 simpler and neater so it can just get out of the way and allow you to get on and code. If you want to get started check out the bunnies demo code on github. Have fun.


Administration portal for a payment system. Built a Flex client with the robot legs framework and signals. Also built the corresponding BlazeDS back-end. Features included a skin-able UI for client specific branding. User level permissions and customisable menu settings. Highly customised charts.


Tink very kindly let me talk at the FLPUG last month about entity systems. Its now up online and you can watch it here.


It was a pleasant surprise to meet people that other people are working with these ideas and even using there own versions of Ember. Hopefully I managed put it on the radar of at least a couple more.