This is a 160+ pages book that could have been perfect as a 10 pages essay. Why do authors believe they need to cross the 100 page mark to give meaninThis is a 160+ pages book that could have been perfect as a 10 pages essay. Why do authors believe they need to cross the 100 page mark to give meaning to their work? I don't get it. 50 pages books are still books, guys. I think the long-windedness is particularly harmful to the cause of this immensely valuable practice, because it gives the false idea you need oh-so-much study to start being an effective code reviewer.
There were some good takeaways though: - code reviews are only good if they are effective at finding defects. So, studies cited here show that each code review session should be: (1) 1 hour max, (2) 400 lines max - simple strategy to avoid repeating mistakes: log every mistake you make and how many times. By just doing this, you'll soon anticipate the mistake and actually prevent it. They postulate this is true for any mistake, not just coding mistakes. Makes sense to me. - one of the big problems for code reviewers is finding what's not there. It's easy to spot a nil dereference crash, but can you spot that the developer forgot to call super in an override? Or that they called a method that's unavailable in a latest OS version? To approach this hard problem they suggest to use checklists. A reviewer would write their own list of things to check in every review, until they finally learn what to check. This is very pragmatic (not to mention pretty tedious) and I wonder if it can harmfully become the be-all-end-all of code reviewing. - look for one defect kind at a time throughout the whole code to be reviewed, then rescan the code looking for another kind of problem. This multiple pass system is kinda interesting, I should try it out.
The last chapter is a shameless plug for SmartBear code review tool. ...more
This book was my first exposure to collection views and I thought it did a great job at both introducing the subject as well as explaining it in depthThis book was my first exposure to collection views and I thought it did a great job at both introducing the subject as well as explaining it in depth.
The style is learn by example. The code samples are explained in their details throughout the book (often line by line) and I liked that the author never makes assumptions in these examples. Each one is pretty much self-sufficient.
I thought you are brought up to speed quickly, with one and half intro chapters that go very quickly, and a core chapter that explains all the basics minus custom layouts. So in about a third of this short book I felt like I had enough to start coding.
Roughly 2/3 of the book is about advanced layout techniques (overriding UICollectionViewFlowLayout, creating your own from scratch and doing things like circular layouts, toggling between layouts, etc) as well as adding interactivity (tap, pinch/zoom gestures, etc).
The author knows his stuff and the writing style is pretty terse, which I think is essential in a programming book (hey I got no time to lose).
My only complaint is that the author barely touched on the role of autolayout. A search for "autolayout" returns exactly 4 results; all layout in the examples is manual. It would have been good to at least discuss possible performance implications, especially for collection views with a lot of cells, dynamic cell heights, cells with complex view hierarchy....more
This book is mainly for computer scientists, not so much for engineers. The emphasis is first and foremost on theory and it didn't provide enough pracThis book is mainly for computer scientists, not so much for engineers. The emphasis is first and foremost on theory and it didn't provide enough practicality for me.
The choice of language for this book -- Standard ML -- is in line with the above: Standard ML is used in research but not as much in the industry as other languages like Haskell, Erlang, Clojure, Scala. How many people are you reaching with this choice? True, there is Haskell source code at the end of the book, and sure I can think of the reason why SML was chosen (being defined formally in a very concise way, leaving out implementation details, etc) but still, I can’t shake the feeling that this choice is somewhat elitist and limiting.
Plus SML is not even a pure functional language!
The other problem I have with this book is that the “purely functional” part of the title doesn’t come out as clearly as I wanted to. Could be it’s just me since I mainly code in OO languages, but after the first 3 chapters there’s a lot of data/state manipulation which resonated more as imperative than functional to me. (After all SML has some imperative features.) The initial chapters instead spent time bringing this out, and those are the ones I enjoyed the most.
I did take away something though: - the explanation of persistence vs performance was cool. At first this was confusing because what they refer to as persistence I call immutability. So, persistence requires that (e.g.) when joining 2 lists into one, the original lists need to be unchanged even if the joining operation should be performant. This requires copying the original lists but in practice only parts of the lists need to be copied. Very cool. - There’s a good run-through data structures I never once used professionally (binomial heaps, leftists heaps, red black trees, splay trees, …) so it was nice to read about them. - The explanation of amortization: for some collections where we need to perform some kind of processing on each item, we may not care if one item takes O(log n) or even O(n) as long as the overall computation is still O(n). - After studying the persistence + memoization + lazy evaluation + amortization theory it applied it to a queue implemented as 2 lists (front and rear), rotating its elements to amortize the cost of each insert/delete/etc operation to O(1). I didn’t have the time to dive deep into this but it’s something it’d be cool to do one day... If they ever translate this book to Erlang or some other purely functional language!...more
Pretty good introduction to TDD on iOS. Throughout the book an entire app (a basic StackOverflow browser) is built from scratch using TDD, covering alPretty good introduction to TDD on iOS. Throughout the book an entire app (a basic StackOverflow browser) is built from scratch using TDD, covering all its functional requirements. This included model and controller code. A long time is spent discussing UITableView and its data sources and delegates, which makes sense since they are such an important piece of UIKit. The author stops at the view level, so things like testing the positioning of UI elements in relation to others is not discussed.
I really appreciated the rigor with which TDD is employed here: the author is pretty relentless in the red-green-refactor mantra, designing mocks etc, although sometimes, especially while following the various table views callbacks, the testing code gets intricate and it's not exactly obvious how to write those in-depth controller tests.
The main drawback of this book is that it focuses on the testing framework bundled with Xcode, OCunit. OCunit does its job and it's well integrated, but I don't think it's the best testing solution available nowadays. Perhaps something more than a half page could have been spent on BDD; and perhaps a discussion about additions like OCMock or an analysis of other established testing frameworks could have been useful.
The biggest plus is that after reading this you want to do TDD! Yes you're going to have to invest some time on it to get used to it, but I liked how the author stressed that the payoff on overall quality (OO design, stability, maintainability) is gonna be big....more
The book is not for complete novices to programming: e.g. the while loop is explained in 2 lines. Syntax diagrams are used to explain every construct. However, if you have programmed in other languages but know nothing about JS, you should be able to follow along just fine.
The "not recommended" parts of the language are still presented in 2 chapters (with explanations about the nature of their evil): the "bad parts" and the "awful parts."
When I was at Oracle, I was asked to code a bunch of stuff in PL/SQL. I knew SQL, but never done anything in PL/SQL. This is the only book I read, andWhen I was at Oracle, I was asked to code a bunch of stuff in PL/SQL. I knew SQL, but never done anything in PL/SQL. This is the only book I read, and it was enough....more