What these have saved me, more than time—although they’ve saved a lot of that, too—is my concentration, exactly as Cook says.
[…]
Another advantage of automation, one that Cook doesn’t talk about, is accuracy. No matter how simple a series of steps is, if it’s a dull, repetitive task, I will eventually screw up one of the steps and have to go back and fix it. I doubt that I’m unique in that way. Automation ensures consistency.
We learned several new ways to pick out a specific element from a collection. I found the discussion exhilarating and uniquely instructive. In particular combining for + where and for + case let were new to me. I am sure that I will soon find more uses for these.
Playing Code Golf in Swift is not about brevity, but mostly about beauty, elegance and code readability. Because of this I ended up with an approach that reads like plain english to me: “from the cell’s content view’s subviews, get the first element of type UISwitch”. Anybody can understand that.
I would lean towards a combination of Variant 6 and Variant 3. It probably doesn’t matter much for this particular case, but a reusable generic extension should not flatMap the entire collection just to find one element.
Update (2016-01-20): Arkadiusz Holko:
V. 6 can be even smarter by inferring generic from return type.
This is cool but seems risky and potentially confusing to me.
Eloy Durán (tweet):
In this post I’ll take you through a debugging session where I reproduce a crash, for which we were receiving a bunch of crash reports, but I was unable to reproduce by just using the application.
It will cover the following topics:
- Narrow down the breakpoint to the method invocation where the crash occurs.
- Locate the exact instruction that causes the crash.
- Look at the implementation of the method where the crash occurs.
- Simulate the crash.
