Stormcrow


CAPTION_YO

If you’ve ever wanted an easier way to write a properly-threaded tweetstorm, my new app Stormcrow can help. Type all your tweets into a single text view. Stormcrow will automatically separate your paragraphs into a thread of automatically-numbered tweets. Publish them all at once at the tap of a button. Spend less time futzing with reply buttons and counting tweets, and focus on what you’re trying to say.

Stormcrow is available now on the App Store for $2.99 USD.

|  27 Mar 2017




Swift Needs a Scope Keyword

Swift’s namespacing is great. It’s quite common now to see nested types like this:

class MyViewController: UIViewController {
  private enum State {
    case initialized
    case refreshing(previousModel: Model)
    case success(currentModel: Model)
    case error(Error)
  }
  private var state: State = .initialized {
    didSet { stateChanged(from: oldValue, to: state) }
  }
}

There’s no need for any class outside of MyViewController to access the State enum. Nesting it not only makes the intended usage obvious, it also lets you trim the type name down to a single word by obviating the need for a prefixed name like MyViewControllerState. Other classes are then free to nest their own State enums without worrying about name collisions.

Swift’s namespacing rules also allow you to group together related functions or constants that would otherwise be scoped at the module level:

struct Transformations {
  static func transform(_ foo: Foo) -> Bar {...}
  static func transform(_ bar: Bar) -> Foo {...}
}

struct Colors {
  static let background = UIColor.white
  static let bodyText = UIColor.black
}

Callers can then access a function like transform() without having to access a free function:

let b = Transformations.transform(f)

Please note this does not require the developer to initialize a Transformations instance. It’s hard to tell from my contrived example, but in practice it’s common to find types that would be nonsensical as instances but are nonetheless useful as scope providers.

But here’s the problem: how do you make it obvious to other developers that Transformations isn’t supposed to be initialized? One option: make the init method private:

struct Transformations {
  static func transform(_ foo: Foo) -> Bar {...}
  static func transform(_ bar: Bar) -> Foo {...}
  private init() {}
}

But that solution introduces more problems. First, it’s still not readily apparent that Transformations exists solely to provide a namespace. Second, this API pattern requires you to remember to make the init method private for every such type you ever create, which is a hassle. This is why the de rigueur solution right now is to use a caseless enum:

enum Transformations {
  static func transform(_ foo: Foo) -> Bar {...}
  static func transform(_ bar: Bar) -> Foo {...}
}

But this too is confusing because it’s not obvious that Transformations is meant to provide a namespace. It’s not really an enum. This is especially problematic in real-world examples where the functions and members of such a type are lengthy, making it impossible to tell at a glance whether there are any case declarations hidden somewhere in the file. It also does not prevent other developers from misunderstanding your intent and adding cases to the enum in the future.

I propose that Swift introduce a new scope keyword to address this common use case. My simple example might then look like this:

scope Transformations {
  static func transform(_ foo: Foo) -> Bar {...}
  static func transform(_ bar: Bar) -> Foo {...}
}

A scope can be declared the same way as structs, enums, and classes:

scope TYPENAME {
  // body
}

A scope can be declared either at a module level or nested within any type that supports nested types, including another scope:

scope OuterTurtle {
  scope MiddleTurtle {
    scope InnerTurtle {
    }
  }
}

A scope cannot be initialized, therefore a scope cannot have instance-level properties or methods. All methods and properties of a scope must be static. However, as a convenience the static keyword can be omitted since this is always implied:

scope Endpoints {
  scope Users {
    func getUser(withId id: String) -> Endpoint {...}
    func followUser(withId id: String) -> Endpoint {...}
  }
}

Scopes support the same access levels as other Swift types:

public scope Foo {
  public let qux = Bar.baz
  private scope Bar {
    let baz = "Baz"
  }
}

If you think this would be useful, please get in touch with me on Twitter.

|  17 Mar 2017




How To Write The Software

From an interview with a career SR-71 pilot:

Q: So if I’m understanding the whole startup process is kind of like this space age Model T, where you cranked it just to get the engine up to speed?

A: Yeah. It’s just amazing, and points out a hallmark of the Skunk Works. Don’t waste energy on something you have a solution for. You’ve got a lot of things to worry about already: how to keep the glass from melting at speed, how to keep the engines running at high speeds for long periods, how do you keep the fuel from exploding. If someone had a simple solution to something, then that’s what they did. A very unique, very pragmatic approach. It was also part of the mystique of the thing, this fifty foot green flame shooting out from each engine on startup.

Source: SBNation

|  1 Dec 2016




Tangential Thinking

I don’t know if this term is one somebody else coined, or if it has other meanings elsewhere, but what it means to me is clear. Life is a series of points on a curve of no discernible shape. No orderly function produced it. There are as many bends and folds as there are numbingly straight passages. The only guarantee is that, as it has bent before, it will bend again. The chief mistake of the student of this line is to project its future course as a tangent from the present. Someday it will bend away from that projection, and the tangent that seems so sure now will vanish. This mistake is easy to make. There are many straight passages, some so long as to suggest a guiding hand. If there is a guiding hand, it seems bent on tempting the complacent into despair and the despairing into complacency. Guard your mind against both temptations.

|  27 Nov 2016




How I Organize a Swift File

As a professional developer, it’s my job to work with the code that I’m given, even if it’s not ideal or aligned with my own coding style. That doesn’t mean I can’t have my preferences and peeves. Sometimes I inherit Swift code that looks like this:

The main thing this code has going for it is that it’s terse, which can be a good thing for some Swift code. But there are problems:

When I encounter code like that, I try to clean it up:

What’s different:

Here’s how it looks with some of the details above removed, in order to capture all code sections in one screenshot:

I don’t expect everyone to agree with my preferences. This is just what I like. But I think I can make pretty good objective arguments for the principles I’m trying to put into practice:

|  2 Nov 2016