Deleted my Instapaper Account, Here are Some Stats, and Why the Service Didn't Work For Me

TL;DR	645 Unread	25 Archived	1 Starred

I've had an Instapaper account since 2008 when Marco Arment launched the service until now. I haven’t been using the account for most of the last 2 years, with my last save in June 2014, the only one the whole year.

So I deleted my account. Finally!

The idea never really worked for me, even though I was very excited about it. I’ve always been a news junkie. My routine is daily RSS reader, hourly Twitter timeline, Facebook News Feed mostly on weekends, and daily manual reading of a number of sites. The idea of a service that could generate a newspaper like thing for me to read later seemed great. But I realized that after I went through my usual news reading routine, my attention was exhausted. 

Instead, I used Instapaper as a bookmarking service for “important stuff”, longer form deeper think pieces I thought I absolutely had to know and would get to later. That also turned out to be untrue. Out of the 671 links I added to Instapaper, how many did I actually read? 26! 3.8%. That’s way lower than even I expected.

I’ve been using the Reading List feature built-in to Safari on iOS and OS X, but it’s where links kind of go to die for the same reasons as Instapaper, I just don’t go there, does’t fit into my routine. Bookmarks are a similar story, only the Bookmarks on my favorites bar see any action.

What I think I might need is something to save links grouped by research topic, not just one big list. Bookmark Folders kind of serve that purpose, but it’s not really an elegant or searchable tool.

I’ve also kind of become one of those people on a desktop browser that just leaves a browser window open per topic with tabs for each site until I’m ready to deal with it. Safari does an excellent job of keeping this state at the ready in my Dock on OS X.

 

How To Use the Spock Live Long and Prosper Emoji on iOS 8.3 & OS X 10.10.3

Versions:	OS X  10.10.3		iOS 8.3

 

Despite the date, this article by Jason Snell at Six Colors about the Spock Live Long and Prosper hand gesture, referred to as Raised Hand with Part Between Middle and Ring Finger, is not an April Fool’s Joke.

 

iOS 8.3 and OS X 10.10.3 can display the emoji, but it isn’t in the standard Emoji keyboard on either OS yet.

 

To be able to use the emoji on OS X, you can create a text replacement macro to use it now:

1. Copy the emoji from here: Raised Hand with Part Between Middle and Ring Finger (Blogger keeps double-encoding the emoji and makes it unreadable).
2. Go to System Preferences -> Keyboard -> Text tab.
3. Click +.
4. I used LLAP in the Replace column and the emoji in the With column.
5. That’s it!

Now when you type LLAP on OS X, you’ll get prompted to use the emoji.

 

Now on iOS:

1. Copy the emoji from here: Raised Hand with Part Between Middle and Ring Finger
2. Go to Settings -> General -> Keyboard -> Shortcuts.
3. Tap +.
4. Paste the emoji into Phrase.
5. Type LLAP into Shortcut.
6. Tap Save.

Now when you type LLAP on iOS, you’ll get prompted to use the emoji.

 

Live Long and Prosper!

With Autocompleted Methods & Functions, I Wish Returned Values Came After the Call In Swift

We’ve been calling functions or methods on objects the same since at least C appeared in 1972. You declare & call a function like this:

int main(void) {
    printf("hello, world\n");

    return 0;
}

int value = main();

To define, the return type is declared before the name of the function. On call, a variable is declared to hold the return value of the function call.

In Swift, you declare a function with a return type like this:

• func printAndCount(stringToPrint: String) -> Int {

      println(stringToPrint)

      return countElements(stringToPrint)

  }

I loved this change to the C convention. IMHO, the information importance follows the order you declare the function: name, parameter type(s), and return type(s). However, you still call that function like this:

• let count = printAndCount("Hello, playground")

This feels like a job half done, a little bit like the tail wagging the dog

I nearly always know the name of a function or method I want to call before I know its return types.

Wouldn’t it be great if the language was fully adapted to the pervasiveness of autocomplete?

Imagine the amount of time you’d save if you could start typing the name of the function or method first and let autocomplete show & then fill in the return types?

Proposing Post Call Return Value Assignment

I’m proposing that variables that are assigned the return value of a function should come after the function call using a return arrow. It would look something like this:

printAndCount("Hello, playground") -> let count

With methods, it would look like this:

someObject.printAndCount("Hello, playground") -> let count

The actual syntax is up for debate, but I’m excited by the idea. I don’t know of another language that does this.

Pros

• Far fewer trips to documentation to lookup the return types of a function you know the beginning of.
• Far less typing of return types of any kind
• Far less (no?) typing the object, autocompleting the method, then fixing up the return types to variables you want.

Cons

• Return variables harder to “find” when reading code
• Listing for completeness, I don’t see it being materially wrong, just different from the norm
• Imagine the style debates because the existing way stays in the language.

I’m betting the pros would outweigh any cons, and this feature would greatly increase the usability of the language and editor together.

iOS MPMoviePlayerController Crashes when prepareToPlay is Called Without Adding to a View

TL;DR	Call something like [self.view addSubView:moviePlayer.view] before [moviePlayer prepareToPlay]

Versions:	OS X  10.10.2	Xcode 6.2	iOS SDK 8.2

I just inherited some code previously compiled against iOS SDK 6.0, ran fine through iOS 7, but crashes on iOS 8.x. Here’s the crasher:

NSURL *url = [NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"impact_of_needs_goal_planning@1x" ofType:@"mp4"]];
self.moviePlayer = [[MPMoviePlayerController alloc] initWithContentURL:url];
self.moviePlayer.shouldAutoplay = NO;
[self.moviePlayer setControlStyle:MPMovieControlStyleNone];
[self.moviePlayer.view setFrame:CGRectMake(0.0, 0.0, 1024.0, 748.0)];
[self.moviePlayer.view setTag:7];

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(movieDidLoad:) name:MPMoviePlayerLoadStateDidChangeNotification object:self.moviePlayer];
[self.moviePlayer prepareToPlay];

App was crashing on the last line, [self.moviePlayer prepareToPlay]; every time it was called.

This is a guess (because installing an iOS 7 simulator is taking forever), but it looks like iOS 7 and below didn't care because the app was working fine. iOS 8 crashes.

The solution is adding the moviePlayerController to a parent view before calling [self.moviePlayer prepareToPlay];, like this:
[self addSubview:self.moviePlayer.view];

Given this is The Right Thing To Do™, I'm actually surprised it ever worked!

Update

Turns out this was not the cause of the crash, which I have yet to nail down. This change did seem to temporarily solve the crash, but alas it is something to do with NSNotifications :’(