If you, like me, have migrated from using Subversion to Git, you may be missing the ability to link commits with FogBugz cases. I have adapted the Subversion integration post commit hook to work with Git.

It should be noted that integration with repositories hosted on GitHub can be found by clicking on this link, to appropriately enough, GitHub (via a blog post on FogBugz). These instructions are for use with local repositories.

I have simply taken the Subverson integration script, that is available at this link on the FogBugz website and adapted it for use with Git.

To use, follow the instructions below:

• Install Perl in the unlikely situation that it is not already installed on your system
• Install wget. On Mac OS X, you can install via MacPorts by simply typing sudo port install wget in a Terminal window.
• Download post-commit and logBugDataGit.pl by clicking on this link to GitFogBugz.zip
• Unzip the archive and copy the two scripts to your [Path To Project]/.git/hooks directory and make sure they are both executable
• Edit logBugDataGit.pl as follows:
  • If you are using the free FogBugz version set $BUGZ_URL_FINAL to https://yourdomain.fogbugz.com and set $IS_TRIAL to 1.
  • If you host your own FogBugz installation, set $BUGZ_SERVER to your domain without http:// and set $IS_TRIAL to 0.

That’s it, there is not step 6!

In Martin’s post and the comments there are some links to great resources to get going with accessibility:

Apple’s Accessibility Developer Page.

Assistive Technology for the Mac Resources

Assistive Ware Videos

At WWDC ’06 I went to the Accessibility session and it was the best Hands-On sesssion I’ve been to at WWDC. The 2006 Session video does not seem to be available any more, but the 2008 session can be found from the link below. It requires access to ADC on iTunes, you may need to log into ADC on iTunes first, or simply look for session 326.

WWDC ’08 – Session 326 – Application Accessibility

The 2006 session had an excellent sample application, Dicey, that takes you through stages of increased accessibility. It can be found here:

Dicey Sample Code

However I would like to extend Martin’s challenge. Most independent Mac software developers sell their products exclusively via the web. Therefore for their software to be fully accessible, Mac developers need to make their websites accessible as well.

Information on this can be found at W3C, the web’s standards body, and elsewhere:

W3C’s Accesibility Initiative

Dive Into Accessibility Guide

I would call on all Mac developers to take up the Mac Accessibility Challenge.

I’ve noticed that a lot of bloggers that I follow have not posted much in the last 6 months either.

Wil Shipley has not posted a blog entry since the end of September. Scott Stevenson has had just 5 posts in the same time frame. Morgan Webb and Marc Andreesen have gone off line. And although Daniel Jakult has posted 25 odd posts in that time period, that seems a relatively dry period for him, with 2 week gaps between some posts.

I suspect that iPhone development has had a lot to do with the dry period in Mac blogging, along with podcasts and Twitter as alternative methods of communication.

For me personally the hiatus was due to the passing away of my father last August. In addition, when you have something you should be doing, the longer you leave it, the harder it gets. Of course you need to take the plunge and get on with it.

I have a number of ideas I’ve been considering posting for a while, so hopefully over the next few weeks I should be getting back up to my past output. Hello, again!

Kevin Hoffman has given a critique of the now infamous criticism of iPhone development. (Another Microsoft Developer Falls Victim to Framework Myopia [The .NET Addict's Blog])

The key points in Kevin’s post are his explanation of how experienced Windows developers should handle their migration to Mac or iPhone development. It reminded me of a post I’ve been planning to write for a long time that most easily be summarised as:

To learn Cocoa, you must un-learn your past development experience.

Cocoa assumes an MVC paradigm. Interface Builder and NIB’s are very weird compared to other approaches. The frameworks are heavily designed for sub-classing to create your own behaviour, rather than having lots of settings to tweak behaviour.

Every time you try to learn a new aspect of Cocoa, you find yourself struggling to do something that feels like the “right way”. A few days later you come out with 3 lines of code that feel completely natural but felt incredibly painful to reach. You will be met with countless, “aaah, that’s how it works and it makes complete sense” moments. You spend days wondering why this bit of Cocoa is so gnarly, and seemingly unintuitive, until you reach another moment of understanding.

People often say that Cocoa has a steep learning curve. It does not. It has a steep un-learning curve, followed by a gentle re-learning curve. Getting yourself out of your previous development mind set can make the whole experience a lot more pleasant.

What is disappointing is that none of the documentation or tutorials spend much time comparing and contrasting with other approaches, that would make the process of unlearning easier.

There’s also a new mailing list for the community, full details can be found here.

Hope to see you there.

Last week saw the release of Cornerstone, a new Subversion GUI client for the Mac from Zennaware. After initial testing, I am quite excited about Cornerstone, as it breaks new ground for Version Control Graphical Clients.

Historically, graphical version control clients have simply put a GUI on top of the command line tools. It is disappointing that there is little or no thought given to the problems that developers want to solve with their source control systems. Developers of these applications seem to completely forget the issues they themselves face.

Cornerstone’s most impressive feature and one that I have discussed extensively in the #macsb IRC channel is it’s timeline. You can easily go forward and back through the history of a file and see changes for each subsequent version. Whilst this falls short of my wishes for a source control timeline, it is a massive step in the right direction.

Cornerstone’s source code diff tool looks great, but still cannot identify when a method has simply moved within a file. If you change the method as well as move it, which is quite common, the changes are not clearly highlighted in Cornerstone, Xcode or any other diff tool I have come across on the Mac. I had already decided that a future version of Differencia will act as a source-code aware diff tool.

Whilst there are a long list of feature requests I have already for Cornerstone, after only a day’s use, it is a huge relief to find that someone is taking source control seriously.

If you are interested, please email david at macmacdev dot com. Further details and updates can be found at the MacMacDev website.

There are already 8-9 attendees, so a healthy number. More the merrier, so please let David know if you would like to come along too.

Since moving to Scotland 18 months ago, I have been surprised by the number of Mac developers based here. I had heard of the Silicon Glen, the idea that there are a number of tech related companies in Scotland, but it was a great surprise to find so many Mac developers here. It makes a huge difference to have a local community, as well as a strong online one.

Glasgow meetings are planned for the 4th / last Thursday of every month, with the next one on 29th May.

Edinburgh meetings are planned for the 2nd Thursday of every month, with the next meeting planned for June 12th. Whilst this is during Apple’s developer conference, WWDC, there should still be a good attendance. Exact venue is yet to be confirmed, and the best place to keep an eye on things is the MacMacDev Website

There are also plans afoot to have a MacMacDev meet up at WWDC, details yet to be confirmed, which will be a good opportunity of East and West coasters to meet up to compare notes.