Of course there are quite a few similarities. It shares the C heritage of C++, it is highly dynamic like Python and Ruby. However, the biggest difference between Objective-C and most other languages is how method names and arguments interact.

At first glance a lot of developers coming from other languages think that they are simply named arguments which is wrong, VERY wrong. This is one of my pet peeves about new Objective-C developers, and every time I see someone talking about named arguments in Objective-C I always feel a need to correct them. But if they aren't named arguments then what are they?

Interspersed Arguments

The arguments aren't named, but interspersed with the method name. For example, a method in another language may be obj.foo(namedArg1=bar, namedArg2=possum), so its method name is foo. In Objective-C a similar method may be [obj foo:bar with:possum]. In this case the method name is foo:with:. So the arguments aren't named, they are mixed in with the method name.

There are some key differences between named arguments and interspersed arguments:

1) Named arguments' names are not part of the method name
2) Named arguments can be re-arranged
3) Named arguments are often optional

None of these hold true for interspersed arguments. This is why I've seen quite a few people complain about Objective-C's "named arguments" not being very flexible. When you realise they aren't named then things get much easier to understand. As with everything in Cocoa and Objective-C, if it is different to what you are used to, then there is likely a very good reason for it being that way.

Examples

So it would make sense to show some examples comparing named and interspersed arguments. So lets take a common Objective-C method:

[@"A string" compare:@"B string" options:NSCaseInsensitiveSearch range:someRange];

And now lets convert it to a language like Python which has named argument, treating the arguments as named arguments:

"A string".compare("B string", options=NSCaseInsensitiveSearch, range=someRange);

Not a big difference at first, but lets try some variations:

"A string".compare("B string", range=someRange, options=NSCaseInsensitiveSearch);

"A string".compare("B string", options=NSCaseInsensitiveSearch);

In Python those are both the same method as the first one. However, in Objective-C, re-arranging the arguments or removing them would result in an entirely different method being called. While in the Python examples the method is called compare() in the Objective-C example it is called -compare:options:range: which is a big difference. If we correctly treat the arguments as interspersed then the Python example becomes:

"A string".compare_options_range("B string", NSCaseInsensitiveSearch, someRange);

Of course Python doesn't support interspersed arguments so they are all attached at the end, but basic rules are the same. Hopefully this has helped quite a few Objective-C newbies to understand one of the many differences between it and other languages they are used to, but if you have any questions then leave them in the comments.

M Cubed has been a part time venture ever since it was founded back in 2005. It always came second to exams and assignments and homework. Because of this releases have been far and few between and often come in spurts when I've had a lot of free time. In the past 3 and a half years I have released just 10 major updates to apps. I'm wanting to seriously improve on that by getting major updates to all my current apps out by the end of the year, and possibly a new app or two.

With all the extra time I will have now, you can expect to see a lot more open source efforts from M Cubed as well as more blog posts discussing various technical things. It will be nice to be able to dedicate time to give back to the community that has helped me get to this point.

And finally, there is some incredibly huge news still to come, all will be revealed on the 1st of July, so watch this space.

For those who don't know, I'm based in the UK. Yesterday the UK government announced the budget for the next year. As well as hearing about how we're all basically doomed the government announced that there will be a new 50% tax band for those earning over £150,000 a year. This means for every pound you earn over £150,000 a year, half of it will go to the government to pay for various public services.

Of course there has been outrage from many of the 1.5% of the population who earn over £150,000 a year and this is partially understandable. Nobody likes paying taxes, but they're a necessary evil and help to pay for things such as health care, roads, schools, parks, refuse collection, police, fire services, defence and many other crucial services. Unfortunately some of the rich feel they're being punished for being successful.

Perceptions of Success

The BBC News had a businessman on their channel to talk about the implications of the tax rise. He felt it was unfair that the successful were being punished for their success. Of course what he really meant was "rich". There is a common perception that in order to be successful you have to be rich. To me this is incredibly flawed. A CEO of a failing company can be incredibly rich but the owner of a small, but successful business may not be rich (thought they probably aren't poor). Yet for some reason the CEO is seen as more successful in life.

Its this perception that leads to many people's desire to be rich. They want to be seen as a success. The problem is it is wrong. Taxing people 50% on their earnings over £150,000 isn't taxing the successful. It isn't really taxing the rich either. It is taxing the greedy.

Massive wages = greed

OK, so that is a little unfair. Some people need bigger wages. Perhaps they're in a career where they can't work until they're 65. No-one would have any qualms with police officers, fire officers, sports stars, soldiers, physical labourers etc earning higher than average per year. Their wages may go down after they are required to change career or forced to retire because they are too old, or have picked up an injury caused by their work, so earning more while they're in their prime makes sense.

I'm also not advocating everyone should be paid the same wage. Those who are highly skilled should be paid more then average. Those who put themselves in danger and/or save lives should be paid a hell of a lot more then average (and also a lot of respect). A varying pay scale is perfectly fine. It is also a case where you may need to earn more depending on the number of people dependant on you (eg children) or where you live (eg London is a much more expensive place to live than Blackburn).

The problem is with those who earn a lot of money each year, more than £150,000, and then spend it on themselves. These are often the people complaining the most about higher taxes for the rich. Of course not everyone who earns that much money is greedy. Some people earn a lot of money but give a huge amount of it away to charity. Nobody could call those people greedy (indeed I believe all money given to charity should be fully tax deductible to encourage more to give to charity).

But those who have a lot of money left over after they have given to charity and paid for the essentials that everyone needs are just being greedy. They'll likely buy themselves a much bigger house they need, or an extremely pricey sports car etc. Things they don't need with a huge amount of disposable income. Things to signify "success".

The Right Thing To Do

So if you are earning that much money, you really have no right to complain. If you are running a successful business and taking £150,000 a year in wages or more then you're being greedy. You could give yourself £50,000 a year and still be incredibly well off. You could have a large house, 2 very nice cars, go on holiday abroad once a year etc.

But what about the other £100,000? Well that could be given to charity. Think about how much good you could do with £100,000. Or how about hiring some more staff. You could hire three people for £33,000 a year. That's a pretty decent wage and you've just helped lower the unemployment figures by 3 people.

The reason that those who earn a lot of money are taxed at a higher rate is that the money they have being taxed at that rate is disposable income. They don't need it, they simply want it. That money can be used for a lot of good and improve the lives of a lot of other people.

Success really needs to be redefined, or rather it's actual definition needs to be reclaimed. Success should be based on how well you perform, not on how much you earn.

Businesses vs Individuals

Businesses are slightly different to individuals. If a business earns a large profit then it's not necessarily a bad thing. In fact that is success. Of course how they use that profit is key. They may give all their employees a share of it, or invest it in research and development. They may save it in order to protect themselves against times when they make a loss or for future plans such as expansion which will create jobs.

Of course, that doesn't mean businesses should be entirely immune to criticism either. If they do make a huge profit they should also not complain about it being taxed. The money that gets taken away as tax goes towards many things that help them as a business prosper, and also in improving the lives of their individuals.

Tax money that goes into improving schools helps provide more skilled workers for the business. Tax money that goes into transport helps the business move their goods and workers around. Tax money that goes into communications infrastructure helps the business expand while being able to keep track of everything. The taxes being taken from a business's profits aren't really a loss of money, but an investment in the business.

Success = Doing Well

As I said earlier, taxes are a necessary evil. But higher tax rates on higher earners is not taxing the successful. There are plenty of people earning under £150,000 who are successful, to say otherwise would be saying 98.5% of the population are failures.

Success as a word needs to be reclaimed to mean doing well, setting out goals and meeting or surpassing them. If we can do that then maybe we can see society becoming more equal and those who do earn a lot of money choosing to help others with it, rather than themselves.

The Conference

The talks were great and I picked up some great tips and learned about some cool technologies that I'll be looking into more in the future. It is often the little things you pick up from in talks that really stick with you and can help you the most. This was helped by the last session where the speakers had to give a few quick tips over 3 minutes after being pulled away from an application design competition they were working on.

I was lucky enough to be given a short lunchtime slot to talk about accessibility. I made the talk, not to discuss technical issues, but to emphasise why accessibility is important and should be top of our agenda as developers. It seemed to really resonate with those in the room, with many saying they were going to make the pledge to make their apps fully accessible by the end of the year. Those who didn't were also very committed to accessibility but many didn't want to make the pledge as they were unsure they would be able to fulfil it before the end of the year. At the very least, it brought a very important topic front an centre to a large chunk of the Mac developer community.

The conference was held at the University of Hertfordshire in Hatfield on the relatively new de Havilland campus. The facilities there were great, with the restaurant (which served excellent food for breakfast and lunch), bar and lecture theatre where the talks were held all within a short walk of the accommodation.

Of course, being a university campus the accommodation was decidedly student oriented, though still being a student it wasn't a problem, plus besides the few moments spent sleeping there wasn't much time spare to be spent in your room.

Now all this wouldn't have been possible without the time and effort put into organising and running the conference by the staff. Scotty and Tim did a great job and managed to put on an amazing event which everyone who went is thankful for. And we can't forget Dave, who dealt with many of the technical aspects of the conference and Ben, who sat patiently outside at the registration desk for hours on end. These guys worked incredibly hard with very little, if any, money in payment for their time and effort and a lot of people now owe them a great debt of gratitude. Here's hoping for an NSConference 2010. If there is one you can bet I'll be there.

One important thing that was mentioned at the conference but not linked to, was my unofficial attendees list. If you went to NSConference make sure you add yourself so others can know you were there!

The Badge

Now, as all the praise is out of the way, lets get onto what went wrong. (Actually, one more bit of praise. The badges we received were incredibly well designed and clear and it was obvious a lot of thought had gone into them. Anyway, back to the failing).

It turned out I was the very first person to register for the conference (I feel like I should have had a golden badge with "#1" written on it, but oh well) and so my badge ended up being the test badge. Scotty and Tim printed out loads of badges with my details on until they got it right. Once they'd perfected mine they printed out everyone else's.

Then it comes to the conference and they pull out all the badges to put into their holders. Out of over 100 badges the only one they couldn't find was mine, the one which they had done the most copies of over the past few weeks. So of course starts a frantic search for the badge, which is eventually found at the bottom of a waste paper bin all crumpled up.

So here is my badge, all crumpled up, next to all the pristine flat badges of the other attendees. So what is the solution to this? Well they pull out an iron (who knows why they had an iron) and start to ponder whether they should iron the badge flat. Thankfully this whole thing was caught on camera by Alasdair Allan (see his flickr set for the conference here) for all the world to see, so I shall leave you with 3 orange men, an iron, a hair dryer and my badge:

Scotty, Tim and Ben wondering how to flatten my badge. Photo Credit Alasdair Allan

If you are creating an AppKit application, then you have an autorelease pool set up for you so you don't need to worry about it most of the time. If you set up a Foundation tool then you'll find that the Xcode template puts code to initialise and release an autorelease pool at the beginning and end of your main function.

However, a problem arises when you're creating a lot of objects at once. The obvious solution is to initialise and release objects by hand in this case, but sometimes it isn't possible. A lot of objects returned by Cocoa methods are autoreleased (by convention any object returned by a class method (other than +new or +alloc) should be autoreleased).

I had one of these situations in Code Collector Pro. Some users were having problems when pasting in the jQuery code, so I decided to investigate. I found that CCP's memory usage was jumping up by about 800MB when performing the regexes to find what code to colour. Obviously that's bad.

The problem is, there were a huge number of autoreleased objects being created, but the autorelease pool only releases all the objects it contains at the end of each cycle of the run loop. All these objects are being created on once cycle.

The solution? Make another pool just for these objects. Autorelease pools are stored in a stack (one per thread). If you initialise a new one all objects autoreleased until you release the pool will go into it. The code that was creating objects was running in a loop so it made sense to release the objects after every iteration of the loop. So I changed my code from:

for (id item in array) {
    //Perform regexes and colour
}

for (id item in array) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    //Perform regexes and colour
    [pool drain];
}

This reduced my max memory usage from the 841.07MB show above to 22.33MB. You can also see below how there are many peaks and troughs in the memory taken up by objects now. These represent each iteration of the loop, where a lot of objects are created and then released.

Good use of NSAutoreleasePools in areas where you are creating lots of objects can reduce your memory footprint a huge amount, especially in loops.

For the first year this did seem to be the reality, with developers getting fixed 4 or low 5 digit sums for their participation (apparently the amount each dev got was doubled after they saw how successful it was. This is what caused most of the outcry as it seemed those who were doing the marketing were exploiting those who did the "real work".

The second Mac Heist didn't receive quite as much controversy. People felt that developers knew what they were getting themselves in for this time. The deal was also a revenue share one rather than a fixed amount. The third and current Mac Heist is operating the same way and is receiving even less controversy.

The change is that developers are finding out more about how the bundles are run and maybe have participated in one of the other smaller bundles. The users are seeing better and better bundles each year with huge sums going to charity. And most of all we're finding out that it isn't a case of the developers doing the "real work" and the Mac Heist team just setting up a website. The amount of polish that goes into the website and the challenges rivals even the best Mac apps. Every year it becomes more apparent that Mac Heist isn't an easy thing to organise.

But...

But none of that will make some of the issues go away. Does this devalue Mac software? Does it hurt developers? The first question I can't answer beyond saying that only time will tell, but I think it won't. The second one I can answer with a resounding no.

For those who don't know, I participated in a smaller bundle earlier this month called the Mac Bundle Box. It worked on a similar concept with 14 apps selling for $49 with 5% going to charity and each developer getting a percentage amount of the profits. It didn't sell anywhere near as many copies as MacHeist does, but it was still a hell of a lot of sales. How many sales? Well I made about twice as much as I currently do a month from regular sales, yet my support load has hardly increased.

Another important impact is the publicity. Your sales outside the bundle can increase as people find out more about your applications. Of course this is more likely to happen if your app costs less than the bundle price, but it is an important thing to considered. It also builds up your user base meaning many more people spreading word of mouth reviews.

Money, money, money

As an example of how much developers are making let's look at the figures Mac Heist provides on their site. At the time of writing there has been $123,000 raised for charity, meaning $492,000 in revenue. There are 12 apps, plus a bonus app, plus the Mac Heist team all getting money from this. Let's assume a straight 14 way split, that would be 7% (actually a bit more but let's round down to take into account expenses somewhat). That would mean each party has so far got $25,830, enough to live off for a year if you keep your costs low.

And this is only so far on the first day. There are another 13 days to go on top of the rest of today. Sales will slow down but they'll still be making a 5 digit sum each day. Let's conservatively assume that they average $10,000 a day, that would be $140,000 each for 2 weeks.

Obviously the maths isn't perfect, the expenses may be more, the parties won't get equal amounts (I'd wager that the cheaper apps get a smaller percentage than the bigger apps), but we're still talking a LOT of money. One Mac Heist could set a developer up for several years or let them invest in support staff or other developers. Basically it is more than a good deal for developers, so don't worry about them unless the ones participating start complaining.

Of course OK isn't good enough. The Mac is a platform the prides itself on user interface, yet it seems it isn't quite as good as we might think. I'd spent no time thinking about accessibility in my applications, and while they were more accessible than I was expecting, there is still a lot of work that needs doing. So I thought I'd check how some other popular applications work with accessibility and what can be done to improve accessibility on the Mac as a whole.

Using VoiceOver and Keyboard Navigation

The first thing to do is explain how to use VoiceOver and navigate your application with the keyboard. Let's use iTunes to try with. With standard keyboard navigation you can easily enough move between the search field, song list and source list and can click on the various buttons with the mouse. But obviously this isn't going to be enough for someone who is visually impaired or who has a motor disability to make full use of iTunes.

To turn on VoiceOver you can go to System Preferences > Accessibility, or just hit Command-F5. Now you will see a black border around one of the UI elements. This is the currently selected item. You can navigate the UI using control-option and one of the arrow keys. Just move around and see how you can how access the full UI, especially take note of what VoiceOver is saying on the various buttons.

Quick Tip: To navigate HTML content, hit control-option-A when the HTML view is selected. This will start reading the full site. You can now use control-option and the arrow keys to navigate the HTML

Below is a table containing some useful shortcuts for navigating the UI from your keyboard, even without VoiceOver selected:

Now try your own app and see how it fares; odds are it won't do too well. But you aren't alone. Here are a how well a few popular Mac apps work with accessibility.

Coda

For the most part Coda isn't too bad, but one pretty serious bug. It seems to cause VoiceOver to be unable to move around the UI if you switch between Local and Remote views in the source list, stating that it is "busy".

Coda also highlights the most common accessibility flaw: Image Buttons.

As you can see, the descriptions of these buttons aren't very, well... descriptive. These are the most common problem, yet also the easiest to fix and can make a world of difference.

OmniOutliner Pro

OmniOutliner Pro has a huge failing. There's no way to navigate to the inspector using just the keyboard. The standard Control-F6 command doesn't work. This means that you have to use the mouse in order to move to an inspector. And when you have moved to an inspector, there is no way to move between those inspectors without again using the mouse. This is a shame as the rest of the application works pretty well with VoiceOver.

MarsEdit

As with most applications MarsEdit is fairly good, but far from perfect. In the post window there is no way to navigate to the Categories table. You can just about get it to highlight with VoiceOver, but it won't let you navigate it. Besides this though the post window is pretty good. The same goes for the main MarsEdit window, besides the image buttons with no descripdtion it has no major flaws.

Delicious Library 2

Again, Delicious Library 2 suffers from image buttons with no descriptions. But by far the biggest problem is the main display view. They keyboard navigation is great, I can move all around my books and CDs and DVDs using my keyboard. But I'm getting no feedback about what the currently selected item is. As I switch items it would make sense for it to read out the names of those items so I know where I am.

The Challenge

So I did come at those from the perspective of someone who hasn't got a disability (well I need glasses and have mild RSI but I can use my computer without needing any real help). What I consider "pretty good" may still not be too good for a disabled user. But what is obvious is that there is a lot of work that needs to be done. We all take so much care and pride in our visual UIs that we don't think enough, or really realise that there are other UIs that people need. Most of us wouldn't ship a shoddy, half baked UI but the fact is that we are all doing that.

So I thought I would challenge my fellow Mac developers to do something that I am pledging to do here and now:

"By the end of 2009, all the apps I produce will be fully accessible"

What do I mean by "fully accessible"? Well, I take it to mean the following points:

• The UI available to VoiceOver users should be as user friendly as the visual UI
• All UI elements should have titles and/or descriptions
• All custom controls should provide full keyboard access
• There should be a clear and logical order to navigating UI fields with the keyboard
• Every part of my application should be reachable without the mouse

Of course there are some caveats. Some applications cannot be easily made accessible. Photoshop for example would be nearly impossible to make fully accessible to visually impaired. But it is conceivable that someone who is unable to use the mouse could draw. OS X does provide methods for controlling the mouse cursor with the keyboard, but with some inventive thinking certain classes of drawing application could be made much more accessible.

Accessibility For All

Making your application Accessible can also offer great advantages in other areas. Tools such Instruments and Automator use the accessibility APIs for recording UI actions to perform back. This can help you as a developer with debugging and your users with automating your application. And if you or your users want more flexibility, making your application accessible opens up the possibility of creating UI scripts in one of the various supported scripting languages.

There are also other potential applications of accessibility. Those of you from pre-OS X days will remember the old Mac Help system that could guide you through performing an action by highlighting the relevant parts of the UI and even performing the actions for you. There's no reason why that shouldn't be possible in an OS X app. Imagine how much documentation writing and support time you could save by being able to have your application show users how to use it!

But...

Of course there will be some questioning the value of doing this. They realise it's a nice gesture, but they don't see the return on investment:

"But I don't know anyone with a visual disability" - I don't know any starving african children or anyone dying from cancer, doesn't mean I shouldn't care. Because you don't personally know someone with a problem, doesn't mean nobody has that problem.

"I've never received any support requests asking me to improve accessibility" - That doesn't mean there aren't those out there wanting better accessibility. Consider that someone might use your app, find it's not accessible and just give up on it. They're not going to waste time sending you an email when they can't see if your app is even worth their time and money.

"Sounds like a lot of work, I'm not sure if it'd be worth the time" - Making your applications completely accessible may take a lot of work, but you can do a huge amount in just a few hours just using Interface Builder. Going through and making sure you controls all have accessibility titles and descriptions, linking your UI elements together properly, making sure the accessibility hierarchy is usable. All these are small tasks that don't take too long and can improve your accessibility a huge amount. You don't even have to do all the accessibility stuff in one version, split it over several versions.

"But I can't make my application accessible for blind people" - Don't think that accessibility is just for blind people. Being visually impaired doesn't mean you can't see, just that you have trouble seeing. There are also other forms of disability that need accessibility such as hearing disabilities and motor disabilities. And on top of this, keyboard navigation can appeal a lot to power users who have no disabilities at all

In Conclusion

Unless we experience something or are affected by something personally, we usually don't care about it as much as we know we should. Try closing your eyes and doing something. Odds are you'll end up opening your eyes for a peek at some point. You're lucky to be able to do that, some people can't.

I've not got a disability that limits my ability to use the computer and don't personally know anyone with one, but I do have a strong sense that we should all be treated equal and have equal opportunities. When we can do something to help someone else and it is very cheap or very easy to do, then we should do it. Making accessible applications can be very easy and not take too much time, but can make a world of difference to some people.

Over the coming months I'll be posting my experiences in making my applications fully accessible so you can learn from what I've found out. We've already made the Mac the platform with the best visual UIs, let's make it the platform with the most accessible UIs.

Apple's Accessibility Developer Page

The great thing about bundles like this is that you can find out about lots of other cool applications you've never seen before, such as Espionage, QuickScale, Magnet and Involver. A lot of people tend to criticise bundles that don't offer "the big names", but I personally find them much more useful for finding new apps if you've never seen them before.

This bundle is also donating 5% of each sale to Charity: Water, a charity that aims to give clean drinking water to the 1.1 billion people without it, so not only will you be getting a lot of great apps for a low price but you'll be helping others get what we all take for granted.

The two main items on the page are M3Extensions (my set of extensions to Cocoa that I use in all my apps) and OCRunner (my GUI for the OCUnit testing framework). OCRunner's page isn't quite finished yet so it just links to the Launchpad site. I'm going to be spending a few days polishing up OCRunner so expect to see its own page soon.

I'm also listening all my blog posts that might be of interest to developers, so you don't need to sift through all the other stuff on the blog. And last but not least there is a collection of smaller projects I've open sourced. These deal with installing from disk images, handling betas, token clouds and more.

I'll be adding more to this site as I find other parts of my apps that would be good to open source, so it will hopefully grow quite large. In the mean time, enjoy what I've put up today and let me know what you think!

The main new areas are a brand new source list, an activity viewer, the ability to add, modify and delete projects and a tag cloud when adding tickets. There are various other smaller improvements that are detailed in the read me file in the download, which is available from here

One of the most annoying parts of software is testing. It takes forever and is boring and repetitive. And worse of all, you often miss stuff, often stuff that is hard to track down. One way to make part of this easier is to use unit tests.

There are two extremes to the argument over whether you should write unit tests:

- "You should write tests for absolutely every single method and/or function in your code"

- "Unit tests are boring, a waste of coding time and don't test everything anyway so don't write any"

As with anything, the truth is often found in the middle ground. Some of the 2nd quote is true: unit tests ARE boring (at least for most devs) and they don't test everything. However, they may not be a waste of coding time if used properly as they can save you a huge amount of testing and debugging time.

The 1st quote is also completely true in some cases. If you are writing software for planes, nuclear power stations, rockets etc I would expect you to be writing unit tests for everything (as well as various other sorts of tests). If something goes wrong in these situations due to a program error it potentially lead to the loss of human life.

Unit Tests in Lighthouse Keeper

But let's assume you aren't writing software that could potentially kill someone. Do you need to cover every part of your code with unit tests? No. In Lighthouse Keeper I just have tests for the backend that works with the Lighthouse API. There are two reasons for this:

1. In an MVC app, the model layer is the easiest layer to tests as it should work completely in isolation from the rest of the application.

2. This is where most of the complex code that is.

Your time is precious so you want to get the biggest benefit from the time you spend writing tests. As such you should target the parts of your code that are most likely to gain bugs, especially ones that may not be immediately noticeable in normal use.

In the backend of Lighthouse Keeper I have a lot of code that parses data, or filters content based on certain logic. These can easily be broken by accident while I'm working on something else. These are ideal candidates for writing unit tests. But the objects that simply store data don't have any tests related to them at all as they only have simple accessor methods. These methods are unlikely to gain bugs and if they do they'll be pretty easy to detect and fix.

Future Unit Testing

While this is where my unit testing is now, I'm wanting to expand it further. While there is a lot of complex code in my model classes, there is also some easily breakable code in other layers of my code. Unfortunately this is much harder to test.

One of the big problems is designing for testing. Some parts of this are sensible and result in better, cleaner code. But I've found some parts actually lead to more code as you're building to make things easy to tests, not to make things simple for you. Model classes are very often designed well for testing by their nature, with controllers you have to put more effort in.

One thing I won't be heading towards is Test Driven Development. This is where you write your tests first and then code later. To me I find that a far too rigid form of development. It requires a lot of thought and planning before you start coding which goes against the way that I work, which involves a lot of chopping and changing. It leads to a more haphazard way of developing but I feel it helps me find the best solutions to problems. Ironically, while this form of development isn't ideal for doing Test Driven Development, it is ideal for automated tests such as unit tests as they help prevent me breaking stuff I know works.

OCRunner

One of the big problems with unit testing in Cocoa is that the tools are very weak. Xcode uses the same UI for unit tests failures as for compiler errors and warnings. It also requires you to go into the raw build log to see individual test details, multi-line errors, timings and other information.

To solve this I spent a few days coding up a replacement UI and this resulted in OCRunner. It's far from complete but it's already very useful for getting more information about your unit tests than Xcode provides in its UI. And best of all, it's released under the MIT licence so you can play around with it yourself. The source is available on Launchpad.

Unfortunately other commitments (aka my degree) has prevented me from working on it for a while, but when I next have some time I'm hoping to add some more features and polish and get a built version online for people to download. If you have any feature requests of find any bugs, then be sure to file them in the bug tracker.

MacDev is being organised by Steve Scott and Tim Isted from the Mac Developer Network and is a Mac developer conference based in the UK being held on the 16th-17th of April. It has a brilliant line up, including Fraser Spiers, Bill Dudney, Matt Gemmell, Mike Lee and many more, covering areas as diverse as UI design, CoreAnimation, F-Script, CoreData, Performance and Application Security.

On top of this there will be a live recording of the Mac Developer Roundtable podcast (which is a great podcast which I recommend all developers should listen to) as well as a conference dinner. All this starts at £399 (+ VAT) for the 2 day conference and includes your meals and accommodation. Don't forget, you're getting, lunch and dinner the Thursday and breakfast and lunch the Friday as well as overnight accommodation. With all this included the price is a bargain, but is only this cheap until the end of January, after which it goes up to £499 (+ VAT).

And if the conference alone isn't enough, there is also a set of workshops on the Wednesday and include UI design with Mike Lee, Core Data with Marcus Zarra and iPhone Development with Bill Dudney. These guys literally wrote the books on these subjects. These workshops cost just £185 (+VAT) for the workshop, lunch, dinner and Wednesday night accommodation.

I strongly urge any and all Mac devs in Europe to sign up for this. It will truly be a great event and provide a brilliant opportunity for Mac devs on this side of the pond to get together in big numbers. And if that isn't a good enough reason to go, I'll be there! So go book now and get your early booking discount.

Code Collector Pro's 2009

Code Collector Pro 1.3.2 will be the first update to be released this year and I'm hoping to have it out in about 2 weeks. For the most part it's just a collection of bug fixes, but it will be a significant release as it will feature a brand new icon.

The next major release of CCP will be version 1.4. Unfortunately this won't appear until much later this year (possibly around summer). I won't get into what it will involve in too much detail as it could change, but the aim will be to make moving your snippets around a lot easier. It will also coincide with a major update to codecollector.net which has unfortunately been languishing a bit as other projects have got in the way.

I will hopefully be finishing the year off with version 1.5 which I'm hoping to use to build in a lot of scriptability support and also prepare for version 2.0.

Lighthouse Keeper's 2009

Lighthouse Keeper 1.1 will be the first major update to an app this year. It will focus on providing better feedback to what LHK is doing, improving tag support and adding support for adding, editing and deleting projects. I'm hoping to have this finished before the end of January so keep an eye out for update notifications.

I am also hoping to get version 1.2 and 1.3 out this year. I haven't yet set a timeframe for these versions, nor finalised what they will contain, but their aim will be to provide more power that is only possible in a desktop app to make using Lighthouse even easier.

Time permitting there may also be a version of Lighthouse Keeper released for the iPhone this year. It's still in the very early planning stages and is very much a side project at this point but I would like to try and get it out by the end of the year.

Minim's 2009

Minim has been feeling a bit neglected for quite a while. 2009 will change that with the release of version 2.0. Minim 1.x has always been a bit of a mish mash of various technologies with no real focus to the application. Minim 2.0 will almost be a brand new application, built with all the latest technologies and all of the experience I've gained over the past few years to make it into what it should be: the best tool for musicians to organise their songs and ideas.

Minim 2.0 will feature a completely redesigned interface to make organising and managing your songs much easier. It will also have many new features to help you get ideas down. The idea bin will be a place where you can store bits of ideas that aren't yet complete but could be useful in the future. These could be interesting melodies, lyrical ideas, chord progressions etc. To add to this, Minim will feature a quick record feature that will let you start recording audio into Minim with the click of a button, which is great for those times when you get an idea into your head you don't want to lose.

I'm also wanting to get Minim 2.1 out this year. I haven't finalised what it will contain but it will feature integration with a new application I'm writing this year....

Project X's 2009

2009 will feature M Cubed's 4th application. I'm going to refer to it as Project X for now as the name isn't quite finalised yet. There will be much more information coming out over the coming months about what it is, but it will be of interest to the following groups of people:

• Authors
• Bloggers
• Directors
• Music Producers
• Composers
• Presenters
• Musicians
• Designers
• Developers
• Theatre Producers

... and basically anyone doing anything vaguely creative. I'm hoping to have 1.0 out by summer and a private beta out by sometime this spring so keep an eye out.