December 2011

[caption id="attachment_1628" align="alignnone" width="300" caption="Weird Al's not the only one who knows how to go large with Jackson"][/caption] A couple of months ago I was asked to build a processor that would take a JSON file; perform a few elementary checks and transformations and upload the resulting records into a Couch DB. I hadn't done any JSON, or Couch and, naturally, the whole thing had to be done yesterday - but at first glance it didn't look like much of a challenge. However, looking a little deeper, my processor was going to be part of a replication process across two databases housed in separate enterprises. The replication was going to be based on a daily snapshot - each JSON file would be a copy of the entire database - and a few back-of-the-envelope calculations suggested that the files may become rather large (40+GB) over time.

Getting started with the development of location-based services on Android is relatively easy thanks to the well documented location API. However, getting more serious shows there is still much uncharted territory. One such area concerns the accuracy of real-life location data, which I have recently taken a close look at. In short, location data can be far more accurate than Google's conservative estimates - at least with the phone that I used.

Swipe Conference Of the many excellent sessions at this week's Swipe Conference, the one titled "Build Better Cocoa Apps Using Game Mechanics" by Paris Buttfield-Addison was unique in its topic. In it, Paris outlined how gamification is currently viewed as something that can be quickly slapped onto an existing product in order to increase its appeal, whereas in reality, successful gamification requires carefully thought-out integration, for when done correctly it should form a core part of your app's user experience.
We’ve all heard developers say it: “I’m a terrible drawer” or “I’ve got no design skills”. Perhaps we’re even guilty of saying it ourselves - I know I am. But after attending this year’s Swipe Conference I now subscribe to the opinion that this is no longer acceptable. We are all responsible for the design of the app we are building; developer, designer, tester, or producer: every member of the team is accountable for helping shape the app’s design and interactions.
Yesterday was the last day of Swipe Conference so I thought I would take this time to reiterate one of the points I took from the first presentation by Josh Clark.  Josh covered quite a few topics and if you haven't already you should check out his book Tapworthy: Designing Great iPhone Apps. In short:
  • Gestures can be brilliant … if the context they are used in feels natural
  • If you're using gestures make sure your users will find them
  • If you don't think your users will figure out your gestures easily, don't overload your users with lots of help hints all at once; instead, let them "unlock" them over time, like a reward for using your app
  • Downside though is that there is no consensus on what a 3 finger swipe gesture might do. Every iOS app that uses this gestures decides it for themselves.
It was obvious from the way Josh presents that he has so much passion for touch / gesture based devices. What I personally took away from his presentation was that gestures can be awesome shortcuts within your app. In a lot of cases gestures are a natural progression with how we interact with real world items.
Shine was recently involved with helping a client bring an outsourced mobile web site in-house. The site was essentially a guide for browsing business and event information for cinemas, restaurants and bars in your area. Bringing this web site in-house was mainly an exercise in re-writing the outsourced instance as a component to the client’s own internally developed NodeJS/Express app server (currently used to serve their main - non-mobile - web site). The NetBiscuits platform was used to handle all the device specific porting which allowed the development effort to focus almost entirely on business logic and backend data processing. The combined learning curve of NetBiscuit’s own markup language with Shine’s Jazz template system was simple enough to make the presentation layer development a breeze. This blog will talk about the process involved in developing for NetBiscuits and some of the problems and solutions encountered on the way.

Cliffano Subagio from Shine Technologies presented together with Carl Husselbee from Sensis "JavaScript from Nose to Tail" at the August MelbJS Meetup. The slides and the video of the presentation are now online....