The Daydream Blog

Note that this article is intended for developers and may not be of interest to a wider audience

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 a recent post, Martin Pilkington of M Cubed Software challenged Mac developers to make their apps accessible by the end of 2009. I think this is an excellent suggestion and I will take up the challenge for Differencia.

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 haven’t blogged for a long time and for that I would like to apologise.

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!

Note this article is intended for developers and may be of limited interest to our wider client base.

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.

The next MacMacDev for Edinburgh has been announced for Thursday 10 July 2008, starting at 19:00. The venue is unchanged and is at Baroque, 39-41 Broughton Street, Edinburgh, EH1 3JU. Full details can be found here.

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

Hope to see you there.

Note this article is intended for developers and may be of limited interest to our wider client base.

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.