f.lux - I Like!

Staring at multiple computer monitors late into the night isn't as pleasant as it should be. I've noticed that the constant bright glare from the monitors causes a lot of fatigue. f.lux is a very simple and yet highly effective tool that has made coding so much more pleasant. I very highly recommend this to anyone who spends long hours working at a computer. Available for Mac, PC and Linux. (PS: MacBooks already have similar functionality built-in that uses the integrated camera to detect ambient light and adjust brightness accordingly).

Cocoa: What is "File's Owner" in a nib?

One of the things I had most trouble with while writing my first Cocoa application was understanding what a File's Owner in a nib file was and what role it fulfilled.

Apple's documentation seems to imply that understanding File's Owner is important (it is) but doesn't really do a good job of explaining the concept. And I'm not alone - this email thread contains a pretty good summary of what Apple's documentation says and the confusion it might create. That same thread has several peoples' attempts to explain what it is. I really didn't get too much from those explanations and ended up explaining it to myself by piecing together data from a few experiments. Now that I think I understand what it's for, I figured I should try and put my take out there as well in case it ends up helping someone else in the future.

The File's Owner of your primary nib file is, by default, the NSApplication class and this comes ready-made for you when you create your Cocoa application. If your application has just the one nib file, you really don't need to worry about File's Owner. But if that's true, your application is probably really trivial or not well written.

Generally, each new window/sheet your application creates should be contained in it's own nib for faster loading of your app and smaller runtime footprint. When adding a nib to your application in XCode, you'll noticed that the File's Owner is set to NSObject by default (select the File's Owner object in the nib and launch Tools -> Identity Inspector). I recommend setting this to a derived type for two reasons:

1. So that you're forced to think about who the File's Owner of the nib is.
2. So that you don't make a silly error while defining the owner of the nib - everything is an NSObject, after all.

A nib file is loaded dynamically at runtime usually in response to some user action (clicking a button, selecting a menu option, etc). Loading the nib is done, usually, using the NSDocumentController or the NSWindowController classes. Just because these classes help load the nib doesn't mean they must 'own' the nib. The File's Owner of the nib is the object that makes communication possible between this new nib and other parts of the application. Let's explore this further.

The document/window loaded in the nib can have one of the following purposes:

1. an informative view that isn't interactive (About box, for example)
   
2. get some more user input to feed into other parts of the application
   

#1 is the simple case - by my definition, since there is no communication to be enabled, the File's Owner for this nib is not important. But based on my previous recommendation of not using NSObject as the File's Owner, what class should be set as the File's Owner? The object (NSDocumentController/NSWindowController) which loaded the nib can be made owner of the nib, and the nib loaded using the method overload that doesn't need an owner specified.

#2 is the interesting case - if this is a form that takes in some user input it is required that this information be communicated back to another part of the application. But no one on the outside really has access to controls in this form. No one, except the File's Owner. In this case, the File's Owner should be an instance of a class that you've previously created, and the type of that instance is what you set to be the File's Owner's class in the Identity Inspector. It's important here to understand that the File's Owner isn't a 'new instance' of the class you specified. In fact, the File's Owner is set to an instance provided when the nib was loaded (see the last parameter of initWithWindowsNibName).

So your application likely had an instance of an object created previously, which is what you would pass in as the owner of the file. That instance can now expose IBOutlets linked to fields of the form, which can then be used by other parts of your application that already have a reference to this instance. This is what Apple documentation means when it refers to the File's Owner as a proxy.

Hopefully, this will help someone else who's learning to work with Cocoa and needs to get some clarity around the File's Owner.

Developing for the Mac - How does it compare?

I spent most of this week developing some Mac OS X software. Having never before written a single line of Objective-C or any Mac software, I was pretty excited. Here are a few observations of developing for the Mac compared to the Windows platform (primarily .NET) from a week's worth of writing an application using Cocoa. Of course this isn't exhaustive and only includes things I had to deal with (disclaimer - opinions subject to change as time passes):

• Overall, developer reference documentation on Apple's Developer site seems more current and easy to understand than that on MSDN. A nice touch is the reference to examples which use a particular method inline with the documentation of the method <example> (MSDN does it using inline code, so it's not too different). My favorite feature about documentation though is the logical grouping of methods and properties arranged by tasks - that makes it very easy to get stuff done. I think this is the result of being the underdog in this space.


• Mac OS X applications' uniform usability and consistent aesthetic isn't a fluke. Apple's documentation regarding recommended usage is precise down to individual visual controls and yet comprehensive as far as Human Interface Guidelines go.
  


• XCode doesn't have anything on Visual Studio. Visual Studio seems, hands down, a better integrated development environment and debugging application. VS 2008 is really pretty awesome.
  


• Cocoa is nice, but still has some catching up to do with .NET. Cocoa libraries provide just enough abstractions to get stuff done, but they don't seem to be nearly as comprehensive and well thought out as the .NET libraries are. I found myself cursing some abstractions/APIs in Cocoa for their primitiveness compared to Windows pretty often. Generics give .NET an edge that Cocoa still doesn't have. Microsoft has done a great job of handling little things, such as boxing, which make development easier than it is for Cocoa. 
  


• XCode and Interface Builder are unfortunate crutches required for Mac OS X development - I would claim that it's impossible to write any decent application without using both. This sounds great until you realize that IB, which really is a designer, does so much magic for you that you just cannot with code. Linking up IBOutlets, for instance, is something I cannot imagine can be done outside of Interface Builder and has way too much magic associated with it. As a developer I often felt at the mercy of these tools, instead of being the master of it. It's fortunate that this is not true of developing for Windows - there is a lot of helpful magic that Visual Studio builds in but it's certainly not required to develop a decent application.
  


• Overall, the Mac platform (Cocoa) seems more closed than it should be. This sounds weird, considering that it's all basically Unix and standard Unix libraries are provided or can be added relatively easily. My comment here related to how accessible and complete Cocoa/Carbon libraries are. Getting access to weird parts of the system is easier on Windows that on the Mac platform, I believe.
  


• Deploying Mac applications is a snap, better than Windows. However, I think this is related to how developers are accustomed to (ab)using resources in Windows (registry, etc). Not having a lot of Windows' 'legacy' facilities on the Mac makes developers think hard about what their app really should be doing. I claim that good developers should be able to create x-copy deployable apps even for Windows, though, so it's unfair to blame the platform here.
  


• The fact that it's built on Unix makes the mac support a lot more languages, especially scripting languages, out of the box. Windows is catching up fast though - integration of interpreted languages with .NET and PowerShell bring it at par with the Mac (I hear it might be better, but I don't have much experience).
  


• Testing on the Mac seems easier. The fact that there are a very finite set of configurations compared to the Windows platform makes life less complicated for developers. It's almost true that if it works on your Mac it's probably doing to work on most Macs (modulo a few exceptions).  History says this has traditionally been an advantage of the Windows platform, but I'm not so sure it's a good thing anymore. This one's probably the most controversial of my observations above and likely to change as I do more Mac work.
  

So, who wins? I would say Windows for the overall developer friendliness. Apple has some catching up to do in several areas. That said, the Windows platform could learn more than just a few things from what Apple seems to be doing right. 

It's a fun time to be a software developer.

A Run on the Bank of Microsoft?

Wow... did I just predict this? Yesterday, in my Problems at Facebook? post I referenced (somewhat jokingly) how I was kinda surprised that in the current economic conditions, the EU hadn't tapped into the Microsoft cash machine using some anti-trust excuse. Lo and behold, a few minutes ago Microsoft issued a press release in response to a 'Statement of Objections' it received from the EU about - you guessed it - European anti-trust law. Obviously, I had no knowledge of this when I posted yesterday - I'm just a foot soldier. The timing is a little spooky though... maybe I should muse of some good things happening. ;)

I wonder if this is the beginning of another run on the Bank of Microsoft by the EU...

Update: More coverage in the Wall Street Journal. This thing is probably going to go on for a while. Sigh!

Win 7's glowing reviews - a case of lowered expectations?

Windows 7 was publicly released as a beta last week, and has been getting some pretty glowing reviews. I haven't yet seen a single negative review - everything I've seen compares Windows 7 much favourably over Vista and in many cases even over XP. ZDNet's review is pretty typical of most reviews I've read. Even traditional Microsoft haters (who shall go un-named) seem to be reacting favorably to Windows 7. Of course there are some brand new features, but I'm more concerned with the stability and snappiness of the OS.

While a lot of the praise is well deserved and a lot of people have worked hard on making Windows 7 what it is, I can't help but wonder how much of it is a result of peoples' lowered expectations from Microsoft with regards to Windows. Vista wasn't nearly as good as it should have been when it released (SP1 seems to have fixed a lot of stability issues, though it is still a resource hog) and the generally negative buzz about Vista has probably reduced expectations to the point where anything that's not sluggish, bloated and resource hungry would've received good feedback.

Anyways, nothing wrong with good reviews... here's hoping that Windows 7 will exceed all expectations when it's publicly released.

Problems at Facebook?

I was thinking about the whole recession thing and how it impacts Microsoft. As I worked through my train of thought, I remembered the huge 899 million Euro fine that the EU slapped Microsoft with in Feb 2008. I remember thinking then that the EU was almost treating Microsoft like an ATM (probably inspired by this post).

I wondered why in this time of recession the EU hasn't yet again tapped its ATM and thought I'd update my Facebook status to say "Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM (Microsoft) again using the same anti-trust excuse...". To my surprise, I got a little popup that said "Validation Error - A validation error occured" and nothing more informative.

Interesting. What exactly is Facebook validating, and did I have some red-herring text in there? I would expect filters for expletives, racial slurs, geo-political issues... but my status message didn't seem to violate any of those. I tried the following variants, which all failed:

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM (MSFT) again using the same anti-trust excuse..."

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM again using the same anti-trust excuse..."

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM again..."

"Viraj wonders why, with this recession n all, the EU"

"wonders..."

Ok, so it's certainly not the text of my status message that's causing this. I started poking around, and my 'Home' page seemed OK - I had news items, status updates from friends, etc. However, when I jumped to my own profile, I was suprised to find that all data I had published was blank. No wall posts, no posted items, no recent history. However, my photo albums seemed to fine, as did my profile information.

My guess is there's been some kind of data loss-ish issue at FB (a lot of their data is simply held in caches so maybe a cache and replicas blew away - perhaps Wall posts are not persisted?). Anyways, I'll try to update status again and see if stuff comes back... meanwhile, I'm locked out of changing my Facebook status...

Any guesses about what might be going on?

Update: I can't seem to be able to clear my previous status message either... the status is cleared in the webpage (local javascript clearing it, I would assume) but on refresh I see my old status again...

Update2: And we're back... that didn't last too long. Cool!

Post on The Live Mesh Blog, PDC 2008

I wrote a post on the Live Mesh Blog earlier today that talks about what I primarily work on - the Pub-Sub backend of Live Mesh. I briefly referenced that I worked in this space in a previous post where I commented on Apple's Push Notification announcements.

I've written tons of design documents, specs and tech summaries on the job but writing this post was an interesting exercise - I tried to make it readable for both the geeks and the regular folks in the audience (hence the references to the postal system). I'm not sure how well this will work... I guess feedback from the blog comments will be a good indicator of how effective the attempt was.

In addition to my awesomely smart teammates on the Live Mesh team, who I enjoy working with greatly, I wanted to send a shoutout to Tom who originally helped design a lot of the stuff described in the blog post.

For those who want more details about how stuff works behind the scenes, there are some Live Mesh related deep-dive sessions scheduled at PDC 2008. Sessions related to the Live Mesh backend architecture ("Live Services: Mesh Services Architecture and Concepts" by Abolade Gbadegesin) and backend communications services ("Live Services: Notifications, Awareness, and Communications" by John Macintyre) might be most interesting to those who were intrigued by my post on the Live Mesh Blog and are curious to know more. 

Unfortunately, I won't be attending PDC - I'll probably be busy chugging caffeine and fanning servers while thousands of new users give our new Live Mesh offerings a spin. :)