Archive for the ‘Tricks of the Trade’ Category

Pattern match style filtering

I’ve written about this before, but a question came up recently that I thought was worth posting, as it’s a much simpler case than the one I wrote about last year.

Byrre_b asks:

Is there any way to write “pattern matching style filtering” in a better way then using a complete `if case` statement?

Such as:

let values: [NonEquatableEnum] = [...]
let filtered = values.filter { val in
    if case .thatOneInterestingValue = val {
        return true
    }
    return false
}

Note: Several people have pointed out if the enumeration is equatable, just use == rather than pattern matching. You can match case, even with associated values with, e.g. if case .foo = value.

You can filter using the pattern match operator, as shown here, or for equatable enumerations with ==.

enum NonEquatableEnum { case nah, blah, thatOneInterestingValue }

let values: [NonEquatableEnum] = [.nah, .blah, .nah, .thatOneInterestingValue, .nah, .thatOneInterestingValue, .blah]
let filtered = values.filter({ $0 ~= .thatOneInterestingValue })

Although this stores all values matching your subject case into filtered, the results aren’t very meaningful unless you want to count how many instances of .thatOneInterestingValue appear. That’s because filtering by enumeration case is usually limited to two situations:

  • You’re working with a structure and using the enumeration as a tag for filtering
  • You’re working with associated values and want to collect the enumeration cases and then extract the values.

The first of these is made simple with Swift 4 key paths. For example, consider the following structure:

struct Foo {
    var (x, y, z) = (0, 0, 0)
    let numnum: NonEquatableEnum
    init(_ n: NonEquatableEnum) { self.numnum = n }
}

let values2: [Foo] = [Foo(.nah), Foo(.blah), Foo(.nah), Foo(.thatOneInterestingValue), Foo(.nah), Foo(.thatOneInterestingValue), Foo(.blah)]

Assuming each instance has some more interesting data than the default (0, 0, 0) triple, pull out tagged instances using the same filter approach:

let kp = \Foo.numnum
let filtered2 = values2.filter({ $0[keyPath: kp] ~= .thatOneInterestingValue })

The key path lets you “dive” into each struct to test the enumeration member, while preserving the data stored in the other structure members. Instead of just counting how many instances of a simple enumeration there are, it acts as a meaningful filtering operation.

The second challenge, retrieving associated values, is more complex, as explained in my original write-up. Hand-crafting a result with if case gets you the values you need.

enum MoreComplicated {
    case one(Int)
    case two(Int)
    case three(String, String)
}

let values3: [MoreComplicated] = [.one(3), .two(5), .two(2), .three("hi", "there")]

Here’s an example that pulls out the case three enumerations:

let results2 = values3.filter({
    if case .three = $0 { return true } else { return false }
})

If you want to filter and extract at the same time,  add let declarations into your if case statement and switch the filter operation to a flatMap :

let results3 = values3.flatMap({
    (value: MoreComplicated) -> (String, String)? in 
        guard case .three(let x, let y) = value
            else { return nil }
        return (x, y)
    })

This returns an array of tuples, containing the associated values for each matching enumeration case.

Thoughts? Improvements? Fixes? Drop a note, tweet, or email to let me know!

How to check your security update

A macOS Security flaw opened access to users who didn’t have root passwords. So Apple updated computers overnight

Unfortunately Security Update 2017-001 turned out to bork file sharing, so Apple updated the problem both by issuing repair instructions and updating the patch.

To check whether you have the proper build, choose Apple Menu () > About This Mac. Click the System Report button and scroll down to Software. Click the word Software. You should be running 17B1003.

Thanks everyone.

p.s. Esopus Spitzenburg is my Mac mini. My MBP is Broxwood Foxwhelp. And yes, I’ve long since gone past Fuji, Gala, Rome, Honeycrisp, Pippin, Winter Banana, and many other varietals.

The Perfect QA Recruitment Filter

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)