Anthony Bourdain on Showing Up on Time
This, seven ways from Sunday, emphatically this:
Q: What’s the best advice you ever received from anyone? Who gave it? And when?
A: Show up on time. I learned this from the mentor who I call Bigfoot in Kitchen Confidential. If you didn’t show up 15 minutes exactly before your shift — if you were 13 minutes early — you lost the shift, you were sent home. The second time you were fired. It is the basis of everything. I make all my major decisions on other people based on that. Give the people you work with or deal with or have relationships with the respect to show up at the time you said you were going to. And by that I mean, every day, always and forever. Always be on time. It is a simple demonstration of discipline, good work habits, and most importantly respect for other people. As an employee, it was a hugely important expression of respect, and as an employer, I quickly came to understand that there are two types of people in this world: There are the type of people who are going to live up to what they said they were going to do yesterday, and then there are people who are full of shit. And that’s all you really need to know. If you can’t be bothered to show up, why should anybody show up? It’s just the end of the fucking world.
Excerpted from this Men’s Journal interview.
[Sponsor] PagerDuty
PagerDuty is an operations performance platform that sits at the heart of your systems and helps you resolve incidents faster. Easily integrate all your monitoring tools for complete visibility across operations, and create on-call schedules to assign the right people to be alerted when something breaks. You can respond to alerts from anywhere, get automatic incident escalations, and ultimately shorten your response time to solve problems faster.
This post is sponsored via Syndicate Ads.
All These App Rejection Stories in One Headline “No One Dares to Build WatchKit Apps that Matter”
In a tweet so ludicrous it bears quoting in full, Greg Pierce announces that Apple has yet again rejected the Drafts.app Today Widget:
Last week’s rejection? Your Today widget does too much.
This week’s? Your Today widget doesn’t do enough.
Seriously.
— Greg Pierce (@agiletortoise) December 9, 2014Every time one of these iOS 8 Extension rejection stories tears across my Twitter and Bloglovin feeds, my mind goes straight to one thing: Apple Watch.
If you’re not already aware, the first round of third-party apps for Apple Watch will be built using APIs similar to those used to make Today Widget extensions. The Watch apps will bear one other crucial similarity to Today Widgets: they’re brand new.
I fear that Watch apps will be subject to the same capricious rejections and inscrutable policies that are already spoiling what should be a renaissance of fresh ideas. Between the lack of sustainable productivity app pricing (subscriptions, trials, paid upgrades) and the unpredictable threat of an App Review rejection, I personally can’t summon any excitement whatsoever about WatchKit. Why should I give a shit about sassy new hardware if the only apps worth building either can’t make money or might get rejected?
Unless something changes at Apple, I predict that we’ll mostly see two kinds of Watch apps next year: hobby apps by curious solo developers, and play-it-safe, free apps for business like Twitter or eBay. And it will be a shame, because the Apple Watch will deserve better.
[Sponsor]: PagerDuty
PagerDuty is an operations performance platform that sits at the heart of your systems and helps you resolve incidents faster. Easily integrate all your monitoring tools for complete visibility across operations, and create on-call schedules to assign the right people to be alerted when something breaks. You can respond to alerts from anywhere, get automatic incident escalations, and ultimately shorten your response time to solve problems faster.
This post is sponsored via Syndicate Ads.
Follow-up on Sharing Data with WatchKit Extensions
Recently I posted about a potential problem when sharing a Core Data SQLite-backed persistent store between a host app and one or more iOS extensions. The short version of the problem is that there doesn’t seem to be a way to prevent the creation of duplicate entries when syncing model objects from a remote API resource.
On Stack Overflow and elsewhere I got a lot of helpful replies with potential solutions or workarounds:
Accept Duplicates, Clean Up Later – Tom Harrington suggests not trying to prevent duplicates at all, but instead use the same approach that one applies to syncing Core Data via iCloud. Apple’s engineers explicitly caution you to anticipate merge conflicts, like duplicate entries, and to design cleanup strategies from the beginning. He’s written about this approach at length here.
Redesign Extension to be Read-Only – Dave Delong suggests a simple and obvious solution: don’t allow your extension to have write privileges for your shared Core Data store. If your extension design can handle this, it might be the cleanest and easiest approach.
File Coordinators – Apple’s WatchKit Programming Guide recommends using
NSFileCoordinatorto synchronize read/write access to shared file resources. However, in a bizarre technical note they also claim that usingNSFileCoordinatorin an extension can lead to unpreventable deadlocks and should not be used. If Apple ever resolves this issue, usingNSFileCoordinatormight be easier than cleaning up duplicates. Then again, it might be unwieldy, depending upon your persistence architecture.Build Custom Delta-Driven Syncing Architecture – If your remote API resource is not capable of running its own code (as is the case with iCloud and Core Data, for example), Milen Dzhumerov (an engineer behind Clear.app) describes an alternative in which the shared remote resource is not the whole object graph but instead a history of changes. This is essentially how iCloud+CoreData is supposed to work, with the exception that a domain-specific implementation is better suited to resolve conflicts in nondestructive ways. This is indeed how Clear.app was designed to work:
A peculiar property of the system is that the actual object graph is never stored on iCloud, only instructions on how to build it. When new data arrives from other devices, the whole history needs to be reconstructed to be able to obtain the latest object graph. […] When a device joins iCloud, it pushes its current object graph as a set of changes (so it would push create changes for each entity). When a device replays creation changes, it can detect duplicate requests for the creation of the same object (by looking at the object UID).
Milen’s entire article is fascinating and worth a read.
A painfully obvious solution occurred to me after writing my previous post. As long as the remote API resource is a server with its own conflict resolution management, why not just treat the extension as yet another client app? In other words, let each extension have its own complete stack, not sharing anything (except perhaps Keychain credentials and simple user default settings). The worst case scenario is that the extension and the host app are out of sync until both have had an opportunity to re-sync with the remote API, which may be a short-lived problem depending upon the design of your extension.