Archive for April 10, 2018

Tuesday, April 10, 2018

Overture: a Swift Library for Function Composition

Point-Free (via Matthew Johnson):

This library was created as an alternative to swift-prelude, which provides these tools (and more) using infix operators. For example, pipe is none other than the arrow composition operator >>>, which means the following are equivalent:

xs.map(incr >>> square)
xs.map(pipe(incr, square))

We know that many code bases are not going to be comfortable introducing operators, so we wanted to reduce the barrier to entry for embracing function composition.

OkCupid’s “Removed” Visitor API

Zack Whipkey (via Hacker News):

She boasted about being able to use the now removed Visitor feature of OKCupid through their JSON API, polling it to see who was looking at her profile throughout the day. […] A few weeks ago, I hit the same API using okcupidjs, a library developed by Hung Tran, and I was floored at the data that provided.

[…]

On March 29th, I contacted OKCupid to report the issue, and asked why so much unnecessary data was being provided. OKCupid responded within 6 hours, telling me that they confirmed the issue and removed access to the visitor API endpoint. This is fast in the world of responsible disclosure, and I give them kudos. However, they gave no answer for why unnecessary data was being provided.

[…]

The statement “Your zip code will not be public” was blatantly false.

Apple Now Runs On “100%” Green Energy

Mark Sullivan:

“You could go out and buy carbon credits and offsets–nope,” says Jackson firmly.

[…]

“I am not aware of any other company that uses that same stringency for making sure the clean power that they’re investing in or purchasing is on the regional grid where it’s being used,” she boasts. But she acknowledges that there are still places in the world where that’s not possible, though that may have more to do with the reality of power markets than choices Apple has made. In some cases, the company has had to sign long-term contracts to acquire the RECs from a new project it helped create elsewhere in the same region. That was the case recently for a two-person office in Chile. There was no suitable green energy source nearby, so Apple is now offsetting the brown power used by that office with RECs from one of its green-power projects in Brazil.

This sounds like a reasonable thing to do in that situation, but if Apple is relying on credits/offsets I don’t think they should claim to use 100% green energy. That would imply that they can run without any brown power, which doesn’t seem to be the case. There are also questions about what the Apple stores in Nova Scotia, Perth, and Anchorage are doing.

The article also doesn’t make clear exactly what happens in areas where renewable energy may not be reliable around the clock. Are they storing solar energy in batteries during the day to use at night? Or is the “100%” a net figure meaning that enough extra is produced during the day to balance out the nighttime use? If the latter, that is really misleading.

Tim Cook:

Every Apple store, every data center, every Apple corporate office — everywhere — is now powered by 100 percent renewable energy.

I wish Cook would stop overreaching. He could be proud of what Apple has accomplished here without claiming more than it’s actually done. Just like he could have said that Apple was paying the taxes required by law without also claiming not to “depend on tax gimmicks”. Or he could have defended the reasoning behind the iPhone battery throttling without claiming that Apple had explained it when iOS 10.2.1 was released.

Towards Robust Performance Measurement

Pavol Vaskovic:

When measuring the performance impact of changes to Swift, the CI bots run the benchmark suite two times: once to get the baseline on the current tip of the tree and again on the branch from the PR. For this, the Benchmark_Driver runs set of 334 performance tests (some are excluded because they are considered unstable) and gathers 20 samples per benchmark for optimized binary and 5 samples per benchmark for unoptimized binary. With ~1s per sample, this results in minimum of 4,6 hours to execute the benchmarks (not counting project compilation). This means that full benchmarks are requested rather rarely, I guess to not overburden the CI infrastructure. Recently reviewers switched to asking Swift CI to please smoke benchmark, which only gathers 3 samples per optimization level, reporting benchmark results in about 1 hour.

Performance test results reported by CI on Github often show false regressions and improvements, forcing the reviewers to perform frequent judgment calls. Even though there are 137 benchmarks excluded from the pre-commit test because they were considered unstable, the Swift benchmark suite does not appear to be exactly stable…

Sometimes improved compiler optimizations kick in and eliminate main workload of an incorrectly written benchmark but nobody notices it for a long stretches of time. Usually the non-zero setup work masks the problem because it prevents measured time from dropping to zero. There is no publicly visible tracking of performance results from the benchmark suite over time that would help prevent this issue either.

Pavol Vaskovic (via Erica Sadun):

Given the fact Swift Benchmark Suite is a set of microbenchmarks, we are measuring effects that are manifested in microseconds. We can significantly increase the robustness of our measurement process using statistical methods. Necessary prerequisite is having a representative sample population of reasonable size. From the experiment analyzed in previous sections it is apparent that we can make the measurement process resilient to the effects of varying system load if the benchmarked workload stays in range of hundreds of milliseconds, up to few thousand. Above that it becomes impossible to separate the signal from noise on a heavily contested CPU.

By making the run time small, it takes less time to gather enough samples and their quality is better. By staying well under the 10 millisecond time slice we get more pristine samples and the samples that were interrupted by context switching are easier to identify. Excluding outliers makes our measurement more robust.

After these resilience preconditions are met, we can speed up the whole measurement process by running it in parallel on all available CPU cores. If we gather 10 independent one-second measurements on a 10 core machine, we can run the whole Benchmark Suite in 500 seconds, while having much better confidence in the statistical significance of the reported results!

App Store Subscriptions And You

Daniel Kennett (tweet):

What makes this more difficult is that right now, App Store subscriptions for “normal” apps (i.e., those that aren’t content services like magazines or Netflix) are reasonably new, and Apple appears to be finessing the rules over time. This can cause a frustrating situation as you try to do your best but end up getting repeated rejections due to your app not meeting the rules.

At the time of writing, I’ve been shipping an app that uses subscriptions for eight months, and have had multiple subscription-related rejections happen between my first release and now due to changing rules and changing enforcement of existing rules. The information in this post is a combination of my experience, as well as conversations with App Review both via email and phone. Hopefully the additional context provided by speaking to a human being from App Review on the phone will be as helpful to you as it was for me.

Erasing Complexity: the Comfort of Apple’s Ecosystem

Federico Viticci:

Probably for the first time since I started MacStories nine years ago, I feel comfortable using Apple’s services and hardware extensively not because I’ve given up on searching for third-party products, but because I’ve tried them all. And ultimately, none of them made me happier with my tech habits. It took me years of experiments (and a lot of money spent on gadgets and subscriptions) to notice how, for a variety of reasons, I found a healthy tech balance by consciously deciding to embrace the Apple ecosystem.

[…]

It’s possible to like something and still point out its flaws. This is an unpopular opinion both among those who think Apple can do no wrong, as well as folks who think they’ve done nothing important after Steve Jobs. I strongly believe that both extremist camps are misguided.

More than ever, consumer technology choices come down to picking the compromises we’re willing to accept and the best overall experience for us. These two sides aren’t mutually exclusive. For instance, you can love the Nintendo Switch and still think that the lack of a Virtual Console and cloud saves is downright user hostile. You can be a fan of Spotify’s remarkable intelligence, but also find its user interface design uninspired. You can recognize the fact that Siri should be substantially improved – if not rebuilt altogether – but also like it for the things it gets right today.