GregHeo.com

Fun With Flags

2019-01-15T14:00:00-08:00

Based on a talk presented at the Toronto Area Cocoa and WebObjects Developers Group (tacow).

The word semaphore has two parts: sema for “meaning” (like the word semantic) and phoros for “carry” (like a pheremone carrying a chemical signal).

Flag semaphores are a communication tool, carrying meaning across some distance.

You have to communicate one letter at a time which can be slow, but communication is silent and can be done so long as the sender and receiver are in visible range.

But what does communicating with flags have to do with concurrency?

Concurrency vs Synchronization

Concurrency is easy: you have multiple sequential processes, and they run independently of each other. In what order? Who cares, it’s concurrent!

If you do care about the order across processes, you need to introduce synchronization. And it turns out, synchronization is all about communication between these processes (or threads, or queues, etc.)

By communicating, we can create synchronization points to help us line up events on one process in relation to events in the other process.

What kind of communication do we need to send to manage multi-threaded computing and concurrent processes?

Locks, for example, can enforce mutual exclusion. Each process communicates with the lock to check whether it’s OK to continue.
Dispatch queues on Apple platforms manage sibling tasks. You can enqueue multiple things on a serial queue and it manages running them in order.
Operation queues are similar and let you specify dependencies. The operation manages the signaling needed to start task B when task A completes.

Semaphores offer another way to do this kind of communication and coordination.

Semaphores

A semaphore is like a lock with a counter. The simplest kind of semaphore is a binary semaphore, which acts like a lock. It’s “binary” since (if used properly) the value is either 0 or 1.

If the value is 1, the resource protected by the semaphore is available. If a task waits for the semaphore, the value goes down to 0.

If another task comes by and waits for the semaphore, it’s blocked and can’t continue since the value is 0.

When the first task completes it signals the semaphore, which increments the integer from 0 to 1. Then that waiting task wakes up, “acquires the lock” so to speak, and the semaphore value goes down to 0 again.

Bigger values

Simple locks and binary semaphores are on or off, but you can imagine initializing a semaphore with a value greater than 1.

Say you had a queue of URLs to download things from the internet. To avoid overwhelming the connection, you only want three active downloads at a time.

You could initialize a semaphore with a value of 3:

let allowDownload = DispatchSemaphore(value: 3)

Then on a background queue, start a download:

queue1.async {
  guard let url = urls.removeLast() else { return }

  allowDownload.wait()
  // start the download here
  // ...
  // download completed
  allowDownload.signal()
}

You could create any number of background queues or concurrent queues with hundreds of downloads but if they all use the semaphore properly, only three downloads at most will happen at one time.

Vs Locks

Semaphores are conceptually similar to locks with a counter, but there are some important differences too.

Thread safety

With most implementation of locks, you must acquire and then release the lock on the same thread or bad things might happen.

Semaphores have no such restriction — the atomicity of accessing and changing that integer value inside is part of the semaphore itself. That means you can wait and signal from different threads if that makes sense in your code.

Accessors

Locks often include API for peeking, or checking if the lock is available or not.

Semaphores usually have no way to read the value of the integer stored inside; they only offer the wait() and signal() functions.

POSIX semaphores are a notable exception here, as they include a sem_getvalue function to read the value. Semaphores in libdispatch have no way to do this.

Closing Words

Semaphores offer an interesting way to control access to a limited resource in a thread-safe way.

Compared to other techniques such as delegation, semaphores are decoupled. The waiting task and signaling task know nothing about each other since the messaging happens through the semaphore.

The communication happens just like a flag semaphore: signaling out there to the world, and waiting patiently for a response back.

I’m going into meetup and conference semi-retirement, so this will be my last public talk for a while. Thanks to the organizers (past and present) of tacow for the amazing community they’ve shepherded, and the always wonderful attendees for listening and making me miss being back home.

Concurrency From the Ground Up

2018-08-27T15:30:00-07:00

As the title suggests, I want to look at concurrency from the ground up. Start from the basics: rather than queues and groups, pthreads and locks.

Why? GCD queues are complicated things, and I think understanding how the simpler, smaller pieces work can help.

Overall Goals

Why do we even care about concurrency? I think it’s an important tool in the toolbox to becoming better programmers and writing better programs.

And by writing better programs, I’m thinking of two things in particular:

Programs that seem faster to the user
Programs that are easy to understand for the programmer

Programs only need to seem faster to users, but they really do need to be easier to understand for programmers.

The How

Next, how are we going to do these things? With concurrency, we hope. We can look at three aspects in particular:

Structuring our programs better. Programming as all about bringing structure to our ideas—that’s literally what code is. And concurrency as all about structures too, as we’ll discover.
Thinking in terms of tasks. Once our programs are well-structured, we can get down to organizing on the code level. This means thinking about smaller tasks, threads of execution, and getting speed-ups thanks to multi-core hardware.
Protecting resources. Finally, we need a mechanism for managing and protecting resources. We’re dealing with systems with limits—memory, CPU time, etc.—and we can look at locks as the concurrency primitive that helps us with resource management.

Concurrency & Structure

We use the word “concurrency” a lot when discussing things ranging from general performance, to doing more than one thing at once, to where to do UI work, to multi-core processors, and so on.

We have two words that we should try to understand better: concurrency and parallelism.

Here are some great quotes from a talk by Rob Pike:

“concurrency is the composition of independently executing processes”

So concurrency is about composition — composing things, these independently executing process things, into something else. It’s about organization and structure: how can we organize these little bits of work together into some cohesive whole?

Here’s the quote about parallelism:

“parallelism is the simultaneous execution of (possibly related) computations”

That seems simpler to me. It’s about simultaneous execution. Doing more than one thing at the same time.

To sum up:

“Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.”

Within this context, parallelism is outside the scope of things I need to do. I’m not the one doing lots of things at once. That’s the computer’s job, or the CPU, or the scheduler, or the operating system, or whatever.

Our job as programmers is the first part: making sure programs are structured in a way that lots of things at once are dealt with properly. We write programs with proper concurrency so the system can run things in parallel.

Decomposability

Another way to think about concurrency involves decomposability — having a large operation, and then breaking it up into pieces that are order-independent or partially ordered.

Maybe you’ve done this kind of refactoring before, where you have a lot of lines of code:

and you break them down into smaller functions:

Then you can replace the original code with a call to each function in turn.

A()
B()
C()

In the easiest case, this is literally a cut and paste job. When we think about decomposability, the easy case is if each of these new sub-functions is completely independent.

What do we mean by independent?

There’s a question of order: if we don’t care which of two tasks happens first, then maybe they’re independent.
There’s shared state: if two tasks have no shared state, then maybe they’re independent.
Mutable state throws a wrench into things: if a task mutates or generates some data, then we might need to start worrying about order.

If two units of work are order-independent then just throw them into the hopper and who cares when they happen?

If the units are order-dependent, then what? How do we ensure they’ll execute in the correct order?

Tasks & Threads

So we’ve broken our program down into smaller pieces. We’re thinking about tasks, and ordering.

And now we’re wondering, what mechanisms are there for us to handle these things? Once I’ve modeled my program into these small functions, how do I model the dependencies or the independence and parallelizeability between them?

We have threads and the pthread library available on Apple platforms to help us with this. The pthread library is a C library and is pretty low level; we probably deal with higher-level abstractions in our day-to-day lives but since we’re looking at concurrency from the ground up, let’s look at pthreads.

Live Coding Notes

The pthreads API needs functions with a certain signature:

func doWork(_ unused: UnsafeMutableRawPointer) -> UnsafeMutableRawPointer?

The function needs to take what would be a void * in C, and return one as well. In Swift that’s represented by UnsafeMutableRawPointer.

Our plan is to run two things in parallel, by setting up two tasks: one to show an activity indicator, and one to do the actual work.

Within the work thread, we can spin off additional threads to call our more specific functions.

The basics of pthreads:

You create a thread and pass it a function pointer. The thread begins executing right away.
You join a thread with pthread_join, which is a blocking call that will wait for the thread to complete.

Live coding is hard to reproduce here; you should check out the video when it becomes available. 😆

You can browse a gist with the final code from this demo.

Locks & Resources

So we started with thinking about structure, and then breaking down code into functions.

If we use threads to model tasks, and we have tools like joining a thread to wait for it to complete, and we can cancel threads, then how do we model our concurrency needs around data and resources?

Locks are a super simple general-purpose thing for protecting resources. They’re like binary on/off switches that you use to ensure you’re not stepping on anyone else’s toes.

Locks are also cooperative — they’re like leaving a note somewhere saying “please don’t touch this until I say so” but the API only covers leaving that note and then removing it. It’s your responsibility to ensure the code takes heed of these notes.

Or, you can think of them like having a room full of people but you only want one person to speak at one time. So you have some kind of token, and you have to first acquire the token, speak, and then release or relinquish the token.

Live Coding Notes

You have the concept of acquiring a lock. That’s like leaving the note or acquiring the token.

Then you do whatever work you need to do.

Then you release, or unlock the lock.

That’s it!

Thinking about usage, you can imagine several ways to use locks:

Locks as signals
Locks as mutual exclusion
Stringing together multiple locks to make a semaphore
Using locks to sequence code together into a quasi-queue

You can browse a gist with the final code from this demo, where we looked at locks as signals and locks as mutexes.

Concluding Thoughts

Locks and threads are the concurrency primitives I think are most useful to understand how higher level concepts and APIs work.

But understanding and applying the concepts of concurrency means pulling together the specific needs of your application, structuring it correctly, and using the correct means to enable high performance.

There are a lot of APIs around locks, threads, queues, etc. available to us on the platform.

I hope this talk and article gives you some new things to research, and helps make you more thoughtful when thinking about structure and concurrency primitives when using those higher-level APIs. 😄

Getting Under Swift's Skin @ NSMeetup

2018-02-07T17:00:00-08:00

I gave a talk Getting Under Swift’s Skin at NSMeetup, where I went over three ways to go a bit deeper in working with Swift:

The Swift language itself, lowered to SIL
Looking at the Swift standard library in the debugger and with custom toolchains
Examining runtime instances with reflection

Why would you want to do these things? It can be fun to go below the surface and see how things are made. You can improve your debugging skills and get a greater understanding of the system and runtime for your apps.

Wise words from a sometimes wise man

As a wise man once said: let’s go one more level down.

The following are some notes and links for more information on things mentioned in the talk.

Swift and SIL

Basic SIL characteristics:

Locals start with %
Globals start with @
Static single assignment, where variables are named with incrementing numbers and are set only once.

To see the SIL representation of your Swift source:

$ swiftc -emit-sil source.swift

To demangle symbols, run the swift-demangle utility:

$ xcrun swift-demangle

Standard Library

Reflection

Five Unbelievable Secrets of Reactive Programming the Experts Don't Want You to Know!

2017-02-23T15:00:00-08:00

Based on a talk given at Playgrounds in Melbourne, February 24, 2017.

I was asked to come up with a super click-baity title for the talk and here it is: Five Unbelievable Secrets of Reactive Programming the Experts Don’t Want You to Know!

(Exactly why the experts don’t want you to know these things is still unclear to me.)

I’ve heard it said about learning Lisp or Prolog or functional programming — even though you might never use Lisp again, learning the language and how it works will (supposedly) change the way you think about writing code and change the way you design programs.

Does the same thing apply to reactive programming? It did for me; writing apps with RxSwift highlighted some best practices and architectural choices that I already knew about, but are much more at the forefront when thinking in the reactive style.

These aren’t actually “secrets” per se, but more like “big picture ideas” that solidified in my head as I learned more about reactive programming. Read on to find out what they are!

1. You already know it

The good news is you already know the pieces that make up reactive programming.

If you’re writing iOS apps in the “traditional” Cocoa style and you learn about functional programming, you already know what a function is. It’s more about learning a new style, a new way of thinking, and perhaps some new words such as everyone’s favorite, “monad”.

Same goes for reactive programming: you’ll see old concepts like sequences, closures, and map used in familiar but novel ways. The way they’re put together, and the language used to describe it may be new but the building blocks are the same.

2. Everything is a sequence

The first thing I think about when designing an app in the reactive style is: what are the sequences? I like to split them into two big categories, inputs and outputs.

Thanks to extensions on common classes provided by RxCocoa, you get many of these sequences, or observables included out of the box.

For example, UISlider has an observable providing a sequence of Float values. UIButton has an observable that fires every time the button is tapped.

You can make your own observables too. I wrote one for a Mac app, to keep track of mouse clicks. NSViewController receives a mouseDown(with:event)method call whenever there’s a mouse click on the view. You can have RxCocoa listen for that method call, and turn that into an observable:

self.rx.sentMessage(#selector(NSResponder.mouseDown(with:)))
  .map({ (params) -> NSPoint? in
    if let event = params.first as? NSEvent {
      return self.view.convert(event.locationInWindow, from: nil)
    }
    return nil
  })

In this case, the first line sets up an observable that produces a value every time mouseDown(with:) gets called. Then we can map over that observable (which remember, is just a sequence) and produce an output observable of NSPoint values.

3. Small pieces of logic

In the example above, we had a sequence of events that needed to be transformed into a sequence of points. Each of these transformations pushes the data through your app.

Within the big box that is your application, there are smaller sequences within.

Each step along the way is its own operation, looking something like another map with a closure. This structure means your programs can be made of small, discrete pieces of logic rather than monolithic massive view controllers.

4. Declarative style

With all these sequences floating around, how do you get them connected together to perform useful work? Up until now, we’ve only seen sequences transformed into other sequences.

Another useful thing you can do with observables is subscribe to them. That means whenever there’s a new value available, or something else happens such as an error or the observable completes, you can provide a closure to react to it.

In the simplest case, say you have an observable that produces strings coming in from some source such as the network. You could subscribe to this observable, and set the value of a label.

someStringObservable
  .subscribe(onNext: { (stringValue: String) in
    self.label.text = stringValue
  })

As a shortcut, you could use the bind function and take advantage of more RxCocoa extensions:

someStringObservable
  .bindTo(self.label.rx.text)

The magic rx property provides properties that can be read or written to. A text field, for instance, can be bound to but you could also subscribe to changes since they accept user input.

The magic comes once you’ve set up all your observables, maps, subscriptions, and bindings: at that point, you can start up your application and all the pieces are magically connected together. Thanks to the declarative approach, you’ve set up the logic of all the transformations and relationships and can now wait for input to start flowing through.

5. Testable code

Having logic in small discrete pieces means they also become easy to test.

Take a very simple example: a class that takes as its input an observable that produces integers:

class SomeController {
  // Input observable providing a sequence of integers
  var intObservable: Observable<Int>

  init(intObservable: Observable<Int>) {
    self.intObservable = intObservable
  }
}

It has a computed property that transforms the input integers into strings:

extension SomeController {
  // Output observable that converts the integers to strings
  var stringConversionObservable: Observable<String> {
    return intObservable
      .map({ (intValue: Int) -> String in
        return String(intValue)
      })
  }
}

You want to test this out. In your app, intObservable comes from some place, maybe the network, maybe user input—it doesn’t really matter. All you want to test is the conversion operation. In this case, the conversion logic is simple but you can imagine having a map with more complex business logic in there.

Between a sequence of integers and a sequence of strings, how are we going to mock these things? If only there were some easy way to mock an ordered, iterable sequences of integers, right? 🤔

At this point, I hope you’re thinking of arrays. Yes, you could take an input array of integers, push that through the observable, and get an output array of strings:

// Test input data
let input = [1, 2, 42]
// Turn the array into an observable
let inputObservable = Observable.from(input)
// Initialize the controller with our test observable
let controller = SomeController(intObservable: inputObservable)

Observables are usually asynchronous since you can’t tell when a value will be available ahead of time. Since this is a test with a fixed array, we can turn this into a blocking observable so it waits for the map to complete synchronously.

// Thanks to the toArray() call, this will be an regular array of strings
let output = try! controller.stringConversionObservable.toBlocking().toArray()

Then it’s a simple matter of making sure the output matches what you expected.

let expectedOutput = ["1", "2", "42"]
XCTAssert(output == expectedOutput)

Done! The nice thing about having inputs and outputs modeled as sequences is that when we need to mock them in tests, it’s very easy to do so thanks to arrays.

Beyond the five secrets

After learning the basics of reactive programming, these “five secrets” encapsulate some big ideas about software architecture and how I want to structure my code. I’m thinking more in terms of streams of data and small blocks of testable code.

If you want to learn more about RxSwift, I’d suggest the following resources:

RxSwift Getting Started page
rx-marin — excellent articles with lots of RxSwift example code
ReactiveX.io — language- and platform-neutral guide to the Rx style of programming

If you were at the Playgrounds talk and want to check out some resources from the talk:

Sample Noughts & Crosses game source code
Slides from the talk

RxSwift @ NSMeetup

2017-02-02T06:00:00-08:00

As someone formerly in the training business, I’m often thinking about the best way to explain things. Something I really enjoy doing is attending talks from beginners — it’s always interesting to hear something you already know (or think you already know!) explained by someone coming into it with fresh eyes.

I started looking into reactive programming and RxSwift late last year, and now it was my turn to be the noob explaining something at a meetup.

Reactive programming is one more thing in the development toolbox. It’s not necessarily something that takes over an entire project; you can use reactive programming elements in just parts of an application if you want.

What are the big ideas of reactive programming? We can turn to Wikipedia for the answer:

Data flows
Propagation of change

Thinking about your app in terms of data — what’s coming in, what’s going out, how do you manage it going from one place to the other — is the core of it for me. Then it’s a matter of pretending you’re a series of tubes, like the Internet, to manage, tranform, and push the data along.

Resources

For the talk, I used a simple app where you provide the angles, and it draws triangles.

You can see the code from the demo on GitHub; there’s one folder with the classic Cocoa UIKit version, and one with the RxSwift version coded up during the talk.

Here are the slides:

And finally, if you’re interested in reading more there are a ton of places to look:

For general theory on Rx: ReactiveX.io
Why use Rx?
The official RxSwift Getting Started guide
There were a lot of questions about dispose bags that I couldn’t answer 😇 — you can read more about them in the Disposing section of the guide
One of the best Rx blogs with lots of useful code examples: rx_marin
Finally, right in the RxSwift repository is the RxExample folder. Don’t miss it when you clone the repository locally and start exploring!

I really enjoy the data flow model and declarative nature of Rx, and I hope to continue poking around and learning. Happy reactive programming adventures to you!

The Year of Travel

2017-01-16T17:00:00-08:00

I haven’t done much travelling in my life, but 2016 turned out to be the Year of Travel for me. I’ve flown about 100,000 lifetime miles, and 56,000 of them were in 2016.

Here’s the year of travel, by the numbers:

Miles flown: 56006
Transcontinental flights: 11
Transatlantic flights: 2
Transpacific flights: 2

Number of times in Chicago without leaving the airport: 2
Number of times in Houston without leaving the airport: 1

Sorry Chicago and Houston; some day I will step outside and visit!

Conference Travel

Pretty much all of my travel was thanks to speaking at conferences.

New countries visited:

🇨🇳 China
🇮🇪 Ireland (airport only, sorry!)
🇬🇧 U.K.

Exciting cities in the USA visited:

🇺🇸 D.C.
🎸 Nashville
👓 San Jose

Relocation

The bigger bit of travel (and the reason I have an odd number of transcons) was moving to San Francisco in March.

I keep a journal in Day One and it’s strange to me to write about being in Toronto and filing it under “Travel”. And when I write about some new thing in San Francisco, that’s just “Journal” I guess. 😄

There were many, many hills & staircases climed in San Francisco in 2016. Luckily there are many more to visit in 2017 and beyond!

Swift Summit SF 2016

2016-11-13T14:00:00-08:00

I had another great time at Swift Summit in San Francisco this year. For a Swift nerd, there’s nothing like being surrounded by so many thoughtful speakers and attendees for an all-Swift single-track conference over two days.

On stage at Swift Summit. Thanks to Erik Kerber for the photo!

Thanks to everyone who stopped to say hello! And a pro tip for other conference speakers out there: have something interesting to say (perhaps one of those “elevator pitches”) about your talk since people will inevitably ask you what you’re going to be speaking about. Apologies to folks who asked me before I had a coherent answer.

On a personal note, my Swift Summit trip last year was the start of talking to more folks at Facebook and led to me joining the company and the team at Instagram. Now I live in the city and work in the Bay Area and it seems like so much has changed in only a year.

Last year I spoke about protocols in the standard library and how we could use them to guide us on using them in our own code. Looking back on it now, I can see that my talk this year had a similar theme: examining standard library source code (now that Swift is open-source!) to guide us toward better coding practices in general.

Open-Source Swift

After last year’s talk, I thought it would be fun to go through each protocol and write about it. I got through a grand total of two before life got in the way.

Then Swift was open-sourced and there were even more distractions! So much code to read and commit history to browse through!

First commit to the Swift repository

I started reading through bit of code at random, mostly at parts of the standard library. I remember checking out the CFLite project and the GNUStep source code back in the day for something similar — GNUStep includes their own implementations of classes you know and love such as NSDate and NSIndexPath and many others. Although this isn’t Apple source code here, it’s still an implementation of the same set of APIs.

On Reading

While reading all this Swift, I found myself thinking more about how I was writing code and also picking up small tricks from what I was reading. One benefit of standard library code is it comes from people who have the most experience with such a young language. You know, that exclusive club of folks who have the “3–5 years of experience with Swift” all the recruiters are looking for. 😉

Again, I managed to get one thing written about Bool.swift before regular life got in the way again. I really enjoyed doing that kind of close reading of a simple-looking bit of source code and writing about it. I did more research and wrote some drafts on optionals and collections and strings over the last few months, but never managed to finish anything.

And that’s where this year’s Swift Summit talk came from. I learned so much from reading more code and making that a habit, and I wanted to share that experience.

If you were at the conference and attended my talk, I hope you enjoyed it! If you weren’t there, there will be a video posted soon enough. And if you were there and didn’t enjoy it, I’m always looking for feedback if you’re willing to take the time to offer it.

I’m hoping to get back to writing more often as all my Swift reading notes continue to pile up. If you’ve started reading more code too, I encourage you to write about it as well!

The Case of the Disappearing Apps

2016-06-19T10:14:00-07:00

For me, the killer app of the Apple Watch has always been notifications. A well-designed and usable dynamic notification is worth its weight in (rose) gold. Even if the app doesn’t provide a custom-built notification, the system-provided one is often good enough to get the information at a glance.

Apps on the watch are effectively invisible — I never launch them, but use them indirectly for their notifications and whatever work they need to do in the background.

On all platforms — iOS, macOS, and watchOS — I often interact directly with the rich notification. This is where you can reply or perform some other action without having to launch the full app.

It’s like the app disappears. I get notified, then perform an action. In many cases, with iMessage as the obvious example, the notification is the app.

Conservation of energy

The app is still there, of course, doing its work in the background. It can’t completely disappear; it just appears to. But the interaction is through the notification, rather than some UI the developer came up with. What if we continue down that path, to a brave new world of almost appless apps?

Then my mind turns to custom keyboards and content blockers on iOS, which for seemingly legacy reasons still need to be inside an app bundle. This seems totally unnecessary — they should just install and show up in the Settings app if they have settings to tweak. No app on the home screen needed.

Now that Apple has even more extension points into the operating system, how many more apps can disappear?

Using the app without using the app

With widgets (formerly known as “Today extensions”) now appearing on the lock screen and by force touching the app icon, you’ll be able to provide some information at a glance to your users. That covers the “pull” half of things, where users reach out and ask for information.

On the “push” half, there are the already-discussed notifications. New in iOS 10 are custom views as part of notifications. That means you can move beyond a plain text message and show some custom UI here. The UI is non-interactive though, so you still need to provide those buttons and actions as before.

Still, that’s push and pull on your app without even launching it, not to mention possible Siri integration. That leads to a fundamental usability question for me: how much can users get out of this app without ever launching it?

Updated but unlaunched apps.

One one end are the keyboard apps that I never need to launch. On the other end are apps like Tweetbot that I launch and use all the time. I think the middle of that spectrum will quickly fill up with apps that are totally useful and usable — just usable indirectly via Siri, notifications, and widgets.

What does that mean for us as app developers? I’m going to start thinking post-Internet humans with short attention spans: provide quick, glanceable, useful bits of information in widgets; take full advantage of custom notification views; and definitely implement SiriKit if it fits into one of the available categories.

And the app itself, with its storyboards and view controllers? There’s still a place for that, but it’s now a shrinking space.

Swift Summit SF 2015

2015-11-03T13:30:00-08:00

I’m back from Swift Summit SF 2015 with many more Swifty ideas in my head. You can read my recap article about the conference here: Swift Summit SF 2015 Highlights.

I’ve written up a summary of my talk, Lessons From the Swift Standard Library Protocols, if you’d like to read it. Or, just go straight to the video!

I always enjoy hanging around the bay area and hearing about all those crazy startups, being shouted at in the mission, and mostly finding raywenderlich.com team members in every corner.

Audience Interaction in your Conference Talks

2015-10-23T08:30:00-07:00

Somewhere on the web is the advice to make your talk “interactive” and get the audience involved. And maybe to take questions too.

Asking questions and taking questions can be good feedback…as long as you do it right.

Note: This applies to technical conference talks, mostly, since that’s the kind that I attend; YMMV.

Polling the Audience

Here’s a tip for any audience interaction: if the talk were recorded, does it still work? With just audio, how does it sound? How does it look on video?

I was at a talk once that felt like a one-way survey: Who’s heard of this brand? Who likes this product? Who’s used this API? And then who’s used that in combination with this other thing? After question five, people stopped putting their hands up.

In moderation, polling the audience is OK. Here’s how you do it:

Ask the question. “Who here has been on a llama ride in the desert?”
Raise your own hand. Pause for people to raise their hands too.
Look around and do a quick count
Give the report. “OK, thank you. Around ten people, which is average for a group this size…”

See what I did there? Ask a clear question. Wait. Tell the audience the results.

This looks good on video and also makes sense in an audio-only recording.

Why raise your own hand? If you’re asking an even slightly embarrassing question (“who hasn’t heard of latest technology X?”), raising your hand—even if that’s not your actual answer—makes people less shy.

And remember, your audience is interested in results too; you’re the one at the front of the room who can see all the hands! They’re counting on you to report the numbers.

Questions Done Right

I’ll be honest: I usually hate questions at the end of talks.

Most of the time, it becomes a conversation about some arcane specific thing between the speaker and some random audience member. It’s like being forced to sit and listen quietly to a private conversation between two people. The audience starts dozing off or checking Twitter.

I’d rather say, “I’d love to chat with you outside if you have questions for me, or I’ll be here for the rest of the conference. I’m very friendly, so please come and say hello and we can talk!”

You’ll wrap up a bit early and the audience will appreciate the time to go to the bathroom, get some coffee, check email; the next speaker can start getting set up; those who really have a pressing question will rush to the front to ask you. Everyone wins!

If you must have questions for whatever reason — the conference requires it, you’re really short on material — say something like this:

“Are there any questions that would be interesting for the entire group?”

Right there, those magic words will make your audience filter their set of questions. “No,” they’ll think, “this question is in fact not interesting to a wide audience. I will not ask it and make everyone in this room hear about this.”

If someone still starts out like, “in my app Foo, I have a class Bar where I sometimes use its convenience initializer, and then in low-memory conditions when it calls my private API, it…” — oh my goodness, please stop them there. Then you say: “that sounds like an interesting case specific to your app; how about we step outside and chat for a few minutes about it after this session? Yes? Good. Any other questions that would be interesting for the entire group?”

Answers Done Right

Aim to answer the question in 30 seconds. That’s a pretty long time — if you don’t believe me, set a timer for 30 seconds and read some documentation out loud.

When you’re up on stage and under pressure to answer, it’s easy to ramble. If you practice 30-second answers and get a feel for how much content fits within that time, it’ll help you keep your answers to-the-point and concise even if you take a bit longer to answer.

If you find you have a ton to say based on a single question, make a note and then turn that into another talk or blog post. More content!

OK, here’s what you do to answer a question:

Repeat the question so everyone can hear and it makes it onto the recording. You can rephrase the question slightly too, to make it clearer.
Answer the question. If you don’t know the answer, just say you don’t know and move on.
When you stop talking, take a moment and think about the original question. Do you even remember the question? Did you answer it? If not, get clarification if required and answer it in ten seconds, then immediately shut up.

Nothing is worse than being in the audience and hearing an answer without having heard the question first. Please please please, don’t forget to repeat the question. The audience and conference organizers will love you for it.

As for step 3: think of politicians who have answers in mind and will make talking-point statements when asked a question. Don’t do this—keep focused on the question and make sure you’ve answered it.

Interactivity

Ultimately, technical talks aren’t theatre and breaking the fourth wall isn’t some shocking thing. Go ahead and bring the audience into your talk.

Just remember: content is king! People chose to come to your talk; the best audience interaction you could hope for is to prepare some amazing content, blow their minds, and let them tweet up a storm to make their followers jealous they weren’t there to experience your brilliance first-hand. 💥

Photo Credits

Mixer; hands up; sleepy puppy; audience

Outlining Your Conference Talk Pixar-style

2015-10-15T06:00:00-07:00

You’re thinking of submitting a proposal to speak at a conference. Or you’ve already committed to speak, and you want to start getting your talk together.

One tip you’ll hear a lot is to structure your talk with a narrative. People have been telling stories since the dawn of language; it’s practically in our DNA. With a strong narrative and call to action, your audience will take something of value away with them.

Call to action!

For technical talks, that doesn’t always work. Having a story and characters can get a little distracting or cheesy when you’re trying to explain the intricacies of multithreading and semaphores.

But when you’re at the outline phase, thinking of the story behind your talk can be a useful thing.

The Pixar Plot

Emma Coats, a freelance director formerly at Pixar, once tweeted a list of storytelling basics. Things that she saw made Pixar films so successful.

One of the items is this storytelling sequence:

Once upon a time there was …
Every day, …
One day …
Because of that, …
Because of that, …
Until finally …

It’s the classic narrative structure here: exposition, rising action, conflict / climax, resolution.

If you’ve watched Nancy Duarte’s excellent TEDx talk “The secret structure of great talks”, there’s a similar structure at work in her model: toggling between what was, and what could be. It’s like a set of mini-stories in the Pixar model: the “before” (once upon a time, every day) and the “after” (until finally).

Tech Talks

This technique works just as well for technical talks. You want to tell your audience about some new API or design pattern or coding technique. But telling them about it isn’t enough: you want to convince them to use the technique, or follow the design pattern, or import that framework.

Tell them why their current world is horrible, what can fix it, and have a clear call to action.

Swift

I gave a talk Switching Your Brain to Swift at 360iDev 2015. You can check out the blog post and/or video if you’d like. As I was preparing the talk, I used the Pixar story structure; here’s what I came up with:

Once upon a time there was Objective-C code and Objective-C apps.
Every day, developers wrote enough square brackets to encircle the globe!
Then one day, Apple unveiled their latest secret project: Swift!

That sets the stage of the “before” state. Then what happened?

Because of that, developers could write simpler code, safer code, and still integrate with existing codebases.
And because of that, developers needed some way to make the transition from Objective-C to Swift.
Until finally, Swift took over the world, from operating system kernels to command-line scripts. There were fewer crashes, and more straightforward, easily understandable code in the world.

There’s the glorious future of what could be, the world we’re striving to create.

So What?

In my case, I didn’t actually “tell a story” per se during the talk, but I had this narrative in mind as I prepared. The Pixar plot is useful for finding the core “so what?” kernel of your talk — the direction where you want to orient your audience.

The end game I was trying to lead people towards was an all-Swift future. How could I help them get there? That’s what I focused on in my talk: Swift’s safety features, code simplicity, and bridging.

Information is nice and stories are fun, but the best talks will inspire the audience to do something. Thinking of the story behind your talk will remind you to keep your audience’s goals and your overall story in mind.

Why not give it a try next time you’re about to go out and inspire the world with your talk?

Switching Your Brain to Swift

2015-08-17T08:00:00-07:00

Based on a talk given at 360iDev 2015. Check out the video too!

The gold standard is, of course, a 100% Swift project started from scratch. If you can do it: great!

But for those of us with existing codebases and an itch to start with Swift, where can we get started?

Why?

To take a step back: why would you even want to write in Swift? Plenty of reasons: Swift is the new shiny; Swift has nicer syntax (begin flame wars); Swift is the direction Apple is steering us in.

In the future, Swift awesomeness will continue to increase and Swift will be the preferred, best-supported, and easiest way to write code for OS X and iOS.

It’s the way of the future; simple as that. What can you do to start thinking in the Swift way?

The Swift Way

There are many things to consider, but let’s discuss two big-picture items: safety and value semantics.

Safety

Nil in Objective-C is awesome. You can message that thing like there’s no tomorrow and the runtime will keep providing responses.

Nil in Swift, however, is quite a different beast. Generally the type system will save you and prevent you from trying to call a method or access a property on nil. But you can get around the type system, and doing so is as bad as dereferencing a null pointer in C: you’ll get friendly trap at runtime and your app will crash.

In Swift, it’s all about type safety. A String is a String is a String. In that case, nil doesn’t even come into the picture. Think more like C++ references rather than C pointers, in that these things will never be nil.

Optionals

With optionals, nil is back in the picture. An optional String could indeed be a String or it could be nil. You have to check. Every time.

Or not: you can just force unwrap the optional. Or change it to be an implicitly unwrapped optional, which means it’s an optional with an inferiority complex and acts like a real value – except when it’s nil, and the app comes crashing down.

Cocoa is full of optionals. That means every time you have one, you have to check what’s inside.

That’s a big shift in thinking. The idea is, you shouldn’t leave messaging nil up to chance. You should know, with a strong type system, whether something is nil or whether it’s a value.

And if it’s uncertain at run time, check. Don’t force unwrap.

Think of optionals as a box: the box can either have nothing (nil) or a value. But you always have to check before you unwrap or “unbox” the thing.

What’s inside the optional box, you ask?

There are plenty of other examples demonstrating safety in Swift: initializers, less undefined behavior, memory safety. Nil safety is a pretty common one that comes up all the time.

Value types

Value types are everywhere in Swift. That’s nothing new – Objective-C has primitives like NSInteger and structs like CGRect. But the vast majority of things – NSString, NSArray, and so on – are classes and thus reference types.

In Swift, it’s the complete opposite where the standard library has over 80 structs and only 4 classes if you scan through the headers.

Strings and numbers and collection types are value types in Swift. That means if you have a mutable Swift String (which is a struct) and pass it into a function, you get a copy. Again, this isn’t a terribly new concept: we’ve had copy and mutableCopy in Objective-C for a long time. The big shift here is that it’s the new default behavior for many common types.

Unfortunately, if you do something awesome with structs in Swift; you won’t be able to access them back in Objective-C. That takes us to our next big topic: Bridging.

Bridging

Swift was of course designed to work well with Objective-C. This is almost a necessity and a given since Cocoa was built for Objective-C. All those Cocoa APIs absolutely have to be callable from Swift, which means your own Objective-C classes also bridge nicely to Swift.

Here’s the problem: starting with Swift, adding Objective-C, and then expecting to call your Swift stuff from Objective-C.

Swift to Objective-C

There are a ton of Swift features such as native structs and enhanced enumerations that don’t bridge over at all into Objective-C. That means if you write the latest and greatest framework in Swift using all its coolest features, you won’t be able to access a lot of this from Objective-C.

Even if you limit yourself and you write things in Swift to use only compatible features, you can’t subclass a Swift class from Objective-C. You could follow the pattern of table views or collection views and use delegates and layout objects to get around the problem, but it’s something to keep in mind if your API is meant to be subclassed.

The default is for nothing in Swift to be visible from Objective-C.

If you mark your classes and protocols and such with @objc, then they’ll be available on the other side. The dynamic modifier also implies @objc so it’ll make things available to Objective-C, but it also makes the property or method you’re marking dynamic use the Objective-C dynamic dispatch.

If you want to swizzle or something, you’ll need to use dynamic; just @objc on its own isn’t enough to guarantee things will use objc_msgSend() as it’s still possible that methods will be devirtualized or inlined.

And again: this will only work for compatible features. If you have a method in your Swift enumeration, that won’t make it over. If you have an enumeration backed by something other than an Int, it won’t make it over.

Objective-C to Swift: Nullability

There’s a lot of good news going from Objective-C to Swift. To help this along, you add annotations to the types of your properties, arguments, and return values in Objective-C.

_Null_unspecified (default) – bridges to a Swift implicitly-unwrapped optional.
_Nonnull – the value won’t be nil; bridges to a regular reference.
_Nullable – the value can be nil; bridges to an optional.

If you annotate your Objective-C, you’ll get nice typed bridging over in Swift. Even if you never touch Swift, these annotations will show up in the code completion when you write Objective-C. And if you say a method parameter is _Nonnull and you pass in nil, you’ll get a nice compiler warning.

It’s good practice to start adding these annotations. They’ll help you when using existing API, and then get you up to speed when you start using Swift.

Objective-C to Swift: Lightweight Generics

Lightweight generics are new with Swift 2. Collection types NSArray, NSDictionary (for values), and NSSet can contain any old NSObject type.

That means a lot of casting. Not such a problem in Objective-C, but remember: Swift is all about safety. Casting done properly involves lots of checks. You shouldn’t just force cast, you should test first.

Now with generics, that means you can write something like this in Objective-C:

NSArray<NSString *> * _Nonnull

It’s an NSArray that will contain NSString objects. With nullability annotations, you can see it also says the array itself will not be nil; you’ll always get an array. The generics syntax here should be familiar if you’ve written Java or C++.

This will then bridge over to Swift like this:

[String]

A nice, clean array of Swift strings.

A small footnote: lightweight generics only work for the foundation collection classes: arrays, dictionaries, and sets.

Bridge over Troubled Water

I would suggest starting new projects in Swift – all, 100% Swift. If you have third-party frameworks, it won’t matter as much whether those are in Swift or Objective-C – you’ll be able to call through to either.

If you have an existing codebase and you want to start introducing Swift into it: try to keep the bridging in the Objective-C to Swift direction. Actual instantiated view controllers and views, for example, work great in Swift; and they descend from NSObject so you can access them from Objective-C if you have to.

But for all those other things: full Swift generics, enumerations backed by things other than integers, nested types, structs, and so on – those will have to wait until the day you’re in the brave new world of 100% Swift. Don’t get left behind; the day will be here sooner than you think!

Until then: keep writing bridge-friendly Objective-C and stay up to date on Swift. There are plenty of resources for helping you make the transition.

Resources

What’s New in Swift 2 – get up to date on the latest stuff in Swift 2
Swift Guard Statement – someone asked a question about keeping code in the “happy path”, which the new guard statement in Swift 2 helps with!
Introducing Protocol-Oriented Programming in Swift 2 – Protocol-oriented programming is the new hotness in Swift.
Using Swift with Cocoa and Objective-C (Swift 2 Prerelease) – Apple’s book on Swift + Objective-C + Cocoa

Watch-First Design

2015-05-29T06:30:00-07:00

Do you remember WAP sites from the days before the fully-functional mobile web?

A WAP site

I liked using the WAP version of sites (if available) even after I got an iPhone. They were clean, they loaded quickly, and they had the important core parts of the site front and center.

Planning out your next iOS app? Even if a WatchKit extension isn’t part of those plans, think about it — what is the essence of your app, distilled down to a single watch-sized interface?

Designing with constraints in this way can really help you get an idea of what’s really important.

Designing with constraints

When the responsive design era of the web came about, the new idea was to start with mobile first. Think about the core of your site and design for small screens first, then expand out to bigger screens.

WAP to phone to desktop

That’s a pretty good tip if you’re feeling stuck: give yourself a constraint to work with to get yourself thinking differently. Stuck on design? Sketch out your site so it only uses three colors. Writer’s block? Try writing a few paragraphs with no adverbs. Write a few paragraphs with an adverb in every sentence.

In the case of the web, you need to strip away the fringes to get to the inner kernel. What is this web site really about? If someone coming to the site only took one glance and never scrolled, what would you want them to see? There isn’t too much room above the fold on mobile; what’s really important to your users?

Watch-first design

This is a good exercise to do when thinking about your iOS apps: determine what is the essence of your app, distilled down to a single watch-sized interface. Even if you’re not planning on building a companion watch app, think about it and see where it leads you.

Screen from Pitch X

What is the information your users will want to know about? What are the actions they will want to have closest at hand?

The watch context menu can have up to four buttons. If each button presents a modal, imagine your app could only have four other screens. What would you put in those additional screens? Could you make do with fewer than four?

Button-mashers will wear out the lower-right corner…

Now that you’ve designed with constraints and figured out what’s really important, expand out to the phone, tablet, and wherever else. Again, even if you never build the watch part, think of how much you’ve learned about the app!

Force Touch

2015-04-08T12:30:00-07:00

No, it’s not a Star Wars thing; first spotted on Apple Watch, force touch is the umbrella term for pressure sensitivity on touch devices.

On the watch, a force touch (simulated with a long press on the simulator) opens up the context menu. Developers can add up to four menu items here for context-appropriate actions based on whatever’s on the watch display.

Watch context menu

Force touch on other touch devices — iPhones and iPads — seemed like a no-brainer. But it turns out the Macs get this new technology next and the iPhone will have to wait a while longer.

Confirmed: Vader rocks a 5C

What do the force touch APIs look like on OS X? You can get the full details from the documentation linked on Apple’s Force Touch for Developers page, and I’ll hit some of the highlights below.

Gestures and events

NSResponder and NSGestureRecognizer have pressureChangeWithEvent: methods for you to override.

The event passed in will be an NSEvent object, which has had a pressure property for a while now; you can get a Float here with a value from 0–1.0 with the current pressure. Here’s the best line from the API documentation:

Pressure is not intended for measuring weight.

That means you need to shelve that idea for a force-touch trackpad scale app, OK? ;)

stage is a bit simpler and provides an integer property for gesture events to say whether nothing’s happening (0), it’s a click / mouse down (1) or “additional pressure” aka a force touch (2).

New buttons

OS X 10.10.3 introduces some new button types and functionality:

Spring-loaded buttons, which provide drag-and-drop on steroids. You can drag something onto a button and then force touch, as if literally drilling down the item into the button.
Accelerator buttons can either fire events faster the more pressure the user places on the button (useful for media controls) or can be non-continuous and only fire an event when the pressure changes.
Multi-level accelerator buttons are like sliders with stepped pressure levels. For example, you could set it for three pressure levels and then get an integerValue from 1–3. You get a little haptic feedback with each step too.

There’s always a fallback for non-force touch devices: drag-drop-and-wait for spring-loaded buttons, while accelerator buttons will just return a simple on/off or 0/1 value.

Force touch on iOS

What might this look like when force touch makes it to iOS, possibly later this year?

Haptic feedback – we can make the phone vibrate, but what about a more precise vibrateWithIntensity: method? ;)
New gesture recognizer – we already have gesture recognizers for tap and long press, so maybe there will be a new one for force touch. Or, to follow the Watch simulator route, maybe force touch will be an option on the existing long press for backwards compatibility?
Accelerator buttons – the API for these on OS X looks really neat and there’s a reasonably graceful fallback for non-force touch devices too. Some new properties on UIButton or even new methods on UIResponder would work.
Pressure-related properties on UITouch – drawing apps could make good use of a new pressure property in UITouch objects. I’m sure the folks at Facebook are already looking to revive their Poke app to support different levels of force to match the poke intensity.

RWDevCon 2015

2015-02-13T05:30:00-08:00

It’s a week after RWDevCon and what’s on my mind as I write this post? Swift 1.2? Collection view layouts? No, of course – it’s the people, and finally getting to meet my virtual colleagues!

As if weekly Google Hangouts with this bunch wasn’t enough (source)

Flashback time

Way back in 2005 when I was starting my freelance career, I worked with a fantastic group of colleagues. They were also here in Toronto, but it was four months before I met them. How strange, I thought! To go four months of working closely with people, talking on the phone almost every day, but never meeting in person.

Pixels and bits on the screen

Fast forward to more modern times. My closest colleagues are now best known to me as Twitter handles and IRC nicks and more recently, 36x36 Slack avatars.

Virtual water cooler inhabitants

I always thought text-based conversation makes it hard to get a sense of people’s feelings and emotions – are they kidding? Serious? Did they mean to add a sarcastic smiley face on that? I still feel this way about email, which often reads as cold and terse to me.

But spend enough time on IRC/Slack and throw the odd Google Hangout into the mix (with an upgrade to 100x100 pixels per person) and an amazing thing happens: you feel like you know these people!

OMG talking heads!

I start thinking: I know exactly what Brian will say next! Tammy sounds super enthusiastic today! Where has Felipe been lately? That sounds just like a @cwagdev joke! How can I troll ecerney this week? And so on.

Meatspace

Turns out, these people aren’t just bits over the air. Even in the early dawn of 6am on our first team outing and as the day went on, I had no problem recognizing voices and faces and personalities.

As always, people are taller than I expect (source)

There were no odd introductions or awkward moments. It was like I had been working with these people for many years – because I had! Seeing them in person and starting up a conversation from where we left off online was the most natural thing in the world.

Remote work

There’s been a lot of talk lately about remote work and how it’s the way of the future. Generally, I agree. Maybe not to the extent of wearing VR headsets in virtual meetings, but it’s not necessary to be in the same room as your co-workers for anywhere near 100% of the time.

As much as I love working remotely from home, which I’ve done for ten years now, there’s something to be said for meeting in person. Having lunch, casual conversations, doing a walking tour of a city, and just hanging out with these ~40 people I work with were the highlights of the conference for me.

Team members at RWDevCon (source)

Ultimately, we’re a distributed remote team and there’s no way around that. With tools such as Slack and Trello and Google Docs and good old email, we make it work. Even so, there’s no substitute for hanging out in person at least once in a while.

For everyone who was there this year – colleagues, people who said hello, attendees at my two sessions: it was a pleasure to meet you! For those who missed it: let’s meet up soon.

I’m on record as having suggested both fall and winter editions of RWDevCon. Hey, why not make it a travelling show like CocoaConf? ;]

Epilogue: the selfiepocalypse

In my non-work life, I’m the unofficial family photographer. That means I’m not in many of the photos, which some family members have commented on. My solution: I try to take lots of selfies at Christmas and Thanksgiving and other such family events.

So here’s another thank you to the team members who put up with my new habit at the conference.

Selfies at RWDevCon. Yes, I only have three facial expressions. (view all)

I didn’t get to everyone, so my apologies if I missed you. Next time I’m bringing an attendance list with me!

What's New in Swift 1.2

2015-02-11T04:00:00-08:00

Another linky post – a summary of what’s new and notable in Swift 1.2.

There are some annoying things that will cause many compile errors, and some cool things that add interesting features to the language. Check it out, and get coding!

Four Things I Learned Making My First Swift App

2014-10-21T17:00:00-07:00

Swift is a whole lot of fun — fun to learn and fun to write.

Being on the cutting edge of Apple technology has its ups and downs though; check out my blog post on raywenderlich.com for all the details!

Shipping Stuff

2014-10-10T03:10:10-07:00

Here’s an often frightening set of questions I need to ask myself more often:

What have you shipped lately?

What are you waiting for?

I’m the kind of person who starts many projects and has trouble saying “no” to things. Couple that with general procrastination and too much picking on the little details and you get a lack of stuff shipped.

What can I say, I’m working on it! I should print out those two questions and keep them over my desk.

Transformable attributes in Core Data

2014-01-27T16:00:00-08:00

In addition to the usual types – string, float, boolean, date – you can define core data entities with an attribute of type Transformable. What is this magic type, and what does it transform into?

Add a Transformable property, generate an NSManagedObject subclass, and this is what you’ll see:

@property (nonatomic, retain) id myTransformable;

A plain old id! So in theory, you could set any object there. On 10.9, I can set my own custom NSObject subclass object to the transformable property, but when I save the context I get an exception for the unrecognized encodeWithCoder: message.

There’s the clue that the object needs to conform to NSCoding. So NSArray, NSDictionary, NSData, and others are supported out of the box.

So you can use your own class as-is — as long as you implement the required protocol methods initWithCoder: and encodeWithCoder:. Then, you and Core Data can get a room and your data will be happily persisted and realized with your classes intact.

The standard downside is that transformable attributes are stored in the SQLite backend as binary plists inside BLOBs, so you can’t query those fields directly from an NSPredicate.

iOS 7 By Tutorials

2013-09-17T17:00:00-07:00

With iOS 7 released today, what’s a developer to do? Wade through screenfuls of framework documentation and header files?

No! Learn by example and step-by-step instructions and challenges!

I’ve been on the editorial team over at raywenderlich.com for almost a year now. Aside from being among the best virtual coworkers a guy could ask for, these are some super smart folks who can explain everything from selectors to Sprite Kit to source control.

I had a blast writing the chapter on unit testing, as well as tech editing part of the book. You’ll love it as much as I know the whole team loved working on it!

Store links:

iOS 7 by Tutorials – everything you wanted to know about iOS 7. (On Amazon.com too).
iOS Games by Tutorials – work through building five games with Sprite Kit!
The iOS 7 bundle – everything you need to learn about what’s new in iOS 7, including Sprite Kit.
Sprite Kit Tutorial for Beginners – a preview chapter from iOS Games by Tutorials.

Adventures in Dvorak, two months later

2013-08-12T17:00:00-07:00

I’m now two months into the great Dvorak switchover. So far so good! I can no longer type on a QWERTY keyboard unless I look at the keys. The context switch seems to be strong enough that typing on the iPhone makes my brain auto-switch to QWERTY, although I find myself mistyping there sometimes.

The stuff I thought would be the worst – shortcut keys and vi keys – ended up being not such a big deal. I thought muscle memory would be much stronger, but it turns out I rememember keyboard commands by the letter or character and not the physical position.

My new favorite typing practice site is typing.io. I used the classic GNU Typist at first, but typing.io is programmer-specific and I get to read an interesting selection of code as I go! Most importantly, the exercises there include all those curly braces and semicolons that programmers type a lot.

I’m still thinking about buying an Ultimate Keyboard:

In the meantime, I did get a Dvorak Keyboard Cover. One flaw is it omits the all-important square brackets but as an Objective-C developer, I learned where those are right on day one!

GregHeo.com

Fun With Flags

Concurrency vs Synchronization

Semaphores

Bigger values

Vs Locks

Thread safety

Accessors

Closing Words

Further Reading

Concurrency From the Ground Up

Overall Goals

The How

Concurrency & Structure

Decomposability

Tasks & Threads

Live Coding Notes

Locks & Resources

Live Coding Notes

Concluding Thoughts

Getting Under Swift's Skin @ NSMeetup

Swift and SIL

Standard Library

Reflection

Five Unbelievable Secrets of Reactive Programming the Experts Don't Want You to Know!

1. You already know it

2. Everything is a sequence

3. Small pieces of logic

4. Declarative style

5. Testable code

Beyond the five secrets

RxSwift @ NSMeetup

Resources

The Year of Travel

Conference Travel

Relocation

Swift Summit SF 2016

Open-Source Swift

On Reading

The Case of the Disappearing Apps

Conservation of energy

Using the app without using the app

Swift Summit SF 2015

Audience Interaction in your Conference Talks

Polling the Audience

Questions Done Right

Answers Done Right

Interactivity

Photo Credits

Outlining Your Conference Talk Pixar-style

The Pixar Plot

Tech Talks

Swift

So What?

Switching Your Brain to Swift

Why?

The Swift Way

Safety

Optionals

Value types

Bridging

Swift to Objective-C

Objective-C to Swift: Nullability

Objective-C to Swift: Lightweight Generics

Bridge over Troubled Water

Resources

Watch-First Design

Designing with constraints

Watch-first design

Force Touch

Gestures and events

New buttons

Force touch on iOS

RWDevCon 2015

Flashback time

Pixels and bits on the screen

Meatspace

Remote work

Epilogue: the selfiepocalypse

What's New in Swift 1.2