15 October 2012, by Hugh Greenish
I recently found myself dealing with a problem that had been identified in load testing on one of our customer’s sites. Specifically, when the site was being hit with requests for mobile pages while also handling a background noise on the desktop versions, one of those desktop pages would, every so often, throw a 500 error. The mobile pages in isolation worked fine, and the desktop pages in isolation worked fine.
This kind of bug is one of those ones that I feel is allowed to happen during dev, so I didn’t feel too bad about it. In order to actually diagnose and fix the issue, however, I was clearly going to need to generate some load of my own so I could work out the problem rather than merely the symptoms.
27 August 2012, by Hugh Greenish
This probably feeds into Rowan’s recent series of blog posts, but rather than looking into the mechanics of writing unit tests, I’m going to discuss a little about the logistics of applying them, and how you can ensure that your tests are actually useful.
From my early days as a cynic, I’ve come full circle and am now a great fan of unit tests. Sometimes I even prefer writing them instead of “real” code. At times I have a tendency to write somewhat esoteric code, and a comprehensive unit test suite is one way to ensure that the customer has as much confidence in the code as I do – and the best way to make sure that you have a comprehensive unit test suite is to measure code coverage. That, however, is not without some pitfalls…
22 January 2012, by Hugh Greenish
Last time, we enhanced our Hello World application so that it could interpret our feedback and take some appropriate action. I closed off by declaring it to be “very bad indeed“. This time, we’re going to find out why…
7 January 2012, by Hugh Greenish
In my first post, I wrote a very simple “hello world” application, that displayed an alert box like this:
It’s lovely as far as it goes, but you were to install that application on your phone, you would no doubt become rapidly disillusioned with it – it may ask how you are, but ideally we’d want something to happen once we press a button. At the moment, all that would happen is that the popup would disappear, and you’d be looking at a white space. Admittedly, this is pretty much how some of the early torch applications worked, but I think we can all agree that we’re not (yet) putting Objective-C to its best use.
18 December 2011, by Hugh Greenish
In part 1 I gave a little introduction to Objective C – why people would want to develop for it, and a quick hello world example. This post will go into more detail about the syntax, with the help of a few household pets.
1 November 2011, by Hugh Greenish
This is the first in a series of posts that will – I hope – give a bit of insight into Objective C: what it’s like to develop in, how to write an app, and a few pitfalls to watch out for. This first one aims to give a basic overview of Objective C, and why we might want to use it in the first place.
Why develop in Objective C?
Objective C is the core language for developing applications for iOS and OSX – if you want to install something on any Apple products, then you’re going to need to write it in Objective C. Long gone are the days when that “if” would be met with snorts of derision: Apple’s growth in the home computer market is massively outpacing the rest of the industry, and – with all due respect to Android – they hold the lion’s share of the mobile application marketplace. A lion’s share that is projected to grow even more…
When you factor in the media penetration on top of market share, any customer looking to dip a toe into mobile applications is – unless they have a very specific need – likely to start with iOS.