Apple is Wrong! (In this small way)

How should you section off your delegate (and datasource) methods? I have seen (so far) two ways that Apple does so in their templates:

  1. ‘Brief’ Format:

// MARK: - Table View

2. ‘SeparateComponentsWith ” ” ‘ Format:

// MARK: - Table view data source

What this misses:

  • Firstly, the idea of having a plain-English pragma mark does not make sense – we should not be reading the pragma marks — not when there is an immediately recognizable heiroglyph such as UISomeAPIiKnowBySight.
  • Secondly, this version…

// MARK: - UITableViewDataSource

…can be ⌘-clicked to take you to the docs and/or implementation of the API in question, which makes so much sense – put the instructions next to the tools in case they are needed.

So I change all boilerplate templates to conform their respective APIs. While those two reasons are not earth-shattering, they are compelling enough that I will not forget (or rather, can ‘re-derive’) which convention I adhere to, consistently. Consistency in coding is a very powerful contributor to readability, so sign me up.

So, who is going to let Apple know that they got this one wrong?

 

Book Review: The Swift Developer’s Cookbook, by Erica Sadun

240 pages, Addison-Wesley Professional, 1st ed (19 Dec 2015)

tl;dr

In sum, if you are a moderately experienced in Objective-C, this petite volume covers basically the same ground as Apple’s Swift Programming Language, but written in a problem-solution style, with the added value of her non-Apple perspective — oh, and did I mention that she does this all in 1/3 of the space (~200 pages to SPL’s 600+). The title “Swift for the Really Impatient” is apparently already taken, but would fit this book quite well. Highly recommended, if you’re her target audience.

—-

Are you an Objective-C developer looking for an advanced primer to dive into Swift? Then look no further. Erica Saudi’s slim volume is densely packed with well-written code that tersely explains (a) how to do Objective-C tasks in Swift syntax, and (b) how to avoid that road, and take advantage of Swift to accomplish those tasks Swift-ly.

Those who have read her other books, such as iOS Autolayout Demystified, or follow her blog, know you are in good hands with a professional who has a deep and intimate knowledge of the inner workings of the Cocoa APIs, and like a good tour guide, can point out common hazards to avoid as she takes you on the safe path. Moreover, she provides ‘historical’ context about what came before. And throughout are little gems of humor.[1]

This book is not for everyone, but it may very well be for you. It is certainly not for fresh beginners, and it is not for someone looking to learn iOS programming or APIs. Myself, I have been programming in Objective-C for about a year now, and just completed my first Swift project when I got my hands on the book, which I saw as a time-saving alternative to scouring the tech-blogosphere and weeding out the Swift 1.x stuff from the Swift 2.x. Rather than read it cover to cover, I read the chapter I needed to bone up on, or searched the index — and in this regard, it works quite well, as a ‘cookbook’ should (though it is not really a cookbook, as I’ve seen the term used, such as in “The iOS Developer’s Cookbook” by the same author — the code provided are mostly of snippet-length).

In sum, if you are a moderately experienced in Objective-C, this petite volume covers basically the same ground as Apple’s Swift Programming Language, but written in a problem-solution style, with the added value of her non-Apple perspective — oh, and did I mention that she does this all in 1/3 of the space (~200 pages to SPL’s 600+). The title “Swift for the Really Impatient” is apparently already taken, but would fit this book quite well. Highly recommended, if you’re her target audience.

Note that this cookbook is focused on Swift, not Cocoa, as in the iOS Developer’s Cookbook by the same publisher. Double-check the table of contents to make sure it covers the topics you require.

[1] My favorite:
“Uppercase function names are immediately distinguishable from methods but are currently out of fashion. This practice was quite common up to and including name-spacing, when it suddenly went extinct. It’s like a million capitalized voices cried out and were suddenly silenced.”
(p.68 / Kindle Locations 2086-2088).

Full Disclosure: I purchased a dead tree copy of the book for my own edification. Subsequently, I was offered a free copy in exchange for an honest review, which got me the electronic version. So, to be honest, I have issues with all programming e-books and how they fail to display code in a helpful manner (read: syntax highlighting!). Dead trees win in that regard, which boggles the mind. But I love having the e-book for searching. I would buy far more books like these if there was an e/tree bundle that was *less* than, say, the price of two full copies!

Make Recipes of ALL The Projects!

An Argument to For Prolific Recipes From Everybody

Hello, Joe Programmer. Welcome to my blog. You have just finished writing your app for using whalesong to solve Fermat’s Last Theorem, or just finished your first program (Tic Tac Toe, right?). Doesn’t matter. Share it with the world.

This ocelot learned to code from recipes. No humans were harmed in the taking of this photo.

They will not thank you in your lifetime, but future generations of supermen/bots will praise your name or its binary equivalent for having hastened the coming of the wired future. What I’m saying is, even if you are not a teacher, not a job-seeker, or not even There Yet, share your code. But in a specific way. The way that is both Lazy and Helpful: Recipes.

What I’m saying is, even if you are not a teacher, not a job-seeker, or not even There Yet, share your code. But in a specific way. The way that is both Lazy and Helpful: Recipes.

 

What is a Recipe?

A recipe is code that is complete, bug-free, and can be compiled as is. It is code that is wrapped in a certain format, like so:

Title //write this last

Problem //1-3 sentences of a real or hypothetical problem

Solution //1-5 sentences of the approach, technique, or core “new” thing demonstrated by the code.

How It Works // (optional) This is not optional. Rather, when it is needed, it is necessary, but that isn’t always the case. This is the place where you explain ahead of time that line or two with the wonky syntax that even a read-through of the docs does not enlighten. Granted, if you need visuals (storyboard), you may be forced to upload a screenshot or two, but often this can be avoided through a few more sentences. Lift one pinky, or two?

…let’s be honest here – you already wrote this code. It is written. 95% of the work is done.

The Code //The magic sauce. All the hard work has been done before this. All that hard word in crafting a Title + 2-10 sentences will pay off, in that you have now prepared your reader for — let’s be honest here — a code dump. You already wrote this code. It is written. 95% of the work is done. You cut and paste it into a new project. You link it to github. You give it a one-over to prettify it (e.g., XAlign), delete all the distracting commented-out sections, and turn your terse comments into full sentences. That’s it. It’s done. Publish!

[Pro-Tip: This can be fulfilled with a very helpful ReadMe added to the code’s Github repo]

Why I Feel So Strongly About This

Implementation is so often the hardest part of any project. Students learn from the little things. “Oh, I see, @selector(someMethod:) has a colon because it takes an argument! That’s why my code has been broken for the last 3 hours! God bless you <#dear reader#>, bless you!” That sort of thing. The things that are so easy to overlook when you know it, but so hard to emulate when you do not.

Tutorials are hard to make. They are designed to hold someone’s hand and take them from point A to pointilliste Beta Prime. A recipe is easy. It rolls out of bed and into your blog, and the world is a better place. So do the right thing. Make the world a better place today. You descendent nanoboticles will thank you.

Principles of Object-oriented Programming: Why SOLID?

SOLID for Newbies

Future Principled Programmer

As a newly hatched programmer, comparing notes comes second nature to me. How can my code be more legible (but not verbose), elegant (but not clever), and defensive (but not paranoid)?

The easy rule of thumb passed down by my instructors has been “Make it work, make it right, make it fast”, a phrase that has been associated with a design paradigm that has come to be known as ‘agile software development‘ (and the wikipedia page). (see sidebar [under construction].

But the assumption underlying that phrase is that you will be refactoring multiple times. How can we make sure our code can even be refactored? The object-oriented programming  (OOP) paradigm can make things either worse or better by separating chunks of code into blocks of associated functionality. One of the nifty mnemonics for a series of ‘principles’ that guide in the right direction are what are known as The SOLID Principles of OOP.

SOLID Principles of OOP

S)ingle Responsibility Principle

“There should never be more than one reason for a class to change.”

Example: If your building closes a floor for renovations, you should only need to modify one class in your elevator’s program–and that the class should only need to be altered when floors are added or deleted.

That said, a word of caution: some programs are small, or simple, and it would be possible to subdivide endlessly for variations and potentialities that may never happen.

Open/Closed Principle

Classes/functions should be open for extension, but closed for editing/modification. It should be usable “as is”. Never modify them, just extend them.
Because it’s very messy, and would probably ruin the coat.

[credit: Betrand Meyer (1988).]

This is done by abstraction. E.g., a drawing class should not implicitly mean to draw with a black pen on paper. Rather, it should be to draw with something onSomethingElse. Then I could draw on paper, or even on nothing (maybe you want your SimPersons to do the wave, or dance to YMCA) through a simple extension overlaying the draw class.

Liskov Substitution Principle
Subtypes must be substitutable for their base-types.
Your Duck superclass will crash when it tries to fly the eDucky even though Batteries Not Included (for Ducks).

Technically, this can be expressed as:

Don’t introduce new behavior into a subclass that the base class couldn’t do.

E.g., you have a Bird Class, and a Duck subclass. Any Bird can fly with any Duck. But say you add a Penguin subclass.  A call to the [Bird fly] on a Penguin will crash your program, since Penguins cannot fly.

Without help, that is.

 

A cool corollary of this is that if you follow the LSP, you implicitly are adhering to the Open/Closed Principle. LSP => OCP

Interface Segregation Principle

Classes that implement interfaces should not be forced to implement methods they do not use.

Use small interfaces, not “fat” ones.

Reset and Write for streams, but not for Write-Only (Printers) or Read-Only (Screen).

Dependency Inversion Principle

a) High-level modules should not depend on low-level modules — both should depend on abstractions.
b) Abstractions should not depend on details – rather, details should depend on abstractions.

E.g., Xcode’s SVC depends on GIT? Bad. Xcode’s SVC uses GIT? Good.

Xcode –> SVC interface –> GIT

E.g., MVC.

We can test modules independently of each other. We can mock or fake interfaces to test the business logic.

Print {with logic x} to {appropriate source}

Print…to file…to PDF…to email client…to printer.