Last night, I released Lab Tick 0.9.3 which fixes a number of small bugs. The biggest change in this release is support for fast user switching. In previous versions of Lab Tick, you either had to disable or quite Lab Tick before you would switch to a different account on your notebook - otherwise, Lab Tick would continue to run and try to control the illumination. This caused erratic behaviour when another instance of Lab Tick was running under a different account.
Also, since Xcode 3.2 in Snow Leopard comes with a static analyzer built-in, I could find a number of small memory leaks, which should hopefully reduce memory usage by a bit.
However, even though Lab Tick 0.9.3 runs perfectly fine on Snow Leopard, it won't run in 64 bit. That is because some of the APIs I use to control the backlit keyboard are not fully 64-bit-capable and have been deprecated by Apple. I will look into replacing those APIs with modern ones that have 64 bit support. Since spare time is always an issue, I cannot make any promises on a release date.
Until then, I hope the lack of support for 64 bit doesn't bother you too much.
Recently, I've founded a CocoaHeads chapter for the city of Bremen. We've had a lot of initial interest in our meetings and have managed about 15 people coming to each of the meetings. For our second meeting, I organized a small challenge for which I gave away a coupon code to receive the first three NSConference 2009 videos for free (Thanks, Scotty!). This challenge was well received and got me thinking about organizing something bigger and better, much like what Ironcoder used to be, but just for our local CocoaHeads chapter.
I've started asking around on Twitter (I'm @arepty, by the way) for software vendors to donate licenses, and with the Mac developer community being as fantastic as always, I received pledges for software licenses worth over 500 € within a couple of days. To top this off, falkemedia has thrown three one-year subscriptions of their magazine Mac Life into the mix, so the winners of the upcoming competition have quite a lot of stuff to look forward to.
The competition details (theme and API) will be announced at our meeting next Thursday, August 13th 2009. Please note that this being strictly a competition for the Bremen chapter of CocoaHeads, you will only be eligible to enter if you have participated in one of our local meetings in the past or will participate on Thursday. Participants will have about three weeks to build an app (Mac or iPhone) with the theme and API that I will choose for them. After the deadline, I will judge the apps and announce winners at the September meeting of our chapter.
You're probably interested to learn what kind of software was pledged as prizes for the competition, so here's the complete list:
RapidWeaver (5 licenses)
LittleSnapper (5 licenses)
Changes (2 licenses)
Lighthouse Keeper (1 license)
Code Collector Pro (1 license)
Versions (3 licenses)
CoverSutra (3 licenses)
Decloner (5 licenses)
Posterino (5 licenses)
Mental Case (1 license)
TimeBoxed (5 licenses)
Mac Life magazine (3 one-year subscriptions)
In my opinion, that is one fantastic line-up of prizes - especially for developers. They will be distributed as follows among the best-ranking participants:
First prize: RapidWeaver, LittleSnapper, Lighthouse Keeper, Code Collector Pro, Decloner, Posterino, Versions, TimeBoxed, CoverSutra, Changes, Mental Case, Mac Life subscription Second prize: RapidWeaver, LittleSnapper, Decloner, Posterino, Versions, TimeBoxed, CoverSutra, Changes, Mac Life subscription Third prize: RapidWeaver, LittleSnapper, Decloner, Posterino, Versions, TimeBoxed, CoverSutra, Mac Life subscription Fourth and fifth prize: RapidWeaver, LittleSnapper, Decloner, Posterino, TimeBoxed
Including the Mac Life subscriptions, the amount of all the prizes comes to over 1,000 €. I'd like to thank all of the sponsors for their generous offers and hope that all those who attend next week's meeting are going to enjoy the competition. I'm looking forward to seeing what you guys will come up with.
Fortunately, I arrived on Wednesday already, so I could participate in the big get-together at the bar that night. A lot of people who arrived early, too, had a great time getting to know each other, drinking beer and cider and generally talking about Mac development related stuff. Getting to know a bunch of people who I just knew from Twitter made this evening a blast.
Obviously, a night such as that one had its drawbacks - namely, alcohol consumption. Too much of it for a clear head on Thursday morning, anyway. About three cups of coffee, a great breakfast, two paracetamol and a Red Bull later, I was back on my feet and excited about the sessions that the day would offer. And I should not be disappointed. All the speakers knew their stuff really well and presented us with great material and inspiration to start working on something that would utlize our new-found knowledge. Especially Philippe Mougin seemed to have hit a nail with his talk about F-Script, as everyone seemed to be eager to use it right away and find out more about their and Apple's applications.
Thursday night saw the NSConference banquet taking place, which was a great dinner along with the chance to meet even more fellow developers and have some great conversations. Also, even more beer and cider, although I managed to drink in moderation and avoid taking even more medication the next morning.
After four more great sessions and a somewhat decent lunch, we got to be witnesses of the first ever Cocoa Faceoff, which pitted the speakers from America against those from Europe with each team joined by two delegates. Both teams had 30 minutes to design a Cocoa application, along with an iPhone version for conference organisers. By the end of the time, the teams should present their idea to the audience which would judge these applications. Scotty made promises of glory for the winning team and shame for the losers - while seeming completely impartial (*cough*).
Tim and Scotty would grab each speaker out of their group for a few minutes, so that they could provide a quick tip to the remaining delegates. This proved to be a lot of entertainment, although it resulted in Xcode being unusable at some point and almost got the Mac Pro destroyed.
Both teams presented their application ideas to the cheers of the audience, and Europe took the win, with a barely noticeable higher noise level than the American team achieved.
With this, the first ever UK Mac developer conference came to a close, and all of us could go home and look back on a few days full of great talks, informative conversations and a lot of fun. I couldn't find one person who didn't enjoy the conference or didn't think they walked away with some very valuable knowledge.
All that said, I'm looking forward to NSConference 2.0 next year.
In the past few weeks, I have spent quite some time working on an iPhone application for a client. It is a port of a J2ME project, and a rather big one at that. Since I've only been working on some parts of the application, I wasn't really interested in using my time to fix all the compile warnings that I encountered and tried to concentrate only on the features that I had to add.
From time to time the application would crash with error messages such as this one:
2009-01-29 13:32:56.306 Debugging[28349:20b] -[NSCFString doSomething]: unrecognized selector sent to instance 0x3030
2009-01-29 13:32:56.307 Debugging[28349:20b] Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFString doSomething]: unrecognized selector sent to instance 0x3030'
It is usually rather difficult to trace the origin of this exception using the debugger. You can of course try to search your code for the name of the selector in question, or you can look through your compiler warnings. In a fairly large project, however, the right spot in your code may not be easy to find. Read More
In the past two years, Lab Tick has matured from a relatively simple slider in a window to a complex application with a bunch of user-configurable preferences and nice features.
The following screen shots will give you an idea of what Lab Tick used to look like in the past. The first image shows version 0.2, one of the very first releases. In version 0.4, I started using a preferences window for some of the very first basic user-configurable behaviour.
Thanks to Sam, I can finally confirm that Lab Tick works on Apple's new MacBooks.
Also, and this doesn't warrant an extra post, for those of you who donated to Lab Tick in the past (Thank you!), I'll introduce a button that will allow you to get rid of the nag screen once and for all. It'll be in the next update.
Unfortunately, I did not do enough pre-release testing of Lab Tick 0.9 before I released it on Monday. There were some glitches which were affecting Tiger users. None of these glitches caused the application to hang or not function properly, but they weren't exactly nice to look at. Read More
I'll bet this is a new one:
I've been using Lab Tick about a week now. Last Monday I left the surgical suite (operating room) for my office. The Xray view box was very bright obscuring everything including my MacBook Pro I got a video ichat from the Surgeon I just left. He asked me a question that needed an immediate answer. Because the Lab Tick'd keyboard was lit up the surgeon got the information he needed. And the wasted time to turn on the keyboard back light wasn't.
So as far as I'm concerned Lab Tick saved someone's life.
Bremen-based chocolate manufacturers Hachez have recently launched a new line-up of their exquisite high-percentage cocoa chocolate (and you thought this post was about programming), named "Wild Cocoa" (link is in German). Here's how it looks:
Since Hachez chocolate can be safely considered to be among the top chocolates in the world and they're based in the city where I live, I thought it would be fitting if I as a Cocoa developer gave their new lineup a try.
I went to their cozy little downtown store and purchased a 100g bar of each of the flavours (45% cocoa and 70% cocoa, respectively) which cost me exactly € 6.00 - a price I'll gladly pay for great chocolate.
I tried the 45% one first and was a little disappointed by the whole milk chocolate taste. It didn't taste bad at all, but whole milk chocolate just isn't my cup of tea.
The 70% one, however, had a lot more intense cocoa flavour and matched my taste very well. Only my superior self-control and the promise of a hot meal in due time kept me from devouring it in its entirety right there, on the spot. It was mostly the self-control, really. I'd never lie to you.
All in all, the new brand is a welcome addition to Hachez' chocolate lineup. I still maintain that the name "Wild Cocoa" could have made a great Cocoa-related blog or something.