(Of course, I still don't see the appeal in using motion to control my TV, after using a Kinect on-and-off since it was released. But, there's more to the market than just me, so, who knows.)

FWIW, a similar tool exists that works with most C-style languages, `uncrustify`. Might be worth looking into as well?

http://uncrustify.sourceforge.net

I suspect (but can't confirm without the source code to the demo) that shouldRasterize would actually hurt performance in one of the two cases in the article. Specifically, I imagine that it would make the score for adding and removing views from screen even worse than it already is.

Yes, it renders into a bitmap, and reduces CPU usage, once you've paid the upfront rendering cost. But, it doesn't rasterize opacity, and, will use up a ton of memory (because it doesn't result in stretchable images).

While its great to have a small image that doesn't require much I/O to read, "small" shouldn't only refer to file size.

Instead, a "small" image should be one that has a small resolution, and is stretchable. This lets the GPU tile the portions of the image that are being stretched and reuse GPU memory, instead of having to waste space in ram to hold duplicate pixel data.

(And when something's as small as it can be, it doesn't minify very well anymore -- not much left to strip from the PNG.)

In other words, the comparison is between the CPU redrawing a gradient 60x a second, and, an image being moved around on screen. Not entirely surprising that the one that does less rendering is going to be faster.

Basically, my target for the year is to read 104 new[1] books cover-to-cover, or, two books a week, and I'm currently a bit ahead of schedule.

1. Books that I haven't read before, not that are published in 2013.

I bet this changes in 10.9. At least, for Retina machines. There's a reason why iOS uses Helvetica Neue as the system font, and not Lucida Grande. It looks better on sharper displays.

The new iMessage app in 10.8 lacks instant messenger integration with services such as MSN, AIM, and Jabber, forcing the use of a different application for these features.

Erm. Those services are still there. Same as ever -- which never included MSN in the first place. Hell, theres a new framework, IMServices, which lets you add support for new services to Messages.app.

No. Just, no.

While I can totally relate to not wanting to have a 9-5 job (and even moreso when it comes to holding out for the right job) a dislike of working 9-5 jobs this is not unique to some (but not all, remember that) programmers.

  @interface MYObject : NSObject
  @property (nonatomic, copy) NSString *foo;
  @property (nonatomic, copy) NSString *bar;
  @end

  @implementation MYObject
  @end

  - (MYObject *) buildMYObject {
      MYObject *object = [[MYObject alloc] init];
      [object setValuesForKeysWithDictionary:@{ @"foo": @"purple", @"bar": @"elephant" }];
      return object;
  }

  - (void) useMYObject {
      MYObject *builtObject = [self buildMYObject];
      NSLog(@"value: %@", builtObject.foo); // will print "value: purple"
      NSLog(@"value: %@", builtObject.bar); // will print "value: elephant"
  }

1. It looks like the main benefit to the protocol is compatibility with the existing design of -[PFObject objectWithClassName:], and, I don't know enough about Parse to say what that does. But, I bet its nifty.

Aside from a small number of top-level classes[1] UIKit isn't designed to be subclassed. When you subclass things like UIAlertView, UIButton, UISwitch, UITextField, UIWebView… etc, you're in for a world undocumented gotchas and spending hours to do small simple things.

1. UIView, UIControl, UITableViewCell, UIScrollView, UIGestureRecognizer, UIViewController, UIApplication and maybe one or two other classes.

RegexKitLite - Powerful regular expression support

Use NSRegularExpression instead. It's built into the OS (in Foundation) as of iOS 4, which is below the minimum target you have (if you support the iPhone 5).