Erica Sadun http://ericasadun.com Where technology meets something or other Wed, 09 Aug 2017 16:58:45 +0000 en-US hourly 1 https://wordpress.org/?v=4.8.1 Helpful hint to anyone attempting to compile Swift right now http://ericasadun.com/2017/08/09/helpful-hint-to-anyone-attempting-to-compile-swift-right-now/ http://ericasadun.com/2017/08/09/helpful-hint-to-anyone-attempting-to-compile-swift-right-now/#comments Wed, 09 Aug 2017 16:58:45 +0000 http://ericasadun.com/?p=5809 Revert  to Beta 4 and make sure to use xcode select

sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer

Otherwise you’ll get a whole bunch of issues with AV Foundation.

]]>
http://ericasadun.com/2017/08/09/helpful-hint-to-anyone-attempting-to-compile-swift-right-now/feed/ 2
Swift 5 begins: new evolution rules will require implementations for language change review http://ericasadun.com/2017/08/08/swift-5-begins-new-evolution-rules-will-require-implementations-for-language-change-review/ http://ericasadun.com/2017/08/08/swift-5-begins-new-evolution-rules-will-require-implementations-for-language-change-review/#comments Tue, 08 Aug 2017 17:04:47 +0000 http://ericasadun.com/?p=5807 Ted Kremenek writes about Swift 5 on the Swift Evolution list. Among other changes, SE proposals will now require implementations before Core Team review. Swift 5 will focus on ABI stability and concurrency.

The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year. Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted updates to the README.md file on the swift-evolution repository, which outlines the core themes and focus areas for Swift 5:  https://github.com/apple/swift-evolution and a more persistent URL (invariant to future README.md changes): https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

I am not going to repeat all of that information here, but I wanted to highlight a few important things.

ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a requirement of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module stability. If you are not aware of the difference — which is rather important — please read the first few paragraphs of the ABI stability manifesto: https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.

Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, but there is a general theme of refining and broadening out the core ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency model. That is simply too large an effort to do alongside ABI stability. However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork. This may take the form of specific enhancements to the language that get implemented, depending on where the discussions for concurrency lead and how they align with the priorities for delivering ABI stability in Swift 5.

Changes to the language evolution process

Last, I want to highlight important changes to the evolution process for-swift-5:

With Swift 4, the release period was divided up into “stage 1” and “stage 2” for setting guidelines for the kind of evolution proposals that were in scope for the release. This was needed to establish focus — especially after the churn we saw during Swift 3 — on some core themes that were aligned with converging the language towards source & ABI stability. One downside is that “stage 2” opened up discussion for potentially disruptive changes fairly late in the release. Further, some proposals — such as SE-0155 — came in so late that there was little runway to actually implement them for Swift 4, let alone evaluate their impact in practice on real projects. Related, there has been some desire for a while to be able to better evaluate the impact of proposals on real code before they are locked into the release, and the best way to do that is to actually have an implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both design and implementation work, but the Core Team did not want that focus to stifle all discussion on potential enhancements to the language that were not fundamentally tied to that primary goal. After reflecting on the evolution process during both the Swift 3 and Swift 4 releases, the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by requiring that all proposals have an implementation before they are officially reviewed by the Core Team. An implementation can come long after an idea has been pitched and after a proposal has been written. However, before a pull request for an evolution proposal will be accepted — and thus an official review scheduled — an implementation must be in hand for a proposal as part of the review. The existence of an implementation does not guarantee that the proposal will be accepted, but it is instrumental in evaluating the quality and impact of the proposal.

There are two key benefits of requiring an implementation:

  1. It encourages a design in a proposal to be more thoroughly fleshed out before the proposal is formally reviewed. The hope is that this will make the review process both more efficient as well as more effective.
  2. An implementation allows the proposal to be evaluated on real world code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in providing an implementation for a proposal that is not likely to get traction. The Core Team will be regularly reviewing potential proposals, and provide feedback either during the pitch stage or when a proposal is submitted via a pull request on whether or not the proposed change looks within the charter of the release or meets the criteria for a valuable change to the language.

Requiring an implementation naturally raises the bar for proposals. While this is by design, it can possibly have the negative aspect of making some feel the bar is too high for them to participate in the Swift evolution process. As an open source project, both the design and implementation of the language is a highly social endeavor, and we encourage the community to collaborate on both the design and implementation of proposals. Specifically, it is not a requirement that the original author(s) of a proposal be the one who provides an implementation — all that matters is that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of scope for proposals considered for Swift 5 begins… now! Proposals that fit within the general focus of the release are welcome until March 1, 2018. Proposals will still be considered after that, but the bar will be increasingly high to accept changes for Swift 5.

  • Ted
]]>
http://ericasadun.com/2017/08/08/swift-5-begins-new-evolution-rules-will-require-implementations-for-language-change-review/feed/ 2
Dear Erica: How do I simplify `Swift.print`? http://ericasadun.com/2017/07/18/dear-erica-how-do-i-simplify-swift-print/ Tue, 18 Jul 2017 16:27:09 +0000 http://ericasadun.com/?p=5800 Dear Erica:

In other languages (Python mostly comes to mind, but I think ml and probably Haskell as well) you can essentially create a new name for a function by assigning it to a variable and use that instead.  All type information and usage follows with it.

I use it a lot in Python to have a local variable that’s  already bound to some otherwise nested module call. It saves some lookup time and textual typing. (Gotta be explicit since syntactic typing is relevant in Swift.) In trying to work around the problem of “print” calling  NSDocument.print, I tried declaring a val at the top level:

let Print = Swift.print // for print to console

The compiler seemed happy with the definition but when I tried to use it as in:

Print(“in makeWindowControllers”)

I got:

Hitting Fix did nothing but I wasn’t really expecting much (this is Xcode 9.0 beta). I assumed it wasn’t  telling me to literally put <#String#> in as a second parameter but that the type inference was inferring a type of String for  parameter #2  It didn’t really make any sense (why would a second parameter be required for a variadic argument?) If two, why not 3…?

So I tried the following but to no avail:

Print(“in makeWindowControllers","two”)

One can obviously write a full function which works fine:

func Print(_ items:Any...) -> () {
    print(items) 
} 

Print("in makeWindowControllers")

It’s pretty simple but seems unnecessarily heavyweight. I can’t seem to find any way to do a variadic closure. Is this possibly a bug or am I missing something obvious? Is there any reason the simple value declaration shouldn’t work? I know I’ve seen complaints about the lack of an Apply function in Swift. Not sure if this is related. My functional mojo is somewhat lacking…

This is a terrific question, and I’m going to answer it in several parts.

First, the full signature of Swift’s version of print is

public func print<Target>(_ items: Any...,
    separator: String = default, 
    terminator: String = default, 
    to output: inout Target) 
    where Target : TextOutputStream

See all those default items?  They don’t travel nicely to closures.  Second, take careful note of the variadic items, because you can’t pass them along by redirecting them to another function. Your “full function” actually prints an array of the items you pass:

Print("Hello world") // prints ["Hello World"]

The only way around this for 10.12 and earlier is to re-implement print (or a reasonable facsimile). Having tried that this morning, I warn you, it is a doozy. Seriously. You wouldn’t believe how many functions and files go into this one little call.

Fortunately, this name-overlap problem (NSView.print vs Swift.print, etc) is fixed in High Sierra. The 10.13 release notes write:

print() methods in Swift: NSWindow, NSView, NSDocument’s print() instance methods have been renamed to printWindow(), printView(), and printDocument() respectively in Swift 4. This fixes the unexpected experience where adding debug logging to a subclass of one of these instances shows a print panel instead.

You can help the variadics don’t propagate cause (“El viva variadics!“) by filing a radar. Go ahead and dupe, mentioning rdar://problem/12134482.

For the moment, here’s a less capable workaround you can use. It does pretty much what you want with slightly reduced capabilities (and complexity) compared to the built-in Swift.print solution.

public func sprint(
    _ items: Any...,
    separator: String = " ",
    terminator: String = "\n")
{
    var prefix = ""
    for item in items {
        Swift.print(prefix, terminator: "")
        Swift.print(item, terminator: "")
        prefix = separator
    }
    Swift.print(terminator)
}

It’s kind of a production-unfriendly workaround for just avoiding Swift.print, but I hope this helps anyway.

Thanks Dave, Tim, Stephen, Caleb

]]>
Beta 3 iPad Control Center Updates http://ericasadun.com/2017/07/15/beta-3-ipad-control-center-updates/ Sat, 15 Jul 2017 19:36:14 +0000 http://ericasadun.com/?p=5798 The screenshot facility is still broken, retaining the orientation (including sideways and upside down, or blank if launching) of the last application use. However, those tiny “x” buttons for closing an app are gone. It’s slide-up again. Thank you, Apple.

Incidentally, battery life has been good (it was good in Beta 2 for me but I hear that iPhone users weren’t as lucky as iPad installs). And responsiveness is pretty good.

]]>
Beta 3 Playground Workarounds http://ericasadun.com/2017/07/14/beta-3-playground-workarounds/ Fri, 14 Jul 2017 19:04:38 +0000 http://ericasadun.com/?p=5792 Adding Resources and Sources folders to Playgrounds

Until they’re fixed, you may have to add them by hand.

  1. Right-click/control-click.
  2. Show package contents
  3. You can add new Resources and Sources files at the top level
  4. Alternatively, navigate down to individual pages (which are finally in Beta 3!) by showing their package contents and add them there

Fortunately under Beta 3 you don’t have to manually add pages, as the new page functionality is finally back.

Creating New Playgrounds

They’re no longer listed in the File > New dialog. Instead choose File > New > Playground (Command-Shift-Option-N) or open “Welcome to Xcode” (Command-Shift-1) and click “Get started with a playground”.

Most of the obvious alternatives (like Command-Control-N, which creates new workspaces) are already taken, but if you don’t mind using the menu for that, I think it’s a nicer key binding for “New Playground”. If you want to mess with this open prefs (Command-comma), type playgrounds into the search field, and edit the key binding for “New > Playground”

Don’t forget that new playground page is “Command-Option-N”.

]]>
The Perfect QA Recruitment Filter http://ericasadun.com/2017/07/11/the-perfect-qa-recruitment-filter/ http://ericasadun.com/2017/07/11/the-perfect-qa-recruitment-filter/#comments Tue, 11 Jul 2017 15:39:57 +0000 http://ericasadun.com/?p=5779 Have you ever heard of the “Brown M&M” clause? The band Van Halen used to issue a contract rider for its shows. In it, they requested a supply of M&Ms for backstage but specifically excluded any brown ones. Van Halen reserved the right to cancel the show if any  brown M&Ms were found.

Superficially, this may sound like a particularly obnoxious and entitled rock star request. However, there was a deeper motivation for this contract stipulation. As articles in recent years have revealed, Van Halen’s “no brown M&Ms” clause acted as an early warning system that alerted the band about potentially unsafe venue conditions.

Steve Jones of Entrepreneur writes:

In now-departed arenas such as Toronto’s Maple Leaf Gardens, the original Boston Garden and Chicago Stadium, Van Halen was loading in massive amounts of staging, sound equipment and lighting. Unfortunately, these buildings were never built to accommodate a rock band of Van Halen’s scope. Without specific guidelines, old floors could buckle and collapse, beams could rupture, and the lives of the band, their crew and fans could be at serious risk.

To ensure the promoter had read every single word in the contract, the band created the “no brown M&M’s” clause. It was a canary in a coalmine to indicate that the promoter may have not paid attention to other more important parts of the rider, and that there could be other bigger problems at hand.

Whenever the band found brown M&M’s candies backstage, they immediately did a complete line check, inspecting every aspect of the sound, lighting and stage setup to make sure it was perfect.

This kind of smart business check isn’t limited to large-scale traveling productions. JF Poole of Primate Labs was telling me the other evening about a similar approach he uses for recruiting Quality Assurance engineers.

“What I love,” he said, “is that pretty much every cover letter we’ve received for the position has cited the candidate’s ‘great attention to detail’ but almost none of them include the candidate’s favorite primate.”

Odd detail, right? But Primate Labs specifically asks for that as part of their recruitment process. The job listing says, “Please, mention your favorite primate in your cover letter.” For a position whose foundation is careful adherence to detail through every stage of production, it’s the perfect test.

Like Van Halen’s brown M&M’s, the recruiters at Primate can quickly scan incoming applications for one unique signifier. Even better, that request tests a candidate’s intrinsic suitability for the position: a rigid and fanatical adherence to detail. When an applicant doesn’t pay attention to the job listing, they probably won’t pay proper attention to your software. It’s a genius approach.

In some cases, sophisticated tells aren’t exactly needed (for example,  “I, $NAME (sic), have come across an opportunity for the position of Software QA Analyst for your esteemed company.“) but it’s helpful to adopt a quick indicator, allowing HR to set aside resumes for more serious consideration.

When I mentioned how sad I was that I couldn’t write up a post about this, John assured me that it would be okay. (“You’re overestimating the set of people who would a. read your blog, and b. apply for our job. Go for it.”) Can you think of any other job category that can so easily hide stealth “tells” for qualifications outside of, maybe, “profreader” (sic) and other consistency-driven positions?

For what it matters, my favorite primate (outside of my husband and kids) is the Slow Loris. Isn’t it cute?

(image via International Animal Rescue)

]]>
http://ericasadun.com/2017/07/11/the-perfect-qa-recruitment-filter/feed/ 1
Result types http://ericasadun.com/2017/07/05/result-types/ http://ericasadun.com/2017/07/05/result-types/#comments Wed, 05 Jul 2017 20:17:08 +0000 http://ericasadun.com/?p=5773 How do I use result types? When using a Result enum for callbacks, how to access the Error?

The most common Result enumeration looks like this:

enum Result<Value> { 
    case success(Value), failure(Error) }

A Result is used almost exclusively in completion handlers. In synchronous code, it’s more common to use throwing functions rather than Result types:

do {
    let value = try throwingFunction(...)
} catch {
    ... handle error ...
}

A Result type replaces the (value: Value?, error: Error?) -> Void handler signature used by many Cocoa APIs with this single Swift enumeration. Handling this type requires a slightly different approach than you’d use with thrown error handling.

As a rule, if an error is generated on your behalf, pay attention to it and don’t discard it out of hand. Errors help identify underlying issues that you may be able to resolve. They also provide important information for the developer and end-user of why an operation has failed.

The switch statement provides the simplest approach to handle both result conditions with equal priority:

switch result {
case .failure(let error): 
    // handle error here
case .success(let value): 
    // handle success here
}

If the error handling code is significantly less detailed than the success code, you might choose to perform early exit instead of using switch. This approach allows you to handle any errors and then move on to processing the returned value at the top scope.

Use an if statement (not a guard statement) to bind error instances. Its primary clause should handle the bound error  and then leave scope.  If the result is success, the if-test will fail. Follow the error check with a guard statement to bind the success value.

if case .failure(let error) = result {
    // handle error
    return
}
guard case .success(let value) = result 
    else { fatalError("Success value could not be bound") } // this should never happen

// use value

This second approach allows you to promote the typically detailed steps involved in processing a value after extracting it from the Result enumeration. The guard‘s else clause is a little ugly but necessary. Swift doesn’t offer a “forced enumeration unwrap” similar to Optional‘s !.

Breaking the handling down into an if/guard pair is not as elegant as the unified switch statement, but it provides a practical way to promote the importance of the returned value.

Update: If the !! operator is ever adopted, you could extend Result to return a computed var value: Value? member, and then use !! instead of the guard/fatalError combo in the above example to create a streamlined early return / value handling approach:

if case .failure(let error) = result { ... }
let value = result.value !! "Success value could not be bound"

It’s a lot cleaner. See this PR for more details. (Thanks Dave)

]]>
http://ericasadun.com/2017/07/05/result-types/feed/ 6
Book: Year of No Clutter http://ericasadun.com/2017/07/05/book-year-of-no-clutter/ Wed, 05 Jul 2017 17:57:46 +0000 http://ericasadun.com/?p=5769

Year of No Clutter (Amazon, $9.99) felt like an aptly inspirational title to help motivate me to trim down my house. Like all techies and moms, I am surrounded by outdated equipment (that is occasionally useful) and boxes of “precious” artwork by my “artistically gifted” children, including single crayon scribbles on a page (post modernism) and several thousand RCA cables.

My kids lean towards hoarder tendencies. (“No, you can’t possibly throw that away. I drew it for you!” and “I won that precious partially-destroyed plastic trinket by playing carnival games all day!”). These I must fight with action, as reason goes only so far.

For me, I often lack the time to sort, organize, and toss my things that have become outdated, especially when there’s a real cost to replacing them when they’re eventually needed. (Quick, how many Firewire cables do you own? 30-pin iPod cables? I have too many, but sorting and disposing is hard.)

My go-to solution has long been to put things into boxes and then move them downstairs into the crawlspace. From “memory boxes” to “stuff I don’t use any more”, it’s become a desperate habit of clearing out space.

If I could, I’d go on a rampage throwing things out. The physical and time commitments to make this happen have been overwhelmingly daunting.

Schaub’s book reflects a slightly contrasting reality in that she’s taking on a different kind of clutter. Her Hell Room(TM) represented a “disposophobic” reality, of her well intentioned safety net. She freely calls it a “giant ridiculous mess”. It was stuffed both with items of potential use and necessary memory.  Each hoarded item had a history, and a story, and a connection to her life.

Her memoir offers an amusing tale of the steps in letting go. It’s a record of catharsis and finding the things that actually matter. If you’ve ever looked at a pile of ancient soy sauce packets, trying to decide whether to organize them or toss them, her story will resonate with your experience.

The most interesting thing about the book are the discoveries, where removing surface levels of clutter revealed real treasures and memories, allowing them the priorities they deserved. From family silver to handwritten letters, decluttering has a tendency to hit us in the emotions.

Throughout, Shaub scatters useful little charts and how-to’s. Things you use on a regular basis should have a place to live, and a regimen to restore it to that place after use:

In sum, the book is a conglomeration of reminiscences, self-reflection, how-to, and coaching. There are some delightfully amusing bits and some parts that kind of slog. I particularly enjoyed the section on “The Weirdest Things I Own”. I enjoyed it as a “library read” but I don’t know if I’d purchase it for re-reading.

I probably won’t ever match my own Mom’s ideal of “When in doubt, throw it out”, but the more control I take over our clutter, the better we’ve been able to function as a family.  I want to own things, not have my things own me.

]]>
Pronouncing “Tuple” http://ericasadun.com/2017/07/04/pronouncing-tuple/ http://ericasadun.com/2017/07/04/pronouncing-tuple/#comments Tue, 04 Jul 2017 21:55:48 +0000 http://ericasadun.com/?p=5764 A tuple is a finite ordered list of elements. It is presented as a parentheses-braced, comma-delimited list. In Swift, you can use them as stand-alone heterogenous lists of values or pass them as arguments to functions and closures.

A tuple is pronounced “tupple” (TUH-ple), not “two-pull”. It’s a shortcut pulled from “double, triple, quintuple, sextuple, octuple”, etc. Yes, please note that “quadruple” doesn’t fit with the others and is not used as a basis for speaking the word. Rules about long and short “u”s that apply to other English words are also not relevant to this case.

In Swift, a tuple is analogous to an anonymous struct. Its members are indexed numerically (.0, .1.2, etc). You can also use labels to access members by name:

let point = (x: 5.0, y: 2.3)
print(point.1) // 2.3
print(point.y) // 2.3

Swift 3.0 and later no longer supports splatting, so you cannot decouple a tuple from a function call. You can read more about this in SE-0029, which disallowed the ability. Before the change, you could call a function either with its direct arguments or by passing a tuple:

func foo(a : Int, b : Int) {}
foo(a: 42, b : 17) // still allowed
let x = (a: 1, b: 2)
foo(x) // no longer allowed in Swift 3+

The continued work on SE-0110 is still resolving on how tuples and closures interact.

The word “arity” describes the number of members in a tuple. (It also describes the number of arguments or operands accepted by a function, method, or closure.) The examples above use an arity of 2. You can call this a “2-arity tuple” or the shortcut “2-ary tuple”. Some shorten that further to a “2-tuple”.  All are acceptable.

Some fun facts to finish with:

  • A figurative tuple with an arbitrary arity is an “n-arity” or “n-ary” or “n-tuple”.
  • A tuple with a variable number of arguments is variadic.
]]>
http://ericasadun.com/2017/07/04/pronouncing-tuple/feed/ 8
Lessons Learned: iOS Extensions and Keychain Accessibility http://ericasadun.com/2017/06/29/lessons-learned-ios-extensions-and-keychain-accessibility/ Fri, 30 Jun 2017 01:45:03 +0000 http://ericasadun.com/?p=5761 Today’s lesson is courtesy of Rizwan Sattar, who writes:

If you’re building a notification service or content extension, keep in mind that these extensions will run even after a device restart, before the first unlock. Normally Apple recommends to set your Keychain items as kSecAttrAccessibleAfterFirstUnlock for “items that need to be accessed by background applications”. When you’re accessing the keychain for things in your notification extensions, you’ll want to set it to kSecAttrAccessibleAlways or kSecAttrAccessibleAlwaysThisDeviceOnly, etc instead.

Thanks Rizwan!

]]>