Carbon Travel Tracker

Okay so now in the iTunes Store is my first attempt at an application that does something actually useful. Its the Carbon Travel Tracker. I travel a lot, not as much as some but quite a lot more than most, two questions always came to mind

1) Just how much do I really travel
2) What is the Carbon impact of that

In the spirit of 'if you don't measure it you can't change it' this really was an application where I wanted it to be really hands off.  I don't want to have to enter all of my travel, I want my phone to stalk me all the time and work out what sort of travel I'm doing and what is the impact of that.

There is much more on the application on the Carbon Travel Tracker support pages but here are a few highlights

1. Tracks automatically in the background - kick it off and it just runs
2. Automatically splits travel into sections/journeys and makes an educated guess on the travel type
3. Allows you to manually override whole sections or sub-sections with the actual travel type
4. Records your distance traveled in the day, week, month, year and since the app was installed
5. Records the carbon impact of that travel
6. Tells you how many times around the world that travel equates to
7. Tells you how many trees, over the same time period, it would take to make you carbon neutral

The purpose is really to have a map so my kids can see where I've been an it sort of escalated from there.

So the map required points, points gave me distance and speed, speed & distance gave me travel types and finally that gave me the carbon impact.

So I now know that basically I don't have a Carbon Footprint, I have a Carbon Body bag.  Now as it says at the top, this app is now:

How Apple will beat Facebook

Looking at the extension of iMessage to the desktop made me think about how Apple can take on Facebook and win.  Lets see what Facebook have over Apple technically...

1. Multiple people in one conversation
2. Broadcast conversations with 'followers'

Now Apple have already integrated Twitter into the iPhone but lets assume that long term the folks from Cupertino want total control.  What do they need to do?

1. Add a 'message thread' function to iMessage so its not just a stream between two people
2. Add the ability to talk in groups
3. Add the ability to broadcast status updates

Applications can compete easily by having some form of multiplayer iCloud sync, or in the same way they already do via 3rd party servers.  What more could Apple do however than Facebook?

1. Integrate the status update piece into Contacts so before you call you see the status and can see the recent messages
2. Integrate the group chat dimension by having 'groups' in Contacts (umm almost Circle like)
3. Provide multi-participant Facetime to switch from iMessage to group comms

The point here is that technically Facebook don't have much that Apple couldn't make standard Mac OS X and more importantly iOS functionality.  Indeed much of this would be a welcomed integrated upgrade to those things (rather than a clear market grab like Google+) so people would 'naturally' start using these facilities as they are on their phone/desktop.  This would increase the link to Apple products in those communities (much as Blackberry used to see).

An added advantage of Apple's approach is that it can remove the view of a 'big central server' and instead create a more federated view of inclusion than Facebook.  This is liable to help increase people's engagement levels and unlike Facebook Apple doesn't need to drive revenue via advertising or selling people, it wants to drive that via more people on its platform as those people hand over real hard cash.

Facebook's big risk is that its network ceases to be the cool and only place to network and that other social based approaches take off.  Apple are ideally placed in the consumer space and have the platform control mentality to drive this.  iMessage is only the start of the evolution, the question is just how much engagement does Apple want to have?

Why I rewrite rather than re-factor

Refactoring is one of those terms in IT that gets bandied about as a good thing.  Refactoring is meant to be the small incremental cleaning up of code to restructure it while leaving it functionally the same(1).  Some folks say that re-writing is different as it changes this functional contract.  What happens in the field however is different...

Refactoring tends to be done in small chunks and done incrementally around a specific area, for instance a single function or class.  The refactoring tries to 'evolve' the code to make it better and does have some good theory behind it, but regrettably in the field I tend to see refactoring creating an incrementally more complex mess as parts are 'optimised' while the whole collapses.  Refactoring in the field is also mostly done when you've got new functionality, so the idea of functional equivalence goes out the window its now just about refactoring as you develop a new requirement which means that the new requirement skews the refactoring.

This reality of refactoring in the field means that I often come across code that has gone through several refactors and each was tinged by the mentality of the developer undertaking a specific new piece of functionality, the refactors therefore are not making the code better but instead making it better to develop that one specific requirement.

For this reason I'm actually a big fan of re-writing and, whisper it quietly, I tend to find its quicker and produces better code, especially from a maintenance perspective.  Now I could argue what I do is refactoring as I'm always rather anal around getting interface designs right and they tend to be rather stable as I put quite a bit of time into them.  The reality though is that the body is completely changed behind the facade.

Re-writing works because I now know what I didn't when I first planned the internals.  I know the additional requirements that I've received and the new information classes that I now must operate on.  Recently I had a piece of code where I had spent a couple of 'refactors' making it 'better' and the code was a bit cleaner and more manageable.   I then came across a bug which was proving rather hard to track (Objective C how I loathe you) and some new functionality I wanted to develop was adding complexity into the code... so it was re-write time.

About 60  minutes later there were 120 lines of code (SLOC) where previously there had been 300+, this clean down had removed the bug (which was to do, as ever, with memory allocation) and added in the new functionality.  The new code had been quick to write as I now understood much better what the end-goal was thanks to new requirements through a few iterations and I'd a much better grasp on how all of the different classes needed to engage.

Functionally my class interface hadn't changed and the calling classes didn't need to change but its hard to claim what I did was a simple refactor as I trashed every single line of code and re-wrote from scratch based on the requirements & design.

Refactoring has become a short cut for 'don't do it well first time' and the reality of the field does not match the theory in the books.  Too often the phrase is used to hide bad code, badly re-structured (and I'll admit that my first pass was in retrospect just that as I didn't know quite how Objective C and iOS worked).

Its time to come clean:

Sometimes its better and quicker to re-write than keep up the facade of 'refactoring'.

Technorati Tags: SOA, Service Architecture

IT going backwards - Objective C is 90s retro

I've ranted quite regularly on how Enterprise IT just hasn't really developed in the last 5 years and my personal task for 2012... learning Objective C and programming for iOS has taken my disbelief to another level. Back in 2008 I learnt Python and for me it sucked. Its 'advantage' over scripting languages of the 80s and 90s was minimal and it had the most hated (for me) of things... indent sensitive code. Objective C however really has stepped it up a level.

I remember learning Ada, C and Eiffel (along with bits of LISP, Prolog, Assembler, etc) and most of all I remember being confused as to why people like coding in languages like C, where the syntax is terse bordering on emo, over languages like Ada where even non experts can have a crack. Through my career people have claimed the stupid 'less characters = language efficiency' which again matches up by saying that Martin Luther King was a crap communicator while a grunting teenager is much more efficient.

But all of this couldn't prepare me for the horror that is Objective C. SIGFAULTS in 2012? Seriously? Have years and years of exception handling been ignored? No even better than that... Objective C has exceptions but you are discouraged from using them, yup they are there but are 'resource intensive' so you shouldn't use them.

Second off we've got the wonder of memory management again, although now with 'ARC' it actually does some garbage collection, yup folks its 2012 and Apple have just caught up with the mid-90s.

All of this is annoying, and rubbish, but that would be nothing if the language had a nice syntax and logical way of working... but Objective C is like people have looked at Java, C, C++ and then sat down and though 'how could we make this really suck?'.  Yes its the same old .h/.c (or .m in this case) combination of header and code but just basic things like function calls are made excessively silly.  No simple .(, ) for Objective C... well not always, sometimes and you can do it but not normally... ahh consistency avoidance always a great way to have sucky code.  No in Objective C you call a function like this

[instance method]:param1 param2:param2

This means you end up with wonderful code that looks like

[[[eventHistory getEventAt:location date:date] calculateDistance:newLocation].doubleValue

Notice that '.doubleValue'?  Yup when using NSNumber (object for doubles) you use the old '.' notation. Perfect eh?

Then we have XCode, an IDE that seems to crash if you do anything it doesn't expect rather than a warning saying 'Fail: you didn't mean to do that'.  Some bits are nice, like some of the code generation and some of the bits, like refactoring, are pretty much up to Java IDE standards from 2001/2002.

The layout model in XCode is okay, with some nicer bits around chaining screens but seriously is it that hard to implement XmForm?  With the multiple display layouts that you get with mobile devices it really would be a cracking layout manager to have.

Then we have the iOS simulator, its great, except if you want to simulate locations that Apple hasn't thought of... the 'accuracy' if you use custom locations (for instance if you want to test something using European locations) is 150,000m... or to put it another way... a level that every decent piece of code should ignore.    Application development speed wise I'd clearly be faster in Java, but as a new language I'd say that Objective-C ranks behind C++ in terms of 'complexity' to learn and ranks significantly behind both C and C++ in terms of language efficiency.

But that said the example code pieces are good and the online manuals are good as well and I knocked up the second stage of my application on a flight across the Atlantic.  Basically however it feels like using C++/Motif with Emacs and the TeleUSE UI builder.  Its 2012, shouldn't it feel like we've progressed?  What it really feels like is some sort of retro homage to the 90s wrapped in a shiny and expensive new package.

From now on I'm only coding for iOS while listening to an iPhone playlist 'Songs of the 90s', it helps get my mind in the iOS Zone.

Technorati Tags: iPhone, iOS