Sound Off Round 4: Live-Captioning Open Source & Feelings

From Sound Off:

Open Source & Feelings has a thorough and unambiguous code of conduct, one of the best diversity statements we’ve seen from a conference, and an about page with everything from venue accessibility, to public transit, to tips about keeping safe while traveling to and from the conference. Everything about Open Source & Feelings communicates thoughtfulness, deliberateness, and listening to feedback.

Donate now to help out this good cause.

Sound Off board member Ashley Nelson-Hornstein explains how live-captioning is useful for all physically-present attendees, not just for people you’d expect to need the help.

It’s also worth remembering that accessibility issues aren’t just something for a small percentage of the population.

Everybody has — or will have, if they live long enough — something they need help with. I have increasing trouble hearing, and live-captioning would certainly help me, and maybe you too.

Straight up: help make sure everyone can participate.

PS The conference will be here in Seattle, at Seattle Central College. I was on the college newspaper there, in moons past.

My Rules for Mutable Foundation Collection Objects

I have some simple rules that I always follow when dealing with mutable Foundation collection objects (plus mutable strings) in my Objective-C code.

Construction

I often use a mutable collection object when constructing a thing — array, dictionary, set, or string — and then pass it somewhere else.

Once it’s passed, ownership is relinquished. The construction code never continues to hold a reference to the thing it made.

Wherever that thing goes it’s treated as immutable (whether or not it really is).

No mutable collection objects in APIs

In my .h files, under no circumstances are properties or parameters allowed to be mutable collection objects.

(Or, well, it’s extremely rare. There could be a utility API that takes a mutable thing, but that API does some kind of work that doesn’t retain that collection, so it can’t mutate it later on.)

Mutable collection objects are internal to a .m file

An object may use mutable collection objects internally, but those aren’t allowed to escape the .m file they live in. There’s no chance, then, that one of these could be mutated without its owner knowing about it.

* * *

By following these rules — which, after all these years, I do without even having to think — I never run into an issue where I’ve passed a mutable array (or whatever) to another object, then held on that array and mutated it. It just can’t happen.

But, really, whatever — these days I write Swift code instead.

Copy vs. Strong NSArray Properties

At work this morning I added a property to an Objective-C object that looked something like this:

@property (nonatomic, strong) NSArray *someArray;

And then it was suggested to me that copy would be better than strong in this case.

I have nothing against copy — but with an immutable array, is that really necessary? The array can’t change, so why copy it?

Well… that’s not strictly true. A caller could use an NSMutableArray — which would be perfectly valid — but then hold on that array and mutate it later on, which would be dumb.

So I ask: who would write code like that?

It’s not a class of mistake that I personally make. (I’ve internalized this so completely from years of writing Objective-C. I do make other classes of mistakes, of course.)

And then I think “Who would write code like that?” is the wrong question. The real question is, “Why wouldn’t I write code that minimizes the effect of a possible mistake?”

(Or even not a mistake. It could be entirely legitimate that the caller has a mutable array that it holds on to and mutates later on.)

* * *

This makes me wonder about the difference between code I write for myself and code I write as part of a team. Since I know that I wouldn’t make this particular mistake, I can safely use strong instead of copy in my own code.

But, really — sharp right turn here; buckle up! — doesn’t it make me wish everything was already in Swift, so we’d have the safer behavior automatically?

Yes. Yes it does.

My personal projects are mostly in Swift — converted to Swift 3 already — but, for obvious reasons, at work we often write new code in Swift but still have a large Objective-C codebase.

What I don’t need in life — because it adds complexity, and I don’t have time for that — is three separate coding styles: Swift, my Objective-C, and work Objective-C.

The only one I can get rid of is “my Objective-C.”

Okey-doke.

So Merlin Says to Me…

I saw Merlin Mann before the Talk Show last Tuesday, and he thanked me for letting him play in my internet treehouse.

I completely misunderstood. He was talking about a small and specific thing (I realized later) — while I thought, at the time, he was doing a thing Merlin would do, which is to thank a software developer for helping to build up the world of blogs and podcasts where Merlin does, indeed, get to play (and be awesome at it).

(What you don’t know about Merlin — or maybe you do — is that he’s one of the best at liking people. It’s creativity and Jonathan-Winters-meets-James-Joyce — but mainly effort and empathy. So he would say what I thought he said.)

Anyway, my answer didn’t make any sense, surely, when I said, “We built it all for you.”

(Because he’s thinking of this one small thing and I’m thinking of the web.)

But it struck me that, as a reply to what I thought he said, it was absolutely correct. We — and I mean me and many thousands of people like me — worked hard to make the decentralized web, the web of blogs and podcasts, a place where all the Merlins would thrive.

Blogs are the Pad Thai, the rib-eye steak, the bowls of spaghetti of the web. Podcasts are the mashed potatoes, the tacos, and the hummous. You could get by for a little while with Skittles (Twitter) and peanut butter cups (Facebook) — but eventually you need something more filling, something you can sit down with and take your time.

* * *

I realize that decentralized-web fanatics are often looked at as if we’re the Libertarians of the web. Or the crazy-conspiracy-theorist-uncles. Or as if we’re stuck, sadly, in a rosy past and we won’t move on.

Think whatever you will. But wonder if, if all this goes away, could there be any more Merlins.

A Meaningful WWDC

Last year I was all set to go to WWDC — or, rather, to everything but the actual conference — with plane tickets and hotel rooms booked. I was going to speak at AltConf and play with the Breakpoints and hang out with old friends and make new ones.

But, right before, my father-in-law died of complications from the treatment of a year-long illness. We thought he would get better, and then he didn’t. (This is what prompted my In the Room post of last October, even though that talked more about my grandfather.)

I was very close to my father-in-law. He lived nearby, in the suburbs, and he was a big part of my life for 25 years.

Naturally I canceled my trip.

When he died, it was already clear that my mother-in-law was also sick — for entirely different reasons, and entirely coincidentally. So we went from one to the other without a break. I was as close to her as I was to him, and she died this past January.

Both were too young, and both had been marvelously healthy and energetic — and I still keep forgetting that they’re not just traveling or something and I’ll see them soon, and then I remember.

* * *

So this WWDC represents something for me. I missed it last year, but this year I can go and have fun — and that’s a real thing.

I’ll speak at AltConf, play with the Breakpoints, and hang out with old friends and make new ones. Same as last year would have been, but this year it’s different. Knowing that I missed it, but that I get to go this year, is helping me in a way it’s never had to help me before. It means something. And I thank everyone in advance just for literally being in SF at the same time as me next week.

Seeking Clarification

I have a side project, a Mac app, that I could also do as an iOS app. I have no plans to do so — but the news about subscriptions and free trials makes me reconsider.

It might be sustainable with this new model.

But here’s the thing: the app is a stand-alone thing. I’m not running a backend web service for it. Would it be okay to use the subscription-based pricing? Here’s what Apple says:

Starting this fall, apps in all categories on the App Store will be eligible to offer in-app purchases for auto-renewable subscriptions to services or content. Users enjoy the reliability that comes with subscribing to a service that they love, and the experience must provide ongoing value worth the recurring payment for an auto-renewable subscription to make sense. Although all categories of apps will be eligible, this business model is not appropriate for every app.

What does “not appropriate” mean? Does that mean rejection? Or is that just a warning that it’s maybe not the best fit, but it’s okay to try it anyway?

The Clean Screen Habit

I’ve spent years of my programming career on a team of one, and I ended up developing some idiosyncratic habits.

One of them could be called the “clean screen” habit. Here’s the scoop:

Xcode’s warnings and errors pane has to be clear at all times. If anything appears there, it has to be dealt with immediately. I enforce this in part by turning on treat-warnings-as-errors, so I’m forced to deal with everything.

Also: anything that appears in the Console pane must be dealt with immediately — that is, any message must be some kind of assertion failure or notification that something bad has happened. Otherwise it must be kept clear (with the exception of temporary caveman debugging).

Having these two panes clear tells me that the baseline health of the project is good. And it ensures that when something does appear, it’s an extraordinary event that I can’t miss — and can’t miss dealing with.

* * *

You could argue that this is pointless and fussy. After all, this doesn’t do anything to prove that the app is well-architected or that I’ve chosen good algorithms or that it uses memory efficiently.

But that’s like saying showers are worthless because they don’t make you a snappy dresser. Cleanliness is just a start, but it’s a good and necessary start.

Oldie Praises the Old Old Ways

Swift’s support of inner functions is one of my favorite features of the language.

Years ago, back in the ’90s, I used to write in UserTalk, the language that powered UserLand Frontier. It was a procedural scripting language — but remarkable for its integration with Frontier’s hierarchical, persistent database. (Storing a string in the database, for example, was just a matter of assigning to a location: foo.bar = "baz".)

In the early days of web programming, we’d often build a page just by appending to a string. In UserTalk it looked something like this:

on buildPage()
  local (htmlText)
  on add(s)
    htmlText = htmlText + s + "\n"
  add("<html>")
  add("<head>")
  // …build the rest of the page…
  add("</body></html>")
  return htmlText

The on add(s) bit was the inner function, and it could refer to variables in its enclosing scope.

That’s a simple example, of course — we did more with this feature than just appending to strings, but it gets the idea across.

Objective-C

Before we get to Swift, let’s start where I started, with Objective-C.

Some time last year I wrote a macro processor. The API looked something like this:

@interface MacroProcessor : NSObject

- (instancetype)initWithText:(NSString *)text values:(NSDictionary *)d;
@property (nonatomic, readonly) NSString *processedText;

@end

That’s not an uncommon pattern. Initialize an object with some input, and then get the result (via the readonly processedText property).

I’d call it like this:

MacroProcessor *macroProcessor = [[MacroProcessor alloc] initWithText:text values:values];
NSString *processedText = macroProcessor.processedText;

It sure just looks like a function call at that point, right? But weirdly split up into two lines.

So I added a C function to the API to make this more explicit:

TextWithMacrosProcessed(NSString *text, NSDictionary *values);

Now I could call it like this, instead:

NSString *processedText = TextWithMacrosProcessed(text, values);

That C function just wrapped up the two lines (alloc-init MacroProcessor and return processedText).

(I could have, alternately, made a class method on MacroProcessor. Either way’s fine.)

Then I thought: well, I have the API I want — a function call — so there’s no need to make initWithText and processedText public, so I removed everything but that C function from the .h file. Great. Fine.

That’s the beauty of interfaces, right? The important part is to get the API right. How it works under the hood (creating an object, etc.) is an implementation detail.

I could have stopped there.

But I didn’t stop there

Let’s be clear: MacroProcessor had unit tests and zero known bugs. It had no side effects. It was good, solid code. A smart developer just moves on to work on something else.

But, since this was part of a Ranchero project (not an Omni app) with no ship date and no hurry, I could allow myself some extra time.

Even though I had the API right, it bothered me that the implementation didn’t feel quite right. After all, if the API is a function, wouldn’t it be ideal if the implementation was also a function?

Is that even possible? I looked at the structure of MacroProcessor, and it was what you’d expect: three properties (initialText, values, and processedText) and a handful of methods.

For some reason it flashed in my head how I’d do this in the old days, back when I was writing UserTalk. There’d be a function with some local variables, and some inner functions that did things, and it would return the final processed text. Like that buildPage example above.

And it occurred to me that the structure is actually the same: some functions have access to variables that nobody else has access to. Whether that’s an object, or it’s a function with variables and inner functions, amounts to the same thing.

So I approached it that way, and wrote it like I would have in the old days (only in Swift this time), and it worked perfectly. (Still has unit tests, zero known bugs, and no side effects.)

And the API is now textWith​Macros​Processed​(text: String, values: [String: String]) -> String, and the entire thing is just that one function. No object needed.

Good old days, bad old days

So one day I talk about how I don’t want to write code like I did in the old days. And today I’m happy because I’m writing code like the old days.

There’s no contradiction. Some stuff from the old days was awesome, and some was fine, and some was bad. Writing Swift this way to do something that I’d solve with an object in Objective-C — at least in the case where it really ought to be a pure function (takes input, does a thing, doesn’t look at or change anything else, returns output) — is great. Love it.

(Pure functions make me unreasonably excited. I think I get this from my Mom.)

Wil, Chris, Waffle, Samuel, Soroush

Wil Shipley:

So Cocoa programmers are in a tizzy A TIZZY I SAY at the prospect of going back to the bad old days (eg, 1987).

And…

I urge anyone who's speculating about Swift's possible future missteps to look hard at the team that's brought us LLVM, clang, ARC, and Swift, and think, “it’s pretty likely they’ll handle this,” not, “OH GOD EVERYTHING I LOVE IS ENDING.” (The latter of which, incidentally, is my nightly mantra.)

The tizzy is part of the process. I like to think that the various blog posts and Twitter discussions are contributions to a discussion rather than just words expended for no reason. It’s not venting or declaring that the sky for sure will fall — it’s people doing their part to think and communicate about tools that are important to them.

Also: 1987? For Wil, 1987 may have been the last of the bad old days. For other people, 1997 is more likely — but for me it was 2002, and for other people the bad old days are even more recent.

Consider Elm. People have talked it up to me, and it looks pretty cool, and I’m sure it’s awesome in a bunch of ways, and there are probably a bunch of things to learn from it.

But look at this small example of handling button presses. There are two buttons, and there’s a case (switch) statement to handle the message.

In a small example like this it doesn’t seem onerous. But an app is a much bigger thing, and doing this kind of thing everywhere would work me into a tizzy.

* * *

Chris Eidhof:

Yet, techniques you don’t know will almost always seem more complicated at first. I tried arguing with a Haskell programmer that runtime programming can be useful. I tried arguing with a Ruby programmer that static types can be helpful. To both, it seemed unnecessary and complicated. They’ve been writing great code without those features.

* * *

Waffle:

What I also expect is there to be a dialogue right now about these kinds of details by people who know what they’re talking about, about how Swift could actually become more dynamic without copying the flaws of its progenitors and without selling out the feel, mechanics and (most of the) performance of the language.

* * *

Samuel Ford:

My experience working with type strict frameworks is that they are fussy. It’s like if the only way you could chop things when cooking is with an array of specialty chopping tools that have to be assembled from pieces every time you needed them. And you have one for garlic, another for potatoes, and so on.

Every time you start to cook, you’ll feel the weight of taking those tools out, assembling the pieces, then taking them back apart, washing them, and putting them away. What you’ll find over time is that the recipes themselves will adapt to require fewer chopping tools and will become more plain and more similar over time.

* * *

Soroush Khanlou:

Primarily, the big thing I got wrong last year was that Swift is just plain fun. This weekend, I had the pleasure of helping a friend with code-review. His project is completely in Objective-C, and our code review session reminded me how rough the rough edges of that language are, especially after spending any time in Swift.

A Definition of Dynamic Programming in the Cocoa World

When I talk about dynamic programming on iOS and Mac, I mean this:

  1. An app can learn about its structure at runtime.

  2. An app can do things based on what it knows about its structure.

  3. An app can make changes to its structure.

The first is things like knowing what methods an instance implements, or getting a reference to a protocol, class, or method from a string. (As in NSSelectorFromString and so on.)

The second is things like being able to instantiate a class where the name wasn’t known at compile time, or to call a method or reference a property that wasn’t known at compile time. (As with performSelector:, KVC, the responder chain, and xib and storyboard loading.)

The third is things like adding methods at runtime (a la Core Data) or adding classes — for instance, by loading compiled code from disk (plugins).

(Note — because people sometimes misread what I write — this definition is not advocacy for a particular style of programming, nor is it a judgment of Swift, which, I repeat, I love, and is my preferred language. It’s to help us know what we’re talking about when we talk about dynamic programming.)

Archive

Ads via The Deck