GitHub Gists

Yes, I know I’m late to the party. I’ve been using CodeBox for all of my code snippets, but today I created my first GitHub Gist. Easy to maintain and share. And a bonus – it’s damn easy to embed a Gist in a WordPress blog. Just add the URL and you’re done. Interesting thing, though – if you revise and change the Gist, the blog post could get out of sync with the code. Can you link to a specific revision of the Gist?

Here it is:

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