Lee Whitney's Blog

iPhone OAuth Starter Kit for LinkedIn

 

I've created a starter project for using the LinkedIn Api via objective-c and the iPhone/iOS. 

 

 

I'm sharing this because I don't know of anywhere else you can get these in one place:

• One project with OAuth, JSON, and LinkedIn Api examples integrated
• Fully functioning, add your app keys and run
• Uses JSON data, includes the fastest iOS parser available
• Does not use HTTP body, everything in Authentication header
• WebView integration, no figuring out how to mix in the UI pieces
• XCode 4.01 project

Hopefully this can save someone some time.  OAuth has 1,000 tiny details that can go wrong - and usually do when you're first starting out.

Any feedback on the project or code is welcome.

Updated 4/11/2011: Rebuilt with XCode 4.01, added icons.

Download OAuthStarterKit_iOS_1_1

 

Nit-picking Google Chrome UI Design

What is the worst part of Chrome's user interface design?  There is one candidate I'd like to nominate.

The user interface to change the default font in Google's Chrome browser makes me cringe. To see if you agree, here are the basic steps a user follows to change the font:

1)    Wrench = Settings?

To change something in Chrome first requires you figure out that clicking the wrench icon is how to change browser settings.  For a computer savvy person ok, I'll buy this, but for many people I know (my parents included) this has already failed.  I totally get the reason behind this - Minimalist design is aesthetically pleasing and the lack of clutter on average can provide a better user experience.  However even when this philosophy works it's still going to have trade-offs and this case is one of them.   Overall I don't begrudge Google the choice of wrench in the spirit of simplicity.  It's a trade-off (like all designs require) but even good trade-offs have their negative side.

2)    Under the Hood is Scary

Once you get to the Chrome options the next step in changing the default font is to select a tab called "Under the Hood". 

Seriously? 

It seems a bit ironic that these correlations exist:

Need big font  >  Have poor vision >  Vision degrades with age > The older you are the less likely you want to click on features called Under the Hood

Maybe to change the default font they could make you click "Stick a fork in my eye…" Usability would probably be about the same, but it might add a little variety to the experience.

3)    Web Content is Meaningless

Users making it this far will find the font settings to be categorized under "Web Content".  At first this might seem reasonable.  On second thought almost anything in Chrome could be shoehorned into this category - it's a web browser for the love of...!  It's entire purpose is to help you with web content.  My only idea on how it could be more over-generalized would be if the category was "Internet Stuff".

4)    Eliminate Scrolling by Using Tabs which Require Scrolling

The final step to finding the default font settings is to realize that you must scroll down within the Under the Hood tab before you can see anything related to fonts.  The first problem with this is some designers just consider it bad design to scroll too much within tabs because one of the main reasons for the tab metaphor was to reduce the need for scrolling (run-on sentence intentional). 

Recapitulation

Changing the font in Chrome fails at least two common usability benchmarks.  First, it will often fail the parent test (unless your parents are fairly software savvy).  Second, the discoverability is really poor.

Discoverability isn't everything as Scott points out, however it shouldn't suffer any more than is necessary for a balanced experience.  Could some of the steps above be made more discoverable without hurting the overall balance of feature priorities?  It doesn't seem difficult to do.

Some may say, if you hate Chrome so much just quit using it!

However I don't hate Chrome - in general I respect the work Google has done.  To be fair, this is one small feature within a vast body of design and engineering.  Regardless of my feelings though I'm compelled to use all browsers - developers are commonly using a variety of browsers for testing, research, etc.  This is not likely to change, just like my vision is not likely to improve.

Anti-Feature Requests - A different way to contribute to Open Source Projects

 A lot of contributions to OSS are either writing code to add new features, or users requesting new features.

Both of these roles are critical but I've noticed there are few OSS participants formally identified as part of a "triage" team, yet it's quite common in the commercial software world.

Triage is essentially helping to decide what work should not be done, so that precious resources get applied to the best possible features and fixes (or least what work should have lower priority).

The term comes from the medical emergency rooms where doctors triage the patients into groups of different priority.  If you've broken your arm, you'll being waiting behind the person who needs immediate surgery, even if you arrived an hour earlier.

Certainly triage happens in OSS, a lot of times by development leads.  Tough decisions happen all the time.  However scouring a huge bug list for items that should be shifted up or down in priority, or questioning obscure items that might really not be as important, doesn't seem to always happen as much as it could.  How could it with only extremely busy developers held responsible?

Once example of this not being emphasized in OSS is that many projects have an option to "Vote for this issue as important", while not having an option to "Vote for this issue as not important" (allowing votes to be cast as 0 to 5 stars would help this).

So for projects where I contribute or at least follow the progress, I'm trying to make sure I keep an eye out for helping with triage where it seems productive.

Some project leaders may not want anti-requests or triage help, and that's of course their choice.  However I just think we should remember that an anti-request could be the catalyst to get your actual feature request enough resources to be completed sooner.

Lee

Linq DataContext and Dispose

A question many developers have with Linq and databases is this:

How important is it to call Dispose on a DataContext object?

Normally a quick web search gives an easy answer to common questions like this.  But sometimes Google fails us.  It turns out so many people have attempted to write about this with wrong or incomplete information that a web search returns mostly junk.

Here is a definitive answer, which I have finally learned after reading down to comment one hundred and twenty seven :) on a blog post by ScottGu, who runs the ASP.NET team at Microsoft.

Short answer:  It is generally not critical to call Dispose on Datacontext.

Longer answer: 
All objects in .NET are eventually disposed automatically by the automatic garbage collector.  The reason developers are paranoid about calling it explicitly is that if an object contains an expensive resource like an open database connection, then we can't afford to wait around for garbage collection, it would have a big impact on scalability.

The good news is that DataContext objects do not keep open database connections like some ADO.Net objects do, so it doesn't really hurt to let the garbage collector do it for you.

There is one caveat here though:  The DataContext does track change states for the data, and by disposing it you would release this memory more quickly.  In almost all apps this difference wont be significant.  However if you have a web site that is using all memory available this is one of many optimizations you could make.

Btw, a gigabyte of expensive ECC server memory is going for as little as 30 bucks now, so if your server is strained you can help it out pretty cheaply.