tonyarnold.com

Internet Explorer does not support modern web standards

Sun, 13 Jul 2008 21:59:00 GMT

Found here: http://www.apple.com/mobileme/migrating/

Finally, someone has the balls to out and out say it in a professional context. IE 7 does not support modern web standards.

Nice.

Convenience #DEFINEs

Sat, 05 Jul 2008 03:00:00 GMT

Update: Lazy programmer, indeed! After doing some research myself this afternoon (at the prompting of Karsten), I’d recommend not using anything but the ZNCGAutoRelease() method below - the others aren’t dangerous, but they’re really not necessary and just obscure your ability to properly debug your code. As for using macros, well, I guess that’s a matter of personal preference - what I’ve seen so far is that it does make debugging harder - you’re probably better off implementing proper methods for repeatable tasks. But it works if you want to use it.

When I first started working on VirtueDesktops (all those years ago), I was still new to Objective-C and very new to the concept of (mostly) manual memory management. Thankfully Thomas had the foresight to do what all good, lazy programmers should do and write himself a few small convenience methods into his codebase.

They’ve had a couple of minor additions and changes since then, but line-for-line, they’ve stood the test of time and I find them an invaluable way to reduce some of the fuss involved in manually managing your object assignments, copies and releases.

#define ZNCGAutoRelease(x) (__typeof(x))[NSMakeCollectable(x) autorelease]

#define ZNAssign(aTarget, aSource)  \
if (aTarget != nil) {               \
    [aTarget autorelease];          \
}                                   \
aTarget = [aSource retain];

#define ZNAssignCopy(aTarget, aSource)  \
if (aTarget != nil) {                   \
    [aTarget autorelease];              \
}                                       \
aTarget = [aSource copy];

#define ZNRelease(aTarget)          \
if (aTarget != nil) {               \
    id oldObject = aTarget;     \
    aTarget = nil;                  \
    [oldObject release];            \
}

I use these everywhere in my code, but just the other day I discovered the absolutely incredibly wonderful CLANG Static Analysis tools (more on this shortly!), and based on some feedback it gave around these calls (nothing bad!) it made me wonder - should I be #DEFINEing convenience methods? Is this best practice? Should I go back to doing this all by hand?

I’m hoping some of my CocoaPeers™ will be able to provide me with some advice here, but if you think the code’s good for your needs - go for your life and use it.

Oh, and happy 4th of July to our friends in the states. We’re waiting for you here on the 5th :)

Introducing the face of Hyperspaces

Thu, 05 Jun 2008 16:33:00 GMT

I’d like to introduce everyone to the greatest icon to ever grace a screen:

This gorgeous piece of design was put together by Sebastiaan De With of Cocoia.com and IconDesigner.net fame. He was an absolute pleasure to work with, and I’ve heard nothing but praise for him from my peers. He’s also got a blog post up his sleeve about the process we went through together to end up with what you see above.

Oh, and the promo site for Hyperspaces is up: http://hyperspacesapp.com/

On how primary function becomes secondary

Wed, 04 Jun 2008 15:35:00 GMT

Over the last month, I’ve been slowly expanding my list of testers who are helping me with Hyperspaces. Initially, most of the testers viewed Hyperspaces as a novelty (which it is), but didn’t leave it running. They’d test whether a new build worked, and then go back to what they were doing. It was an interesting thing to watch: I’d poured months and months of my time into making the visual space switcher function properly, and nobody was really using it.

Does it show a near real-time overview of what’s happening on all of your spaces? Check.
Does it use nearly no CPU? Check.
Does it look good? myyeeeeah - it’s not terrible.

Initially, I didn’t pay much attention to what was happening here, and just plowed through adding in some of what I considered to be secondary features. This included the ability to set a different desktop image, a tinted colour overlay and text labels on each of your spaces.

It turns out I was seriously off-base with what people actually miss from VirtueDesktops and it’s ilk. The big ticket item that seems to be missing from Apple’s implementation with Spaces is context: Which space am I currently working in?

Anyhow, those are just my observations - don’t assume that you know what’s important based solely upon your own experience and ideas. In my case, this wasn’t time lost or wasted - the technical work involved in gathering information about how Spaces works is used just about everywhere in Hyperspaces, and once I’ve released the app, I’ll share a lot of what I’ve learned so that others can benefit from that research.

Now before Neil has a go at me for not releasing a public beta before WWDC - because apparently he’s not too keen on attending with a “has been” - I am serious about getting Hyperspaces into your hands as soon as I can, but I’m not going to release something that is almost good enough. I’m almost there, and you can help me - I’m about to build the final visuals for the switcher, and I’d appreciate some feedback.

Here’s how it looks in 1.0 alpha build 404 (heh - yes, I see it too):

It functions much as you’d expect - you click on a space to switch to it. The active space shows a live-updating image of your current space, and the others show ghosted representations of your windows. Everything is drawn using CoreAnimation, so transitions of window positions smoothly fade in and out as window positions change on other spaces.

Here are my rough ideas mocked up using Fireworks for where this is could head:

The QuickSilver concept

The first is a QuickSilver-style window that would include other functionality and configuration options:

The HUD concept

The second (and my current front-runner with a bit more polish) is this black, hud-like window. It also reflects some of the design elements of Hyperspaces very, very unique icon which I’ll be introducing before the week is out.

Leave your thoughts in the comments.

How late I am…

Sun, 11 May 2008 03:20:00 GMT

This just demonstrates how much your planning ends up meaning when you have a full-time job in addition to developing an application. I started earnestly developing Hyperspaces just under 6 months ago now (17th December, 2007 is the date of the first subversion commit). I’d been toying with the idea of a version of VirtueDesktops that wasn’t an insane hack, but instead worked with Apple’s implementation of virtual desktops for a few months prior. Until that week, I wasn’t sure it would be possible to gather enough information or interact with Spaces in a way that would even let me achieve what I wanted to.

Is the development vs. full-time job dilemma common among other small developers? Long term, I’d love to be able to develop great mac applications full-time, but it seems to be a catch-22 situation.

These are the voyages of the USS Hyperspaces…

Sat, 10 May 2008 06:20:00 GMT

Double-click to play.

Hyperspaces is feature-complete, I’m just working on the user interface controls to configure the desktop elements you can see in the video. ~~I have a few more bugs to fix, a web site to construct and a tiny bit of documentation to write, and then (finally) I’ll be releasing a public beta~~. Yes, I know what I said - I’m taking it back. I want Hyperspaces to be as polished as CoverStream, and right now it’s not. But it will be - and it will be soon, but whereas 24 hours ago soon meant “Monday”, now it means “before WWDC08”. Flame on.

Oh, and if I haven’t said it enough alread - Core Animation is seriously the poo. If you’re not using it in your apps, you should be. Watch the video and tell me you don’t want implicit animation.

Integrated documentation for Xcode projects: a project proposal

Fri, 28 Mar 2008 04:05:00 GMT

I’ve been thinking for the past week or so about how I can contribute something back to the mac development community - a lot of good people spend a lot of time helping me out with my issues as they come up, and I believe improving our toolchain is probably the best way for me to contribute. Documentation, to be specific.

If we take the time to properly document and comment our source code, we’re unlikely to want to have to re-document that into a human readable format such as HTML or PDF, right? I’ve previously used tools such as HeaderDoc and NaturalDocs depending on the language and framework I’m coding in to achieve this end – with wildly varying results. HeaderDoc’s default output is quite ugly, and has some glaring omissions in terms of it’s parsing of some of the newer documentation tags.

So I’m thinking about starting up a Google Code project around this, and I’m just trying to get a feel for what people think about this idea, what they would use, and how they would see this working. So far I’ve solicited a little feedback and the following are things I know I’d like to see:

Xcode build integration: the generation of this documentation should work as part of the Xcode build process. No messing around with external tools;
Comment formats should use what’s already out there: Lots of our code is already documented using HeaderDoc’s comment format - we should try to expand upon that if we need to - not replace it (but I’m open to suggestion here);
The generated output should look good. No arguments there.

Comments ahoy, my peers!

Aluminium MacBooks can’t jump

Sat, 08 Mar 2008 12:36:00 GMT

I know a few of you are anxiously awaiting a public release of Hyperspaces. Unfortunately, there’s not going to be a public release for a few weeks yet. I know - I said early March, but my MacBook Pro tried to master the finer points of flying a few weeks ago, and it’s interesting how badly those shiny silver beasts stand up to a small drop. I’ve just got my replacement this past week, and I’ve only just got all my development tools and settings right back where I want them.

Oh, and I’ve also been cleaning up and painting our kitchen - but that’s another story with photos to come. In any case, the Hyperspaces icon is done (and I’ll be showing it off shortly!), the feature set is being locked down, and my list of pre-beta tasks is down to 14 items - some of them quite small, some of them larger (“Watch for fsevent changes to the Dock’s plist file to trigger changes in the enabled state of Spaces” for instance). Almost there people - I hope you guys love it as much as I hope you will! I’ll post when there’s more, but I’m hoping to put up a feature preview on http://hyperspacesapp.com in the next week - I just need to get some of the finer points of the user interface locked down!

Booyah! Microsoft finally gets it: web standards for all

Tue, 04 Mar 2008 08:17:00 GMT

http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx

This is the best news I’ve heard for a long time. Now we can all enjoy proper standards support, no matter what browser we choose to use. Is this a new era for Microsoft?

Releasing a public beta of your application: my thoughts

Sat, 01 Mar 2008 13:57:00 GMT

With the Hyperspaces public beta coming quite soon, I’ve been thinking about how to release beta software, and when it’s appropriate to do so.

My previous piece of software - VirtueDesktops - had eternal beta syndrome (EBS). Hell, while I was running the project I’m not even sure I’d have called it a beta knowing what I do now. This was a huge fucking mistake. And it showed. Users got awfully upset, and the only reason I got away with it was because I didn’t charge anything for the software.

1. Release your beta when you have weeks left until release - not months

How often do you download a great new piece of software that’s in beta, and then spend the next 6 months waiting for it to become stable enough for daily use? Seriously, if you couldn’t realistically release a bug-free version of your software within 4 weeks of putting out your public beta - hold off and get your software to a point where you can!

2. Protect your reputation above all else

I believe the most important thing I have as a developer is my reputation. Skills, languages and patterns can be learnt - reputation is something that has to be earned, and is really hard to rebuild if you damage it. In my experience buggy releases or a constantly “in-beta” product are two of the fastest ways to cripple your reputation.

3. If something goes wrong - make sure the user can let you know as easily as possible

This applies regardless of the release status of your application - if something goes wrong, the user will only let you know if:

The error really pisses them off; or
It’s incredibly easy to do so

I generally believe in collecting as much information as possible and automatically posting this back to your servers - this way, you don’t need to ask the user to root about in their Library folder. If you’re going to do this, make sure you let the user know exactly what’s happening!. When I was coding VirtueDesktops, I used Unsanity’s Smart Crash Reporter - and was quite happy with it. I’m still not sure what I’ll use for Hyperspaces - APE is out for Leopard now, but it’s not out of beta yet.

Conclusion

Don’t release your software before it’s ready, and make sure it’s easy to report errors when they happen.