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:


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:


So, they probably should be ignored.

However, shared schemes are saved like this:


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