Memorable Songs from Pivotal Indy Moments of Your Life

While attending the Release Notes Conference this past week I saw a talk by Mike Hurley of RelayFM fame. A lot of the talk was pulling wisdoms from Mike’s own story, the history of his past projects up to working on RelayFM. One tidbit included an attachment to a song when he quit his job. For him the song was Another One Bites the Dust, Queen.

For me when I quit my full time job with ASMP to focus on my Mac development work the song was Maggie’s Farm, Bob Dylan. I was really into Dylan at the time and the lyrics just fit. I remember blasting it from my office and hearing it play throughout the apartment those first few indy days working at home.

I’d love to hear what songs match up to your own big indy life moments. Shoot me an email or tweet me your story.

Staying Secure on OS X with a Few Unsigned Apps

I could get into some real heavy talk regarding Apple’s policies about installing software outside their stores (and maybe I will someday) but for now let us all be thankful that not all Mac software must come to us through Cupertino. Let us also be thankful for Gatekeeper, a nice compromise Apple offers.

With Gatekeeper, Apple allows people to distribute Mac software outside the store but requires it be signed with an identity registered with Apple. The general idea being if a developer gets marked as distributing malware Apple can blacklist them so as to not effect users in the future. I’m not aware of any honest developer being wrongfully blacklisted and my general understanding is that the program is working well with known limitations.

OS X ships with a nice safe default via Settings > Security, “Allow apps downloaded from:” set to “Mac App Store and identified developers”. Unfortunately even though Gatekeeper has been around since 10.7 there are some apps that are not signed nor will never ever be signed that you want to run. Most users will sadly turn off the Gatekeeper check entirely at this point, leaving their system vulnerable. Below I’ll walk you though how to allow a unsigned app to run while leaving the security setting as-is.

By default OS X ships with the setting set to “Mac App Store and identified developers”.

default settings

When you try to open an unsigned app you’ll get a prompt like this:

prompt

Click OK and then go back to System Preferences and you might notice the pane has changed:

Open Anyway option

Now you can choose to “Open Anyway” for the last app blocked by Gatekeeper. Go back and try to launch the app again. You’ll get a final prompt asking if you sure, and upon clicking Open you’ll be able to run you unsigned app while still maintaining the default security setting.

Last check

While a little tedious jumping back and fourth for the initial approval, I’d much rather do this and leave Gatekeeper on than to run without the identity check. I highly recommend you do so too, and if you can, maybe a friendly email to your app developer asking him to sign his app.

UPDATE: Was informed by @boredzo and @ abrahamvegh that there is a shortcut to this flow if you anticipate the app requiring approval. For example, if you download an app you know will need this special exception you can control-click it and choose Open from the context menu. Doing so will cause a similar prompt that will whitelist the non-signed app and allow you to run it without turning off Gatekeeper. Thanks for the extra info guys!

Sweating the Little Details of UI Copy

While user interface design is not a core responsibility at my current job I do believe it is an important skill in my field and I try to improve all the time. A large aspect of user interface design is choosing the right words. For example, a good UI designer when crafting an iOS alert will honor and consider Apple recommendations. Some notes from the HIG:

Place buttons appropriately. Ideally, the button that’s most natural to tap should meet two criteria: It should perform the action that users are most likely to want and it should be the least likely to cause problems if a user taps it inadvertently. Specifically:

  • When the most likely button performs a nondestructive action, it should be on the right in a two-button alert. The button that cancels this action should be on the left.
  • When the most likely button performs a destructive action, it should be on the left in a two-button alert. The button that cancels this action should be on the right.

Give alert buttons short, logical titles. The best button titles consist of one or two words that describe the result of tapping the button. Follow these guidelines as you create titles for alert buttons:

  • As with all button titles, use title-style capitalization and no ending punctuation.
  • As much as possible, use verbs and verb phrases that relate directly to the alert text—for example, “Cancel,” “View All,” “Reply,” or “Ignore.”
  • Use “OK” for a simple acceptance option if there is no better alternative. Avoid using “Yes” or “No.”
  • Avoid “you,” “your,” “me,” and “my” as much as possible. Button titles that use these words are often ambiguous and can appear patronizing.

My personal pet peeve isn’t mentioned in the HIG but is present in almost all systems that require a user account:

Forget your password?

I hate that phrase. I find it to be patronizing and judgmental. As if I’m suppose to remember every password I ever created for every little web site and service. Who could?

Additionally, it’s misleading. If I click a link labeled “New Comment” I expect to be provided a form to make a new comment. If click a link to “Forget your password?” do I expect some flashy animated GIF that will erase some data from my brain? What I want is a link to “Reset Password”. The link title “Reset Password” is clear, focused on the target action to be performed and does not have a hint of judgement.

Sweat the little things. Read and then reread the interface guidelines. Be able to explain why for all your interface choices. Have fun.

How To Play WWDC Sessions at 2x Speed

Now that all the new bits of iOS 9 and OS X 10.11 are in the wild you might find yourself wanting to get up to speed on some of the changes. One great resource to help you get started is Apple’s WWDC videos.

The WWDC video library has a lot going for it: HD and SD video sizes, slide downloads and now even full text search! The only real negative thing is the sheer amount of content out there. It can get overwhelming and time consuming to watch all the stuff you are interested in. Here’s the hint. Like podcasts, WWDC videos are mostly single voices speaking one at a time and if you have the tools to double the playback speed you’ll find them still very comprehensible.

Now for the tools. For downloading you can of course use the Apple website. I like this WWDC Mac app as well. Once you have the video file on your hard drive you’ll unfortunately need to look for something beside the built-in QuickTime player to help. Even with all its enhancements it sadly doesn’t have this tool of QuickTime’s past. The good news is you can still download QuickTime 7 and it works great!

After you open your movie in QuickTime 7 (you’ll find it installed in the Utilities folder), use the Window menu and choose Show A/V Controls. In this panel you’ll see a slider that let’s you adjust the playback speed.

QuickTime 7

Now you can watch your chosen WWDC videos in half of the time! Enjoy!

UPDATE: My thanks to Paul Brown who let me know that the native QuickTime player can playback faster, even if it is a little hidden. To increase playback speed, bring up the controls with your mouse, then option-click on the fast-forward control. This will increment playback speed by 10% each time you click. You can keep clicking this up to 2.0x playback speed but sadly the audio does not work at 2.0x, you’ll have to limit yourself to 1.9x to retain the faster audio. Thanks again for the help Paul!

Quick Launching for Cocoa Unit Tests

I was doing some proofreading and research today regarding the latest testing features in Xcode 7. In the process I ended up rereading this article from Mark Dalrymple on code coverage. It’s a great article but it also reminded me of a little tip I wanted to share on the blog.

- (BOOL)application:(UIApplication *)application
    didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    ...
    // bail out early if we're running as a test harness.
    if (NSClassFromString(@"XCTestCase")) return YES;

    // otherwise load the main storyboard.
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"MainStoryboard" bundle:nil];
    UIViewController *vc = [storyboard instantiateInitialViewController];
    ...
}

Not only can this type of check help speed up your unit test times by a little bit, but, it also makes sure you aren’t loading things like crash log capture tools, performance monitoring injections, or other things that might otherwise interfere with your unit test logic or code coverage numbers. Now if you are doing the new UI testing you’ll probably have to use some other kind of flag to define this path, but regardless the core idea is the same.

CocoaLove 2015 Notes

This weekend was the second annual CocoaLove event here in Philadelphia.

A conference about people, not tech. CocoaLove highlights the iOS/Mac community’s passions, challenges, and triumphs.

From all accounts, people had a great time. My very heartfelt “thank you” to the speakers, attendees and organizers for making it such a blast.

Some of my own takeaways and notes:

  • Just Do It! and more specifically, don’t let your high taste of quality hold you hostage from creating and shipping. Get it out in the world and improve it over time.
  • Don’t let the negativity of the web infect you. Be positive; be constructive.
  • Make time to help people out. Mentor them, teach them, guide them. It’s probably the most import work you’ll ever do.
  • Embrace today; do what you love; don’t settle.
  • Don’t let other people define your life’s scope. Poke life.
  • The world is in desperate need of good managers. Managers need not be robots; the best managers can have a huge impact on their team and the product.
  • Don’t let imposter syndrome or other people hold you back.
  • Humanizing the customer support experience is extremely important. These people are calling out for help, treat them right.
  • The developer ecosystem is forever changing. Even today the wheels are in motion and a few years from now it’ll be different. Be prepared for change.
  • Embrace side projects. Start tons of things. Experiment. Do things outside your comfort zone.

While we wait for this years talks to be edited and published, consider stopping by the 2014 video collection. In particular I recommend Joe Cieplinski – The Back of the Fence.