Dev Diary - 1st March 2015

Understanding Games

I don’t play many games but Alto’s Adventure sparked my curiosity in games programming again.

Games programming is quite a bit different from the programming I do day to day. I started taking a look at the amazing tutorials on Unity’s website but I’d really like to get a grounding in the core concepts of what makes a game engine.

In order to work through this, I started writing a basic games engine in Javascript. It handles rendering of basic game entities (i.e. boxes), very basic collision detection & poorly implemented physics.

I’ve put it on github: Platformer.

Podcast App

Seeing the designs come together has been really exciting. Most of the basic feed syncing, episode display/details/play views and I’m now refining that core functionality. Handling all the different states that episodes and related assets can be in has been challenging. Spending some time getting good test coverage has helped though. I’ve made some fairly large refactors of various parts of the code base without much breakage.

I’m starting to see areas that could be turned into libraries although I’m not really sure on the best way to do this in the Java/Android world. Maven Central seems to be the Rubygems/npm equivilent but it all seems to be way more complicated. I’ll be doing some research on this in the near future.

In particular, I’ll be looking to outsource the podcast feed parsing library. I consider it to have a reasonably easy-to-use API which might benefit others but I’m also keen to get input from a community for handling feed formats. Feed formatting is a constant pain as many differ and are often just plain wrong.

Hirgana Practice

This app came out of nowhere on a Sunday morning when I was considering the Hiragan practice app I’d been using. Many apps use the ‘flash card’ style, showing you a character and asking you to choose from a list of Roman sounds - for example, for “ち” you would tap “chi”. This is problematic because it encourages you to “map” sounds to known English equivilents instead of internalising the sound itself.

In classic programmer style, instead of just practicing, I wrote an app that plays the sound and you then write the character on screen. You then tap when you’re done and compare your character to the actual one.

I lifted most of the drawing code from here and translated to Swift. I’m going to have a go at improving this using actual Bezier paths instead - I’ve been reading this to understand more.

With a basic design in place I may release it in the coming weeks.

Dev Diary - 22nd August 2014

Work on the Reallyenglish mobile app is going well as the team prepares for the upcoming official release on Android. After working through bugs on the platform I’m actually really preferring a lot of the toolset that comes with Android over iOS.

Aside from the day job, things have been rather Go-focused.

Podcast app: Adding subscriptions

I’m keeping the subscriptions/directory side of things on the server at the moment. Initially I wrote the directory search API in node but on Ali’s suggestion I tried out Go. Turns out, I really like it.

Go is super powerful while taking care of some of the more house-keepy parts of something like C. A more concurrent style of programming is actively encouraged in the language through nice abstractions. You can let Go deal with stuff like load balancing between CPUs but it doesn’t feel like you’re being protected from reality.

I also built a basic version of the podcast search UI for the Android app. Starting to get a feel for how activities and fragments fit together. When I hooked up the UI to the directory service I was pleasantly surprised that Android threw an exception when I tried accessing the network on the main thread on my first pass. Quite a change for the platform.

Crypto Challenges

I had a really good time Wednesday when I attended Ali’s workshop/coplay working through the matasano crypto challenges. A few of us hooked up in a chat room and chatted as we worked through the challenges, sharing ideas as we went. We all chose to use Go which proved really good for the task.

Ali also doubled the earnings from the ticket price and donated the lot to Eaves - what a great guy!

From Subtle Sexist to Aspiring Feminist

I always just assumed I was a feminist. All of my friends as a kid were girls. I’ve always had a very equal relationship with my wife and never thought that there were specific roles that women should be limited to.

However, I recently started to learn about the more nuanced elements of sexism & feminism. Looking back on my opinions I’m kinda appalled.

Women in the Workplace

For a number of years in my 20s I ran a small web development agency. We never got big enough to really hire outside of a couple of freelancers but it was just a given that we wouldn’t hire women.

It wasn’t because we thought that women don’t make good engineers - they were just too… complicated.

I kid you not - the two biggest concerns in my mind were:

  • Pregnancy
  • Workplace relationships


In my early 20s I remember thinking about how men & women were fundamentally designed differently: women are clearly better suited to homemaking/babies and men make the money. Just look at cavemen - just logical right? I so vividly remember the thought process and how it made perfect sense.

So why am I saying all this. Kinda wondering that myself reading it back.

Facing the Truth

It’s like this: I think of myself a reasonable person. I would never in my life post the kinda of bile and hate I see some posting in forums and comment sections. But to say that I haven’t actively contributed to the problems women face would be denial.

Even earlier this year I was pretty much in the ‘not all men’ & ‘this isn’t equality’ camp but something made me stop and listen for a while. I talked to my wife, I followed a load of women on twitter and started reading.

I came to understand why this isn’t a simple matter of making things ‘equal’ on the surface. It was like a punch to the gut when I read this article:

“Get in the habit of treating your maleness as an unearned privilege”

But then I thought about it for 5 minutes. Men and women are born equal but men are instantly given an advantage in society. Girls are weaker. Girls cannot handle certain subjects. Girls should dress/act a certain way. Women should take more care when going out with friends. Women should expect sexual advances from men. And on and on.

“Equality” and Debt

Absolute equality would be totally awesome but it’s an unreasonable expectation. The opinions of society don’t change overnight and the cultural memory that women have is not broken by just saying “hey we’re all equal now!”.

Imagine we’re playing a game where we all stack playing cards in a tower to see who builds one with 6 rows first. The only thing is that the cards are on top of a mountain you have to climb up first. As men, we’re already at the top saying “HEY - WE’RE ALL EQUAL NOW - YOU CAN TOTALLY PLAY THE GAME WITH US NOW - 1,2,3 GO!”.

Weird analogy? Maybe.

Basically, we have a debt to pay. It’s really the only way to address balance in any diversity issue but so few people understand this. The term ‘privilege’ is despised by many but understanding it is key to making a real difference.

Men can actually help here but we’re going to have to accept the hard stuff along the way.

Before you get angry, before you feel hard done by or offended - just stop. No one is taking your job away or threatening your life. Just suck it up and try to understand what’s really going on here. Then see how you can help.

We’re going to hear things that challenge us and we’re not going to get it right every time but worthwhile change is often the hardest. I’m personally so underqualified to be talking about any of this but I wanted to say something.

To hear from people who actually know what they’re talking about, start here: 35 Practical steps men can take to support Feminism.

Dev Diary - 11th July 2014

Javascript Debugging Joy

I’m way late to the party on this - I just discovered the debugger command: debugger - JavaScript | MDN

You get an analysis of the current callstack and can interact with the app within the scope debugger was called.

After spending quite a bit of time in Android studio where this is a common part of debugging workflow, this is a very welcome addition to my toolset.


Speaking of Android, I’ve been working my way through the Big Nerd Ranch’s Android book in preparation for starting development of a side project I’m kicking off in the next few weeks.

Despite the positive parts of Xamerin, I’ve chosen to go native. I’m keen to learn Java and the native Android platform so it’s a much better choice for me right now.

So far I’m really enjoying Java. As Sean Cassidy points out Java might not be as bad as many would have you think.

Old Code

I was amused and slight embarrassed to come across some old open source code of mine from 2002: PHP MySQL Search Class.

My lack of competence with SQL shines through as I pull down the entire table of data and do the filtering in PHP.


Philip Roberts’s talk on the Javascript runtime is required viewing for anyone working with Javascript.

The Right Lines

I just pushed some code that fixed some fairly major issues I discussed in Friday’s Dev Diary. This amounted to about 4 hours work but it summed up to around 5 lines changed in production code.

It would have been easy to jump in and start panic hacking. However, most of that 4 hours was spent manual testing, proving/debunking assumptions, reading documentation, experimenting etc.

I’m reminded that so much of programming, like any other craft, is about knowing the right lines to write - not how many.

Dev Diary - 27th June 2014

App Store Approval

We finally got App store approval! We had low expectations about Apple’s turnaround but our resubmission was approved within a few hours. After the various rejections, subsequent unplanned development and uncertainty, this has been a huge relief for the team. Of course we’re a few days from actual users getting their hands on it - then the real fun starts…

More Testing

As I’ve discussed before our team is very committed to testing. This week however I’ve realised just how easy it is to miss regressions when your app is in flux. In particular two things stood out that we’re going to address immediately:

We missed some fairly likely scenarios in our integration specs
Testing use cases that involve offline > online transistions can be tough and we missed a particular case that had been tested to death manually when we first implemented. However, a point upgrade of one library introduced a regression that broke this use case. Our automated specs missed it.

Thankfully, Appium 1.0 made testing cases like this a whole lot easier so we can fix it but this shows that even with a motivated team, it’s easy to miss things if the friction to testing is high.

More broadly, we’ve noticed that our integration specs cover a lot of micro use cases instead of more closely simulating a user interacting with the app. Our plan is to simplify with full stack pathways through the app instead of individually specing each item of functionality seperately.

Our internal staff testers didn’t really test until we got approval
One of the company’s marketing people found the regression while testing after we announced App store approval. This was great but I was disappointed that we hadn’t had more people testing against the beta builds that have been pushed out for the past few months. This week has been great for digging out bugs but many could have been spotted and dealt with weeks ago rather than just before launch.

In an ideal world we’d be able to push out to a team of dedicated testers which may be a direction we’ll go in. We’ll probably also chat to the staff and see if there’s any way we can make things easier for them to pick up during development.

Charles Proxy

One bug that I found occurred when the device lost connection during a download of data. The app should cope with this but I found myself in a constant loading state while testing the app on a train. I used Charles proxy to try different scenarios after reading this post. I’d like to try building automated specs (given our experience above) but in the meantime this has been invaluable for throwing different situations at the app to try and break it.

Dev Diary - 6th June 2014

In-app Purchase

Turns out that we need to implement some form of in-app purchase on our app in order to get into the app store. It can be frustrating with Apple because, despite giving us this guidance, they cannot give us a clear ‘yes’ or ‘no’ in principal until we submit. Because of this we focused on a minimal implementation and have almost completed the work with a week left in our current sprint.

We used the iOS In-App Purchase plugin for Cordova/PhoneGap which works with both old and new receipt styles. Because we’re targeting iOS 7, we don’t need to have any server side components. Overall I’ve enjoyed digging into the IAP side of iOS dev - in particular the “Using Store Kit for In-App Purchases” video from WWDC 2013 really solidified my understanding.

I18n with gettext

Internationalization is a big deal for us as we largely target Japanese & Chinese users. We’ve had a few ways approaching this in the past and all have become difficult to work with.

Tim did some research and suggested we try out the old standard gettext. The benefit here is that the toolchain is highly advanced but the actual usage is very straight forward. It also uses standards that our translators are familiar with. I’m also impressed how simple the integration with code is. Having base keys of actual text means that code makes more sense to read:

var heading = I18n.gettext('Welcome to my site');

I wrapped up the jsxgettext npm module in a singleton that we could require through out the code where needed. Handlebars integration was very simple:

Handlebars.registerHelper('tr', function(text) {
  var translation = I18n.gettext(text);

   return translation;
}, this);

We can then extract translations into .pot files and use gettext’s msgmerge to handle merging & building of locale .po files.


Our apps automated UI specs have been pretty flaky for a while. Many times a day we’d get failures from Travis because the simulator was just hanging or didn’t even boot. Thankfully Appium 1.0 dropped a few of weeks ago and the improvements looked promising. Randy set out getting our cucumber steps inline with the new API and so far everything has been running very smoothly.


Like many, many developers I was super excited after the Apple keynote on Monday. As well as taking a look at the new APIs I’ve been working through the Swift language guide. Just getting familiar with the syntax and approach for now but I’m looking forward to writing some actual code in it soon. It’s great to see Apple moving on something like this and exciting to see another platform going in a functional programming direction.


I’ve read Ilya Grigorik’s Minimum Viable Block Chain post multiple times this week - really interesting tech explained clearly. It’s made me think about ways to apply the concepts behind crypto currencies to other areas that have similar problem sets. Establishing validity and history is not limited to financial transactions.


I loved Radiolabs episode “Things”. As always, interesting stories with lots to think about afterwards. I used to be very attached to “things” in the past and while I’ve improved, this episode really made me think about how more I could let go of.

Dev Diary - 16th May 2014


This week was mostly about analytics. I worked on updating and adding UserId features to Dan Wilson’s Cordova Google Analytics plugin.

Overall I’m pleased with the result but the workflow of Cordova plugins is not straight forward, especially as there is no standard way to build a test suite. This meant manual testing all the way, reloading plugins in my actual app for each platform in order to test.

I’d like to hear about testing Cordova plugins - even at a unit level as it would make the process much slicker. I’ve had a few ideas so I may investigate myself at some point.

Language Overload

I’ve enjoyed the variation in programming languages I’ve had this week. Combining work on our app, the plugin work and personal study I’ve written a fair amount of C, C#, Objective-C, Java, Javascript & Ruby.

Back to Rails

I’ve been away from regular Rails dev for quite a while so it was nice to get back by doing some upgrade work on a CMS app that I host for our local NCT. It was fairly painless to upgrade the app from 3.0.1 to 4.1 and along the way I got a good feel for the recent changes.


The Ruby Rouges had Julia Grace on to talk about hardware hacking.

Directional did a 2 hour long commentary of the Nintendo DS keynote from 10 years ago.

Notes From #isTDDDead?

I worried that I was going to find the discussion between DHH, Kent Beck and Martin Fowler annoying but I actually really enjoyed it. Well worth watching.

Kent & Martin’s responses seemed quite surprising to DHH who appears to have had a very dogmatic experience of TDD. The daily use of the guys that were influential in the popularisation of the techniques were more pragmatic than many people will have imagined.

I look forward to the next discussion where I think we’ll get into the meat of TDD.

I wrote a number of headline points for your enjoyment!

Kent Beck

  • If an idea is bad, find a cheap way to try it
  • Programmers have a right to feel confident about their code
  • TDD is one way to achieve confidence
  • Mixing techniques - some TDD, some not is totally fine - it’s powerful tool
  • TDD is often about trade offs
  • Don’t twist design to make it testable
  • Generally doesn’t mock anything
    • Mocking can couple you to implementation which too high a price
    • Repeatable feedback loop is far more important


  • Dogma in TDD circles is big problem (i.e. you must TDD 100% to be a ‘professional’)
  • Mocking forces unnatural structure, supporting tests instead of code
  • “Easy to test == better design” is a fallacy
  • Understandability is often compromised

Martin Fowler

  • TDD does not imply isolation or mocking
  • Self-testing code is one of the most important things to deliver - TDD is one approach and it has other benefits

Dev Diary - 9th May 2014

Android woes

Mostly fighting off Android issues with our audio player component. Cordova’s Media plugin is a little difficult to work with as it’s very much written to work with older iOS APIs. This seems to have influenced how the other platform integrations work.

There are very limited event callbacks as the audio plays so I have to keep track of playing using a timer:

this.timer = setInterval(_.bind(this.updatePlayerStatus, this), 1000);

I can’t rely on the timer for position data so I get it using getCurrentPosition:

updatePlayerStatus: function() {
  this.player.getCurrentPosition(_.bind(function(position) {
    // update UI

Trouble is this sometimes leads to the UI being out of sync with the audio.

I’m also not happy with my UI implementation as it uses a native web form slider. This was a quick implementation but it needs workarounds to get a ‘played’ track - which can be a little flaky.

Android joys

On a more positive note, I’ve found the joy of remote debugging on Android. I’m used to this on iOS of course but the Android tools are even better. Safari’s remote inspector constantly disappears and you don’t get any console logging that occurs prior to opening the inspector. Very impressed with Android here.


I’ve mentioned Debug before; they have great interviews with developers about their history & work. This week they interviewed Scotty of NSConference and iDeveloper fame.