> actually implemented in-depth testing beyond the anemic xcode support
I think this is the key motivator for people looking at alternative architectures. My guess is most people wouldn't stray very far from basic UIKIt/MVC if the established practices weren't so hard to unit test.
I see the experimentation with alternative approaches as the iOS community going through a phase of maturity, and is a positive signal. Many people in the community care deeply about issues of code quality and testability and while striving for simplicity. The increase in iOS architecture related articles is an indication of unrest and an active search for better practices. I suspect that it is only through these experiments that we will discover the balance we are looking for.
Similarly, I think articles like the OP are a healthy resistance against the pendulum swinging too far the other way. Although I agree with several points made I'm disappointed that testability isn't even mentioned and thus many points ring hollow.
Maybe it's just me, but I find the "Tomatometer score" to be confusing. The combination of the tomato graphic with a number confuses an otherwise obvious rating.
I have a very strong (but false) intuition that the tomato graphic is a qualifier for the rating number. i.e. "Is this saying that 92% of people would throw tomatoes at this performance? Oh it's a fresh tomato...but wait, why would they throw tomatoes if they like it. Oh I see, the tomato is a lame representation of the rating, not saying something about the rating number."
Anyway, my false intuition is so strong that I still have to concentrate to ignore the tomato and simply look at the number (even if the number itself is controversial as noted by this discussion thread).
Except that rotten tomatoes are not green..they are deeper red in color than a fresh one. Plus, why throw tomatoes at all if you like a performance. For me it's a completely broken analogy.
The following is a link to the tool he is using in the video. I've adjusted things so that it is displaying CO right before the emission event. Advance the time by 3 hrs to see the difference.
I took a stab at this exact scenario years ago (1999?) and came to roughly the same conclusion. I ultimately decided to treat it as a travelling salesman problem where the distances between nodes (people) were weighted based on how recently they had matched with each node in the past.
This ultimately led me to create a TSP solving library that implemented a bunch of the known heuristic algorithms to approximate the solution. Worked out pretty well in the end and learned lots while I was at it.
It would have been interesting to see that heat map extend into Canada to see if the trend along the Rockies continued as expected. I found the following paper that at least anecdotally fits this theory:
Apparently Calgary is going through a suicide epidemic:
"suicides are the leading cause of death for boys and men 10 to 49 years of age, ahead of murder, traffic accidents, and all other causes of death in this age group"
Note that Calgary is at high altitude as well, roughly 3500 ft.
When you restrict to men between 21 and 65 you find suicide is one of the leading three causes of death, and often the leading cause of death, in many places.
California has better than US average rates for death by suicide, but that is because the death rate in older people is unusually low. When you look at rates for younger people you find california does slightly worse than the US average.
Calgary has also horribly cold winters which forces a lot of people to stay inside most of the winter. Maybe someone should do a correlation study with days/year where temperature doesn't exceed 20F (I know correlation != causation but at least it's one more hypothesis) . I personally feel depressed on days where I have to stay inside all day, and just taking a walk outside for half a hour uplifts my mood quite a bit.
Another strategy that I've often used is to just fix a few bugs that seem to be in the vicinity of the area you want to familiarize with. Heck, I even do this on my own codebases that I haven't touched in a while.
I find it helps focus the mind, provides a clear definition of success and forces you to think about a specific area of the code without requiring too much context.
This seems similar to what I've had to do with OpenCV in various iOS apps, but I think your results are more impressive than mine.
I had to sacrifice some quality in order to be able to do this with realtime video, but still, I should probably work out exactly what processing that command actually does and see if I can improve quality while still meeting the realtime requirement.
It describes the anticipated impact of the impending megathrust earthquake by examining the first moments, hours, days, etc after the event.
[0] https://www.cbc.ca/listen/cbc-podcasts/147-fault-lines