Vincent Gable’s Blog

June 17, 2010

The Arrow Points Up

And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they’re current working at is exactly the right one for the task at hand. Anything lower-level is seen as barbaric, and anything higher-level is a bloated, slow waste of resources. This remains true even as the overall level of abstraction across the industry marches ever higher.

First the C guys can’t imagine writing in assembly anymore, but C++’s vtable dispatch is still just too slow to consider. Then the C++ guys look back with chagrin at the bad-old-days of rolling their own half-assed object systems in C, but Java is dismissed as a ridiculous pig. Still later, the Java guys sneer at pointers and manual memory management, but JavaScript is ridiculed as a toy “scripting” language for validating web forms. And on and on.

And in the short term, in the moment, they’re often right. But this arrow points only one way, and that’s in the direction of ever-higher abstraction. To judge how much time remains before the next leap forwards, look at the leading edge of the industry.

John Siracusa (emphasis mine)

Here’s my two cents on the future of abstraction: systems are clearly getting wider (paralell), not faster; technologies like Grand Central Dispatch help us deal with concurrency today, but longer term, I think a functional programming abstraction is the answer.

June 14, 2010

Ask F-Script!

Filed under: Cocoa,iPhone,MacOSX,Objective-C,Programming | , , , , , ,
― Vincent Gable on June 14, 2010

F-Script is an amazingly useful tool for answering quick API
questions, like “What happens if I pass in nil“. I use it several times a week. For verifying corner-cases, F-Script is faster than google, stackoverflow, or reading header files. Just type in a questionable expression and instantly see what happens.

There’s a good tutorial to get you started quickly. I’m not going to reproduce it here, so if any of these examples aren’t clear, go read it.

Example: NSMutableArray

Objective-C had historically poor support for exceptions, and the Foundation/Cocoa libraries are pretty inconsistent about using them. For example, trying to add nil to an array throws an exception, but trying to remove nil from an array has no effect. Here’s how I used F-Script to verify that,

> a := NSMutableArray array

> a addObject:nil
NSInvalidArgumentException: *** -[NSCFArray insertObject:atIndex:]: attempt to insert nil

> a addObject:'foo'

> a
NSCFArray {'foo'}

> a removeObject:nil

> a
NSCFArray {'foo'}

If you’re not impressed, I understand. Static text really can’t convey the power of an interactive console. Sure, the F-Script syntax is marginally more concise than writing the equivalent code in Objective-C, but not enough that it matters. What matters is the interactivity, I got my answer as soon as I hit return. No waiting on the compiler. No switching between the program and Xcode. Immediate feedback.

You might prefer to use python as a Cocoa console. That’s cool! I prefer F-Script because it’s closer to Objective-C, but any tool with a REPL console works. If you have a favorite, please leave a comment!

REPL consoles for exploring Objective-C on a Mac:

June 11, 2010

Simulator Advertising?

Filed under: Announcement,iPhone,MacOSX,Programming | , , , , ,
― Vincent Gable on June 11, 2010

I wish I could take credit for this idea, but it’s from someone else, will Apple sell iAds that only show up in the iPhone simulator? Probably not, but it would be a hell of a targeted demographic.

For those of you who aren’t familiar with how building iPhone software works, we developers spend thousands of hours testing and debugging our programs in an iPhone Simulator application that runs on our Macs. The simulator can’t run Apps from the App Store, only programs compiled from source code with Xcode. So the only people using the simulator are programers, or otherwise deeply involved with building iOS apps. Apple could make it so that any iAds in the simulator would show special ads targeted to developers.

Better still, iAds in the simulator could show something useful like rules from the Human Interface Guidelines (that too few read), good tips or even inspiring quotations.

June 9, 2010

Apple’s Typographic “Perfection” Sucks

Filed under: Design,iPhone,Quotes | , , , ,
― Vincent Gable on June 9, 2010

…one particularly outrageous moment stuck out for me. At about three minutes into the video, senior vice president for iPhone software Scott Forstall extolls the virtues of the Retina Display by declaring that “The text… is just perfect!” Meanwhile, the central image in the video at just that moment is this little typographic calamity:


I urge you to fast-forward the time code to 3:02 to hear this for yourself. Forstall is quite literally claiming perfection while a hand model holds up this terrible example of everything that’s wrong with Apple’s commitment to typography. While the letterforms on that virtual page may look gorgeous, it’s apparent to any designer that the text is far from perfectly typeset. It’s hideous, scarred as it is by unsightly “rivers” of bad spacing within the text. No self-respecting typographer would dare call that perfect.

Khoi Vinh

The unrelenting drive for perfection was a quality I always admired in Apple. I hope this is just bullshit spin, and an unfortunate choice of sample frames.

June 7, 2010

Quality is Money

Filed under: iPhone,MacOSX,Programming,Quotes | , , , ,
― Vincent Gable on June 7, 2010

The truth is that an iPad app is neither easier nor harder to make than an iPhone app (or a Mac or Windows app), in any general, reasonable, defensible way. Software doesn’t work like that; we don’t have to work twice as hard to cover twice as many pixels on screen. It’s all about the elusive quality factor.

Matt Legend Gemmell, on iPad App Pricing


June 2, 2010

NSHomeDirectory() is a Bad Thing

Filed under: Announcement,Cocoa,iPhone,MacOSX,Objective-C,Programming | , ,
― Vincent Gable on June 2, 2010

Code that uses NSHomeDirectory() is probably doing The Wrong Thing. It’s not appropriate to clutter up the user’s home directory — internal application-data should be stored in the Application Support directory (or a temporary file if it’s transient). So I can’t think of a good reason to get the path to the user’s home directory. Every use of NSHomeDirectory() I’ve seen is spamming the home directory, or getting a subdirectory in a brittle way.

For sample code that gets a directory robustly, using NSSearchPathForDirectoriesInDomains(), see Finding or creating the application support directory.

Because NSHomeDirectory() encourages so many bad practices, it should be deprecated.

Disabling NSHomeDirectory() in Your Projects

Add the following macro to your prefix file:

#define NSHomeDirectory() NSHomeDirectory_IS_DISCOURAGED_USE_NSSearchPathForDirectoriesInDomains_TO_GET_A_SUBDIRECTORY_OF_HOME

Then any use of NSHomeDirectory() will give the compiler error:

‘NSHomeDirectory_IS_DISCOURAGED_USE_NSSearchPathForDirectoriesInDomains_TO_GET_A_SUBDIRECTORY_OF_HOME’ undeclared (first use in this function)

Tell Me I’m Wrong

If you’ve seen a legitimate use of NSHomeDirectory() please leave a comment! Just because I can’t think of one doesn’t mean they don’t exist.

May 26, 2010

drain an NSAutoReleasePool Don’t release it

To clean up an NSAutoreleasePool, do [pool drain]; not [pool release];

In a garbage-collected environment, sending any object a release message is hardcoded by the runtime to do nothing (very quickly). So [pool release] won’t do anything. But [pool drain] will signal the garbage collector to cleanup, and works correctly (just like release) in a non-garbage-collected environment.

Why This Still Matters on an iPhone

The iPhone doesn’t have garbage collection today. That doesn’t mean it never will. RIM and Android both support some kind of garbage collection. I’m too grizzled an Apple developer to not future proof my code, because I’ve been effected by Apple making some major runtime changes (eg. switching between PowerPC, x86, x86_64, and ARM processors). Section 3.3.1 of the iPhone SDK agreement means Apple’s runtime is the only game in town. It pays to be sure your code always plays nicely with it.

Using drain also helps your code will play nice with Mac OS X. That gives you more options to re-use and monazite it. If you decide to go the open-route, it means more people will be able to use your code.

May 25, 2010

Write dealloc FIRST

Filed under: Bug Bite,Cocoa,Objective-C,Programming | , , ,
― Vincent Gable on May 25, 2010

As soon as you give a class a new instance variable (ivar), update the class’s dealloc method (and viewDidUnload, if the ivar is an IBOutlet) to clean up the ivar. Do this before you write the code using the new ivar. Here’s why:

Never Forget

You can’t forget to release an ivar, if the code that reaps it is in place before the code that creates it. Updating dealloc first means less memory leaks.

Even with an impossibly good testing protocol, that catches every memory leak, it’s faster to fix memory leaks before they happen than to track them down after the fact.

You Know More Than They Do

Sometimes there’s an important step that must be done when cleaning up an ivar. Maybe you need to set it’s delegate to nil, or unregister for a notification, or break a retain cycle. You know this when you setup the ivar. But your coworkers don’t know this a priori. When you checkin code that leaks or triggers an analyzer warning, they’ll want to fix it, and since they know less than you do about your code, they’re more likely to miss a crucial step. (Even if you work alone, remember Future You! In N weeks, Future You will have to deal with all the code Present You wrote today … and they’ll be in the same situation as any other co-worker, because they won’t remember everything Present You knows. )

May 24, 2010

Experts are Easier to Fool

Filed under: Quotes,Research,Security | , ,
― Vincent Gable on May 24, 2010

Another counter-intuitive finding is that scam victims often have better than average background knowledge in the area of the scam content. For example, it seems that people with experience of playing legitimate prize draws and lotteries are more likely to fall for a scam in this area than people with less knowledge and experience in this field. This also applies to those with some knowledge of investments. Such knowledge can increase rather than decrease the risk of becoming a victim.

(via Bruce Schneier)

Never Name a Variable “Index”

Filed under: Bug Bite,C++,Cocoa,Objective-C,Programming | ,
― Vincent Gable on May 24, 2010

Never name a variable index, especially in C.

Instead say what it indexes. For example, if it is used to index an array of Foo objects, call it fooArrayIndex, or currentFooIndex.

If the index variable is just used to enumerate over a collection of objects, (eg. for(int i = 0; i < arraySize; i++){…} ) then iterate smarter, using a simpler construct that doesn’t require declaring auxiliary variables. (Eg., in Objective-C use Fast Enumeration). It’s not always possible to do this, but it’s always a good idea to try.1

Why index is Especially Bad in C

The standard strings.h header declares a function named index, that finds the first occurrence of a charicter in a C-string. In practical terms every C program will have the index function declared everywhere.

But when a variable is declared with the name index it shadows the function — meaning the local variable named index takes over the name index, so the function can’t be called anymore:

char * world = index("Hello, World", 'W');
NSLog(@"'%s'", world);

Prints “‘World'”, but

int index = 0;
char * world = index("Hello, World", 'W');
NSLog(@"'%s'", world);

Won’t compile, because an int isn’t a function.

Obviously this is a problem for code that uses the index() function — but honestly modern code probably uses a safer, unicode-aware string parsing function instead. What’s given me the most trouble is that shadowing index makes the compiler give lots of bogus warnings, if you have the useful GCC_WARN_SHADOW warning turned on.

There are other good reasons as, specific to Objective-C, which Peter Hosey covers.

1If you really can’t think of a better name than “index”, I prefer the more terse i. It sucks, but at least it’s shorter. Brevity is a virtue.

« Newer PostsOlder Posts »

Powered by WordPress