The stage has been reached in the development of my fitness app, where running through (haha, running) the same tests "as a user" is getting too mundane and convoluted. If you haven't experienced automation in iOS before (or any platform), I'm going to outlay a brief explanation on why it has value, and run a small example on an automated test that I've implemented today.

Context Is Everything:

A company that hired me to do contract work in the summer of 2011, opened my eyes up to automated testing when the tech lead gave a demo on Selenium. Because it was for their Java based web apps, I found it mostly a snore fest at the time. Until a few weeks later when the QA team started to explore automation in iOS. It was definitely one of those aha moments when you think, "oh, that order of motions that I have to do every single time I build and run the app after a change, you mean those motions can be robotic?". The beauty is that robots never forget. We humans are (beautifully) flawed, we forget. Love thy robots.

Having used it frequently for almost 2 years, this is why automation has value:

Is the term "fire" trending again for product names in the dev world? Naming curiosity aside, Firebase are launching their native iOS framework to remove the complexity of passive synchronization in iPhone/iPad app development.

"Early feedback from beta customers and those demoing the product at hackathons has Tamplin and his team confident that they’ve built the most powerful realtime synchronization API available today"

I've been going through another tutorial on the great raywenderlich.com on implementing MapKit in iOS 6. Good tutorial, everything is explained in a coherent manner, and it's a good example to touch base on the concepts of MapKit.

Something struck out at me when implementing the MyLocation class they use. This has been a question on my mind before, and I've had debates about this with other devs - what's the best way to represent properties?

This is an issue that a hacker doesn't care about, there are those who like chaos and those who like quality. The hacker movement has gained a lot of traction over the past decade, to the point of saturation. Like all movements, when one reaches saturation the polar opposite movement comes along and takes over, and the cycle continues. Well, the age of the Crafter movement is arriving. I'd like to expand on this in another post, for now let's focus on properties.

I try to tackle every problem with the mentatlity of "what's the best solution out of about 3-4 alternatives?". The Hacker school of thought has programmed kids with "what's the very first solution I can possibly think of? Let's run with that".

Readers of TechCrunch might've caught sight of this furore over the past few days, regarding a co-founder tweet for a startup called Markerly.

While I don't think it's helpful to have an opinion of it directly, as there's too many opinions expressed over it anyway, I'd like to abstract this out. Extract thinking away from the outcome -> feedback -> damage control cycle.

Think instead of what cause contributed to this. I don't mean in the responsibility-shifting way that dominates politics. Obvisously blame had something to do with it, for whatever reason the CTO of Markerly felt a sense of injustice for not getting covered in TechCrunch. That's not the point. Now redirect the cause to the lesson. The lesson any startup co-founder can take away is this, and I'm writing this mainly to remind myself over time when things start to get hard:

Any startup that soley relies on getting covered by TechCrunch for success, should seriously question their business plan.

Just a thought. One that could save you from thinking of guns.