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.

Dev Diary - 2nd May 2014

A little slow this week while we debate largely non-technical issues with Apple. Doubling-down on Android is the order of the week.

On a more positive front we had a very successful deploy of a huge improvement to the most important part of our service. It was a multi-app deploy and has so far gone off without a hitch. This is how it should be of course but you can never be 100% until it’s in the wild. As well as Randy’s awesome code we also did quite a bit of manual testing and a detailed code review.


Megan Fox discussed game dev on this week’s Ruby Rouges which was low on Ruby but and interesting insight into an industry so different to the web dev I’m used to.

I literally cried listening to Sara Seager on Story collider. The episode is funny, tragic but also beautifully inspiring - impressive for only 16 minutes.

Dev Diary - 25th April 2014

This week

The app store wait continues while we work on promo sites and continued Android fixes.

Spending time with Android

I’ve spend the week using a Nexus 5 as my carry phone to get a feel for the subtle differences in the platform. It’s been a good learning exercise as I now have a better understanding of Android.

On the whole it’s what I expected: great service integration & some interesting features but way lower quality of hardware and software. I’ve always thought the UI looked messy but it’s actually just a bad user experience in many places.

Third-party apps

I’m a heavy podcast user - I listen to multiple podcasts during the day. My week on Android was made worse but a complete lack of decent podcast clients. Every one of them was awful - confusing, overblown interfaces, even the ‘basic’ features were impossible to use and understand. I tried many - both paid and free - from ‘the best of’ lists and none of them made any sense.


Like many programmers my reaction to the lack of a decent podcast client was to think ‘hey - I could write my own!’. This lead me to the Xamerin Project. I remember Xamerin & Mono from the early 2000s when I was primarily working in .NET.

After working on a PhoneGap-based project it was interesting to see another approach to the problem of cross-device development. So far I’m impressed. The main idea is to write your core code in shared libraries then create platform-specific UI code that hooks up to it. The whole thing is then compiled down and run on a platform-specific runtime shipped with the app.


I was a die-hard, London-school TDDer and boy did I talk about it. My approach has softened a lot recently. I broadly agree with DHH’s issue with being so prescriptive. Many things that we treat as process should actually be tools for getting the job done. Pair programming, TDD, Agile etc are all susceptible to ‘silver-bullet’ syndrome.

It is however, important to remember that skepticism is about applying critical thinking - not just dismissing out of hand. The urge to argue against the doctrine can blind you to the good stuff. For example, you’re missing out if you’ve never used tests as a way to drive design. A lot of the time it just makes the feedback cycle quicker.

Ultimately we’re all just trying to write good code and get good results. I can’t say it better than Zed Shaw: Programming, Motherfucker.


The ongoing debates and issues surrounding sexism in tech have no doubt been on everyone’s minds recent. The Debug podcast had a great discussion with a panel of women in the tech industry.

Dev Diary - 17th April 2014

This week

We’re now in the ‘Waiting for Review’ stage of every iOS release so most of the time has been spent tidying up, spiking new features and bug fixing in prep for our Android release.

Listening to smart people

A few weeks ago I had a debate about our evolving API with my good friend & college Tim. He was pushing for a more ‘hypermedia-style’ while I was more keen on ‘keeping things simple’. I’ve always kept and ear to the ground on hypermedia but it felt too up in the air still.

My mind has been changed after listening to the ”Hypermedia APIs” epsiode of Javacript Jabber where Steve Klabnik goes in depth on the philosophy behind hypermedia and talks about With a specification building around it - and the benefits of convention and a richer data set - I really feel like it’s something we can get behind. I’m really glad we versioned our APIs sensibly!

I’m also resolved to dig deeper before dismissing an idea. A throw away comment from Steve hit it home for me: “I was like, ‘That person’s smart. But they said something that sounds stupid. I should maybe think about why I feel that’s true and maybe go look into what their argument is.’”.


The past few Javascript Jabber episodes have really stood out for me. Raquel Vélez talking about robotics and Javascript was fantastic and really inspiring to get out and play with something other than pure code.

The Incomparable have rebooted their podcast Teevee. At there moment they’re talking about Game of Thrones.