Vincent Gable’s Blog

July 17, 2008

Null-Terminated Argument Lists

Filed under: Bug Bite,C++,Cocoa,Design,Objective-C,Programming,Usability | , , , , ,
― Vincent Gable on July 17, 2008

I was using +[NSDictionary dictionaryWithObjectsAndKeys:] to make a new dictionary, but one of the objects in the dictionary was the result of a call to a method that was returning nil, so the dictionary was incomplete.

This got me thinking about NULL/nil terminated argument lists. I don’t think they are a great idea (the compiler should be able to handle the list-termination for you!), but I think they are an especially bad idea in Objective-C.

The problem that it’s very common to have a nil object in Objective-C, relative to, say C++. Many Cocoa methods return nil on error. Since doing stuff with nil (generally) won’t cause an exception, these nils stick around much longer then in other languages. As you can see, nil is a pretty poor choice of a sentinel value.

It’s the 21st century! The compiler could tell an Obj-C method using a variable-argument-list how many arguments are in the list. This is trivial when all arguments are of type id. Since Obj-C methods use a radically different syntax from C functions, it shouldn’t effect existing C-code. Unfortunately, I don’t see this being added, because Objective-C is already so mature.

In the meantime. Be a little more suspicious of any objective-C methods taking a NULL-terminated list. I wish I had a perfect solution to avoid them, but I don’t! Sometimes they are the best way to do something. If you have a great work-around for constructing, say an NSDictionary with a variable number of key/values please let me know!

July 7, 2008

Getting OS X Icons

Filed under: Design,MacOSX,Programming,Reverse Engineering,Usability | ,
― Vincent Gable on July 7, 2008

This is what the Apple HIG has to say about icons. You should read it if you ever use icons. Even if you are not drawing your own icons, you need to understand how they should be used. (eg: icons in a toolbar should have a flat “head on” perspective, not the three-demensional look they have in the Dock.) You’ll find the icons you need faster if you know what they should look like.

Websites with icons you can use freely: IconDrawer, Iconfactory, Kombine.net.

SystemIconViewer (source included) by Noodlesoft is a useful tool. It lets you browse over 100 standard OS X icons that are available programatically.

For getting paths to private OS X icons, try poking around inside CandyBar.app — A commercial program that lets you customize just about any icon on your system. As of v2.6.1 /CandyBar.app/Contents/Resources/English.lproj/IconData.plist contains information on where icons are located. Icon locations do change completely between releases of OS X, even if the icon itself does not! I found CandyBar to be a better source of up-to-date icon locations then google. IconData.plist is pretty big and dense, but you can search it for keywords if you open it in Xcode, which helped me a lot.

(Although I haven’t used any of them personally, these are some design firms Apple recommends, if you have the cash.)

July 6, 2008

Designers Don’t Solve Stuff

Filed under: Design,Programming,Quotes
― Vincent Gable on July 6, 2008

Designers are so low on the list of people capable of solving the problems we face … I don’t care how clever your layouts are, we, as designers, are incapable of solving global hunger, poverty or warming. We are what we have always been. The messenger, not the message.

Developers on the other hand …

Jack Shedd

Absolutely true, if “Designers” continue to limit themselves to style, and not how it works.

July 3, 2008

NP-Complete is Often Easy

Filed under: Design,Programming,Quotes | , , ,
― Vincent Gable on July 3, 2008

There are a lot of problems that are, in theory, incredibly difficult – but because the difficult cases are very rare and rather contrived, they’re actually very easy to solve. Two examples of this that I find particularly interesting are both NP complete. Type checking in Haskell is one of them: in fact, the general type inference in Haskell is worse that NP complete: the type validation is NP-complete; type inference is NP-hard. But on real code, it’s effectively approximately linear. The other one is a logic problem called 3-SAT. I once attended a great talk by a guy named Daniel Jackson, talking about a formal specification language he’d designed called Alloy. Alloy reduces its specification checking to 3-SAT. Dan explained this saying: “The bad news is, analyzing Alloy specifications is 3-SAT, so it’s exponential and NP-complete. But the good news is that analyzing Alloy specifications is 3-SAT, so we can solve it really quickly

Mark Chu-Carroll (aka MarkCC

Unfriends

Filed under: Design,Quotes | ,
― Vincent Gable on July 3, 2008

Facebook‘s “People You May Know” feature shows you a few links to profiles of people you … well, may know. Put another way it’s a feature that
shows you people that all your friends know who you are not friends with. There aren’t pleasant names for these kinds of people.

Facebook is a spiteful conniving bitch

It continues to put my ex in the “people you may know” section.
You fuckin’ dirty backstabbing whore, facebook, I’ll kill you. Just keep rubbing that shit in, I’ll fucking kill you.

some bitter guy.

Applying the ‘The Security Mindset’ can keep you from implementing a similar feature.

June 24, 2008

open source just isn’t a very good strategy for fixing ugly

Filed under: Design,Quotes |
― Vincent Gable on June 24, 2008

And unfortunately, open source just isn’t a very good strategy for fixing ugly.

Hank Williams.

June 6, 2008

case:

Filed under: Bug Bite,C++,Cocoa,Design,Objective-C,Programming
― Vincent Gable on June 6, 2008

This bug was frustrating enough that half-way through squashing it, I promised myself I would document the solution. Unfortunately, it’s not a particularly interesting bug, but a promise is a promise!

I had some code very much like:

typedef enum {NoError, ReadError, WriteError, NetworkError, UnknownError} ErrorType;
...
void DescriptionOfError(ErrorType err, char *string)
{
   switch(err)
   {
      IOError:
         strcpy(string, "Could not read data.");
         break;
      
      WriteError:
         strcpy(string, "Could not write data!");
         break;

      NetworkError:
         strcpy(string, "Network Error. Make sure you have an internet connection and try again");
         break;
      
      NoError:
         strcpy(string, "No error.");
         break;

      default:      
      UnknownError:
         strcpy(string, "Unknown error.");
         break;
   }
}

int main (int argc, char** argv)
{
   char desc[1024];
   DescriptionOfError(ReadError,desc);
   printf("error: %s\n", desc);
   return 0;
}

And it just wouldn’t do the right thing, but for the life of me I couldn’t see what was wrong.

The “solution” was very simple, and somewhat embarrassing. I forgot the case keyword before the labels in the switch statement. Turns out that if you don’t have a case in-front of a label, it’s treated like a goto label, not a switch label. And this is something that I’ve known for years, but for 20 minutes I kept reading the code, and my brain would interpret what it should say, not literally analyze it.

This was extremely frustrating, not because it took me a long time to fix (I wish all my bugs could be squashed in just 20 minutes!), but because the results I was seeing totally violated my mental model of what should have happened. Violating someone’s mental model is more unsettling then you might imagine — avoid doing it at all costs.

June 3, 2008

AppleScript is the Uncanny Valley

Filed under: Design,MacOSX,Programming,Quotes,Usability | , , ,
― Vincent Gable on June 3, 2008

A interesting theory:

I think this “like English but not quite” aspect of AppleScript is the Uncanny Valley of programming languages. Because AppleScript looks like English it is easy to fall into the trap of believing it has the flexibility of English. When that mental model fails its more unsettling than when you screw up the syntax in a regular programming language because your mental model isn’t making unwarranted assumptions.

Mark Reid

May 31, 2008

Links: Less Code Is Better

Filed under: Design,Programming,Quotes
― Vincent Gable on May 31, 2008

I happen to hold a hard-won minority opinion about code bases. In particular I believe, quite staunchly I might add, that the worst thing that can happen to a code base is size.

–Steve Yegge

The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.

Now, remember, these dimensions are all in opposition to one another. You can spend a three days writing a routine which is really beautiful AND fast, so you’ve gotten two of your dimensions up, but you’ve spent THREE DAYS, so the “time spent coding” dimension is WAY down.

So, when is this worth it? How do we make these decisions?

The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to:

“START WITH BREVITY. Increase the other dimensions AS REQUIRED BY TESTING.”

— Wil Shipley

May 28, 2008

The Minimum Screen Size You Must Support for Mac OS X Is 800×600

Filed under: Accessibility,Bug Bite,Design,MacOSX,Programming,Quotes,Usability |
― Vincent Gable on May 28, 2008

Mac OS X can run on systems with a screen size as small as 800 x 600 … Unless you know that your users will be using a specific display size, it is best to optimize your applications for display at 1024 x 768 pixels. … Design your user interface for a resolution of at least 800 x 600.

According to Apple’s Human Interface Guidelines (retrieved 2010-04-21).

« Newer PostsOlder Posts »

Powered by WordPress