So I wrote a book about performance...

...specifically iOS and macOS Performance Tuning: Cocoa, Cocoa Touch, Objective-C, and Swift. Despite or maybe because this truly being a labor of love (and immense time, the first time Addison-Wesley approached me about this was almost ten years ago), I truly expected it to remain just that: a labor of love sitting in its little niche. So imagine my surprise to see the little badge today:

Wow! Number #1 new release in Apple Programming (My understanding is that this link will change over time). And yes I checked, it wasn't the only release in Apple books for the period, there were a good dozen. In fact, iOS and macOS Programming took both the #1 and the #4 spots: Oh, and it's also taken #13 overall in Apple programming books.

So a big THANK YOU to everyone that helped make this happen, the people I was allowed to learn from, Chuck who instigated the project and Trina who saw it through despite me.

Anyway, now that the book is wrapped up, I can publish more performance related information on this blog. Oh, the source code for the book is on GitHub.

UPDATE (March 5th, 2017): Now taking both the #1 and #2 spots in Apple new releases and the print edition is in the top 10 for Apple, with the Kindle edition in the top 20. Second update: now at #5 and #21 in overall Apple and #1/#3 in new releases. Getting more amazing all the time. I should probably take a break...

Concept Shadowing and Capture in MVC and its Successors

In a previous post, I noted that Apple's definition of MVC does not actually match the original definition, that it is more like Taligent's Model View Presenter (MVP) or what I like to to call Model Widget Controller. Matt Gallagher's look at Model-View-Controller in Cocoa makes a very similar point.

So who cares? After all, a rose by any other name is just as thorny, and the question of how the 500 pound gorilla gets to name things is also moot: however it damn well pleases.

The problem with using the same name is shadowing: since the names are the same, accessing the original definition is now hard. Again, this wouldn't really be a problem if it weren't for the fact that the old MVC solved exactly the kinds of problems that plague the new MVC. .

However, having to say "the problems of MVC are solved by MVC" is less than ideal, because, well, you sound a bit like a lunatic. And that is a problem, because it means that MVC is not considered when trying to solve the problems of MVP/MVC. And that, in turns, is a shame because it solves them quite nicely, IMHO much nicer than a lot of the other suggested patterns.

It turns out that MVC is, just like Algol an improvement on most of its successors.