Coders seek the truth

Why do you debug your code? Because you seek the truth.

What is the truth? Code that works.

It’s impossible for a coder not to want to seek the truth, otherwise why would they waste time writing code that doesn’t work? Code must work. That’s the point of it. Thus, coders seek the truth. When we debug and trace, and spend days in search of the cause of a bug in our code, we are seeking the truth.

It therefore becomes ingrained in the coder to seek the truth at all levels. Perhaps this explains why we have whistle blowers and hackers that want to expose wrongdoing – Aaron Swartz, Julian Assange, Edward Snowden, and many others. When you spend your time seeking the truth in code, why would you not seek it elsewhere?

These people are not “hacking”, nor “whistle-blowing”, they are debugging. They’ve found an issue, and filed a bug report with reproducible test cases.

This begs the question – if coders seek the truth, what about non-coders? For example, certain so-called “managers”, or “directors”. These people get to the top of the greasy pole by obfuscation and lies. They operate behind closed doors, wheeling and dealing, bigging themselves up, putting their name to work that others have done, and continue to protect themselves by concealing the truth.

In terms of coding, they publish phony APIs that serve as a bogus front to private, undocumented methods and frameworks. Consequently, the organisational program becomes hampered by bugs, and any attempt to debug it by those suffering the consequences leads to accusations of “whistle blowing”, or “trouble making”.

If the organisation we belong to can’t be debugged because we’re being fed phony data, we leave.

After all, we seek the truth.

what is truth

Xcode projects and .gitignore

Xcode projects produce quite a few additional settings files that you may or may not want to commit to your Git repository. Some of these may be useful to share with your team members, and some not. A shared (committed to the repository) .gitignore file is therefore very useful. However, not everyone agrees on what should be included in this file.

My .gitignore file for any Xcode project consists of this:

project.xcworkspace/
xcuserdata/

This ensures that individual user settings like breakpoints, Xcode UI layout and workspaces don’t get committed as each team member (or, in my case, each instance on different Macs) will obviously want their own, local, settings.

(“.DS_Store” and other spew is listed in the “.git/info/exclude” file for each of my local repositories. This means that each team member can add their own ignored files without adding them to the shared .gitignore file. Read this for more information.)

Schemes are localized because they include the user name, like this:

MyProject.xcodeproj/xcuserdata/user_name.xcuserdatad/xcschemes/MyScheme.xcscheme

So, they probably should be ignored.

However, shared schemes are saved like this:

MyProject.xcodeproj/xcshareddata/xcschemes/MyScheme.xcscheme

So, don’t ignore the “xcshareddata/” pattern.

Objective-C Singletons – an alternative pattern

Singletons are supposed to be bad practice in any programming language. One of the arguments against their use is that they are difficult to re-use, they hide dependencies, they’re hard to sub-class, and loads of other reasons that I can’t remember since I fell sleep reading them…

Bullshit. There are clear cases where a Singleton makes sense, for instance when you are only ever going to use one instance of a class – for example an application’s data model. The key is to make your singleton re-usable and interchangeable and to provide a façade to the implementation by means of an interface – “write to the interface”. This ensures that the class is not really a Singleton, but that you are accessing a single default instance of the class. This is a subtle difference.

Here’s the canonical way of declaring a Singleton in Objective-C:

The dispatch_once call ensures that the instantiation is thread-safe. That’s it. It’s limited but it works. However, this pattern is the one that the critics shoot down. Here’s a better pattern…

We’re going to create a re-usable Data Model Manager class (DataModelManager) where we can access just one instance (the Singleton), via a Factory class, of an implementation of an Objective-C Protocol and still have the freedom to swap out the implementation if needed (and sub-class, too).

Here’s the Protocol for the Data Model Manager and the Interface that will serve as the factory class:

Any required instance methods for the Data Model Manager should be declared in the Protocol. This is equivalent to a Java Interface. We are declaring those methods that any implementation of the DataModelManager protocol has to implement (required). The DataModelManagerFactory interface returns the (Singleton) shared instance of DataModelManager. The implementation is opaque to the user, and is in fact interchangeable. What we have declared so far is the public API. The consumer doesn’t need to know any more than that.

Here’s the implementation:

We’re using the same traditional Singleton pattern as before, except that we’re declaring the class name of the actual implementation of the DataModelManager protocol in an NSString. This could be declared and retrieved from an external configuration file, or passed as a parameter to the DataModelManagerFactory when initialising. Or hard-coded if you ever need to refactor and provide a different implementation of DataModelManager.

Here’s the interface declaration and implementation of TheDataModelManager:

If we want to swap out a different implementation class, all we need to do is change the name of the class string in the Factory and provide a matching implementation class of the same name. So if we changed it to this:

We would implement it differently:

This pattern ensures that you’re not locked in to a single, static implementation of your Singleton. As the consumer, you only care about the methods that the Singleton declares in its Protocol. The actual implementation can be changed both at compile time and dynamically at run-time if the name of the class is provided to the Factory class. And, as a bonus, it’s easy to substitute a mock class for unit testing.

Let’s modify the Factory class so we can change the class name:

Now we can initialise the DataModelManagerFactory with the class name of our mock DataModelManager class, “MockDataModelManager”:

All we need do now is implement the MockDataModelManager class.

There’s refinements that could be made to this pattern, and improvements. For example, you could pass a Class type instead of a Class string. It’s the basis for a useful pattern.

You could argue that it’s not really a Singleton pattern at all, but that you are declaring a single access point (the sharedInstance factory class method) to an instance.

We can be Heroes, for ever and ever

Julian Assange
Bradley Chelsea Manning
Aaron Swartz
Kim Dotcom
Edward Snowden
Us

We can all play our part, however small. Every act, however small, adds up to a war of attrition. For example:

Use Mega to store your files
Use the latest TOR and TOR Browser
Don’t use GMail or Skype
Use PGP for email
Encrypt everything!

heroes

Native vs. Web Apps (again)

When all you have is a hammer, everything looks like a nail.

Another example of developers coming to their senses –  accounting software developers Xero are ditching HTML5 in favour of native iOS and Android apps

In their blog post, the company explain that developing in HTML and JavaScript was not the wisest decision:

…building a complicated mobile application in HTML5 has been hard. Even with frameworks as amazing as Sencha Touch, we’ve found the ability to iterate as fast as we would like has become harder as our application has become more complex.

The HTML / JavaScript stack initially seem attractive as a time-saving route to development, but sadly this isn’t always the case. In an attempt to save time for the developer, the user ends up with a third-rate experience. Xero say:

Xero prides itself on not compromising on customer experience, and when it comes down to it, the question isn’t “How can we use our existing skills to build a mobile application?” but “What is going to enable us to deliver the best customer experience on the mobile devices that our customers use?”

There has been a cost:

And the lesson we’ve learnt over the last 12 months has been that the cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go.

Phil Libin, CEO of Evernote, wrote something similar two years ago in his guest post, Four Lessons from Evernote’s First Week on the Mac App Store. Libin wrote then that:

…people gravitate towards the products with the best overall user experience. It’s very hard for something developed in a cross-platform, lowest-common-denominator technology to provide as nice an experience as a similar native app.

Sure, I agree, it would be nice to write once, run anywhere, but, as with Java desktop apps, you never get the best experience. Libin is realistic:

As the CEO of a software company, I wish this weren’t true. I’d love to build one version of our App that could work everywhere. Instead, we develop separate native versions for Windows, Mac, Desktop Web, iOS, Android, BlackBerry, HP WebOS and (coming soon) Windows Phone 7. We do it because the results are better and, frankly, that’s all-important. We could probably save 70% of our development budget by switching to a single, cross-platform client, but we would probably lose 80% of our users. And we’d be shut out of most app stores and go back to worrying about distribution.

When all you have is a team of HTML and JavaScript developers, everything looks…third-rate.