Via Michael Tsai: Predictably, someone looked into how Leopard’s Dock manages to keep iCal’s icon up-to-date so that it always shows the current date – even when iCal itself is not running.

It turns out this is not an iCal-specific hack, but rather an undocumented (und thus potentially volatile; developers should not depend on it) new capability known as a DockExtra. An application simply specifies a path to a bundle in a key named DockExtra. The bundle, then, needs to implement certain functions to decide when to redraw the icon, and to actually handle the drawing. Finally, SystemUIServer loads the bundle and constantly keeps it in memory.

Perhaps Apple will one day make this a public API. CocoaDev wiki entry, anyone?

“DockExtras” were discussed all the way back in 2001, but those are probably Docklings instead, which haven’t been used much at all in half an eternity; pretty much ever since 10.1 introduced Menu Extras. (Does the current Dock even permit them any more?) Also of note: someone else figured all this out about a week earlier.

(And why can’t Jeff Atwood use Unicode? )

Via reddit comes some excellent insight into the failings of programmer job interviews. The “Fizz-Buzz example” had me intrigued enough to try and see how good I could get it working in two languages; in particular, Ruby and PHP. As MarkByers points out, there’s actually an online page where you can submit your implementation in a large number of languages, have it automatically compiled and tested against the spec, and see how you match up against others in efficiency.

Surprisingly enough, a sizeable number of comments fail to follow the spec properly. Several get the line breaks wrong, which perhaps would be forgivable, but a few even gloss over the “prints the numbers” part entirely. As far as I’m concerned, that’s what the test is really about: not about how fast, how elegantly, how efficiently or in how many languages you can write an implementation, but whether you’re actually capable of understanding the original problem specification, and solving the test accordingly.

Not unexpectedly, a number of posters find that obscuring their code somehow makes it better. This isn’t an unusual perception, but it is one I’ve never understood. Using language-specific capabilities is generally a good idea, of course, but if it takes you longer to think about (and therefore, ultimately, longer to write), it’s going to take others even longer to read. If you’re writing code only for yourself, that may be alright, but that’s hardly ever the case. Consider that, one day, you might not even be at the company any more to explain your code to others, or you might simply have forgotten.

I personally feel that a small performance penalty is actually acceptable if it means far more readable code, which is frequently the case. Performance can be improved with newer machines, whereas you are unlikely to find people who are more capable at reading code. I.e., the former scales; the latter does not. (Of course, there is such a thing as performance-critical code, but unless you’re specifically asked to write that, I don’t believe you should attempt to.)

Another reddit user, danweber points to “The Five Essential Phone-Screen Questions”, which is actually a decent enough way to double-check your own skills; if you can’t answer all those functions well enough, you should probably get some practice before you start looking for a job.

As many have mentioned, nervousness plays a role; while interviewing, you can’t expect the applicant to be full of excellent ideas in solving your problems: in most cases, there is a lot anxiety.

Regarding the assertion that “The majority of comp sci graduates can’t [answer the FizzBuzz test]“, though, I’d like to point out this: a lot of people study computer science in order to become programmers, and a lot of companies target people with a computer science degree as prospective programmers to hire. A CS professor, however, would actually disagree that CS is intended for this; the course is intended to be far more theoretical than this. Research about how to move programming forward, as opposed to learning how to learn any particular (and thoroughly-developed) programming languages and paradigms of today.

In other words, an interviewer shouldn’t be surprised when a fresh CS graduate has little actual programming experience – unless they have been hacking away in private for years (which, mind you, is frequently the case), they simply won’t. Certainly, a CS degree-holding applicant is far more likely to have a deep understanding of the intricate workings of programming; they are more likely to abstract programming to the point where languages differ mainly in their syntax, and they can therefore typically adjust to new languages, frameworks and paradigms far more easily. However, all of that is of little user to a manager in the here and now; they need someone to solve a concrete problem. I believe that interviewers would be far better served looking for applicants not by their degree, but by their ability to solve things such as “The Five Essential Phone-Screen Questions”. A degree is an excellent bonus, but hardly an accurate measure of the person’s expertise at software development.

In general, if you have the time, I would recommend you read through all the comments at Atwood’s entry, as well as the ones over at reddit.

With Cyan still not having fixed the infamous KI image bug, I have decided to wrap up development of KIImageFixer. I had previously talked about the Windows version as well as the “port” to Mac OS X.

As Kestr’l mentions in a comment, my original instructions for KIImageFixer are gone; I don’t even have a copy. The Uru Live Forums’ moderators tendency to just take away entire forums forum public view, taking all threads and posts with them, baffles me, but I’ve been trying not to care about that mess over there any more. Suffice to say I don’t have a copy of my original post, as I didn’t expect it to be washed away for no legitimate reason at all. (Yes, I might be able to ask them to give it back. I just don’t care to. This shouldn’t be an issue to begin with; there’s no reason at all they can’t at least provide a read-only archive of the old threads. We’re talking about posts from mere weeks ago. Even a transitional phase would have helped; make the forums read-only so people stop posting in them and get used to the ‘newer’ ones, then hide them altogether. But I digress.)

I already have a code repository for various MYSTlore stuff at Google Code, so this was very fitting to add. You can find links to the latest versions of KIImageFixer 1.0 for both Mac OS X and Windows on the project main page, or of course the Downloads section. As anything in that repository, this stuff is MIT-licensed, so if you wish to use any of this code, be my guest. You’re also welcome to use the issue tracker to make suggestions or point out problems, or ask questions. Or you could comment here. I’ll see it either way.

As with any noteworthy development work I do, there as a lesson to learn. This time: the compressed embedded PNG icon format Windows Vista uses for its 256×256 icons may be nice, but is virtually useless for the time being. While Explorer in Windows XP just ignores the larger size and happily displays the 48×48 variant (and, with a modification, the 128×128 one), Visual Studio is not so graceful. Rather, it completely refuses to compile the result into a resource file when preparing the build the binary. You have to disable compression, at which point the icon file size blows up from bad to worse; I think it was something like 340 vs 199 kiloBytes. Then that is wrapped into the resource file, which takes up another 200 kBs, and finally the result ends up in the executable, which then totals over 700 kBs. All for the sake of having higher icon quality, which now that Vista is released becomes increasingly relevant. I would appreciate if Microsoft could fix up Visual Studio (I’m using the 2005 Express Edition, if it matters at all) so it can accept and ignore the compression, saving some space, but I’m not counting on it.

Mind you, the situation isn’t perfect either on Mac OS X, but certainly better. 10.4 Tiger was supposed to bump things up to 256×256, which as I understand it didn’t make the cut; 10.5 Leopard goes all the way to 512×512, and its version of Icon Composer fittingly adds a new size. I don’t know about compression (but, judging from the file sizes I’ve seen, it automatically seems to be enabled), but I’m fairly sure 10.4 isn’t able to handle the additional size; if you do any editing, it probably drops it. If you merely build the project, however, it probably just leaves it in. I’m saying ‘probably’ because I haven’t actually tested this, but I can’t think of any reason why not, since it merely copies the icon file into the bundle, rather than converting it into a resource, then embedding it into the application.

Now, if Cyan could fix that bug so this app becomes obsolete…

Jesper writes about 10.5 Leopard’s Cocoa bridges for Ruby and Python, and why they’re more useful than .NET’s similar support for many languages. In a nutshell, whereas in .NET, everything ultimately compiles to CIL, thus taking away any performance benefits one particular language may have had, Cocoa leaves your code in the very language it’s been written; there is no bytecode. In addition, while .NET’s CIL requirement ultimately means that all .NET languages try to be as C#-like in their features as possible, Cocoa languages such as Ruby can play out their own particular strengths.

I for one am still not sold, however, that Apple is giving up on the bytecode concept completely, especially with regard to Apple’s mysterious LLVM involvement. I can’t wait to hear more gossip on that one.

Uru Live’s weird (and, puzzlingly enough, still unfixed) JPEG bug prompted me to create a GUI application to let average users work around it, by running their Uru Live-created images through a process that would remove the corrupted data.

Images output by Uru Live have their first four bytes filled with the file’s size, or rather what it would be if it weren’t for those four additional bytes. Only then does the JPEG header begin, and soon after the related data. I call it a bug because, while one support contact has described it as “the intended behaviour”, this conflicts not only with common sense, but also with the account of other employees.

For someone who knows their way around hex editors, this is trivial to fix, but not very convenient. For anyone else, it’s so hard they’ll simply give up. A GUI app certainly helps.

So in December, I released a small Windows tool that did just that. It lets you select JPEG images, looks whether their header is a JPEG one, and if not, strips off the first four bytes under the assumption that that will fix things. This will break awfully if you try and run it on non-JPEG images, let alone other kinds of files, but it not only provides a backup option (which is on by default), but also warns the user of this problem.

I had written that app in C# and .NET using Visual Studio 2005 Express, which wasn’t my first experience with the IDE, the framework or the language, but the first time I spent enough time in all of them to actually ship something.

Seeing as a Mac version of Uru Live will come up, and will likely have the same bug (though one would home they’d have it fixed by then, but I doubt it), I decided to port the app to Mac OS X (with Objective-C, Cocoa and Xcode), where “port” isn’t quite the right word. I took a brief glimpse at how the Windows code works just to recall the basics, but then proceeded to implement virtually everything from scratch.

You can see the source code for both versions over at Google Code’s MYSTlore project, though I wish Google Code would offer a more suitable source browser.

That’s that. Ideally, of course, the actual processing could would be written separately in backend code shared by the two frontends. Since C# and Objective-C are both, in a way, related to C, it would make sense to write this part in C itself. For such a tiny project, it isn’t really worth it, though, and in general, I lack the expertise and inclination to write C code.