Autolayout Constraints in Emoji — Maximum Readability

Programmatically creating Autolayout constraints is famously dense to read, although the strongly-typed visual format makes some easier to parse visually.

With that in mind, which is easier to read?

This:

let subView1 = UIView()
let subView2 = UIView
let constraint = NSLayoutConstraint(item: subView1, attribute: .left, relatedBy: NSLayoutRelation.equal, toItem: subView2, attribute: .right, multiplier: 1.0, constant: -10)
constraint.priority = 900.0
view.addConstraint(constraint)

Or this:1

view.📌(subView1 ⬇️=⬆️ subView2 + 10 ‼️ 900.0)

Read More »

The Minimal Swift for Reading `stdin`

I needed to do some simple text file manipulation the other day and since it the command line was the obvious place for this, I started to use it as an excuse to learn bash, but then I quit that. I decided to fall back to Swift. I had to go back to a previous script I had written at one point that used Swift for stdin manipulation.

So, here in all its glory, is a very simple method for reading stdin into a single string.

#!/usr/bin/swift
import Foundation
var string = ""
while let thing = readLine(strippingNewline: false) {
    string  = thing
}

In order to run it without prior compilation:

xcrun swift readStdin.swift < textfile

To compile it, and then run the executable:

swiftc readStdin.swift -o readStdin
./readStdin < textfile

Personal Unit Testing Road Blocks

Ok, gonna make this quick, or else I’ll never publish it.

I just listened to a great episode of Fatal Error podcast on testing.1 Chris is clearly a consistent unit test writer and did a great job laying out the whys of testing and some basic approaches. Soroush did a great job as the less consistent test writer and laid out some great reasons why testing would be helpful. Together I appreciated a few of their strategies for getting started.

I know that Chris in particular felt like the episode was a mess, but honestly, it was really, really good. More to come will be welcome, but this episode struck a great balance of nitty gritty without getting bogged down by nailing down every. single. term. and. concept. which in the testing conversation is a serious risk.

That was just throat clearing. The point of my post is to describe how I get bogged down in trying to add tests to my current codebase:

  1. Our codebase is a mix of Objective-C and Swift.
  2. I fixed a bug today. The fix involved UINotificationCenter. So there were a few places that I was just not going to even try to test, i.e. “did the class get the notification?”, “Did the class call the right method when it got the notification?”… But the class called a protocol method that behaved differently depending on whether I passed an object or if I passed nil. That seemed testable.
  3. So, then I started to think about writing a test. And I started down this mental path:
    1. I need to create an object that conforms to the protocol.
    2. The method in question does not actually return a value, it just calls a method on our analytics singelton if the object is present.
    3. So, I guess that I could rewrite this method in the class that conforms to the protocol, so that it calls a returning method that indicates whether it should call the analytics method. OK.
    4. Then, we are writing all of our Unit tests in swift, no problem, creating an object that conforms to an protocol is no problem, right? No, I don’t think so. But how do I know if the other method is called? Well, I’ll figure that out in a minute.
    5. Oh, and I’ll need to figure out how to call a private Obj-C method from swift. If the test were objective-C, I would just write an inline (testable) category in the Unit Test File, but how to do this in Swift? 2
    6. AAAaannddd… I’m done. This method is simple and obvious enough… No need to test it…

Some of these things are definitely only problems because I don’t write tests often enough. I’m sure they would strike many as trivial problems that are just a part of writing inter-operating Swift and things that are just learned with practice. I agree. It’s just as raw (and vaguely embarrassing) a description of my mental process as I can write.


  1. Soroush Khanlou & Chris Dzombak host it, and it is great! ↩︎
  2. now that I’m writing this blog post out this way, I remember that I can add that category to to an Objective-C header file, which I can add to the Bridging-Header.h file in my Testing workspace. ↩︎

iOS-ification of Mac Hardware

For a long time there was concern that Mac OS X was going to get iOS-ified

But it seems a lot more like the tea leaves are indicating instead that the hardware has been iOS-ified right underneath our noses:

  1. No official Mac monitor.
  2. No new Mac mini in many years.
  3. No new Mac pro in years.
  4. In other words, all mac hardware designed in the last 3 years is a form of screen cpu in a single housing.
  5. No Keyboard with touch bar.1
  6. No more Wifi products.
  7. Many now-necessary peripheral cords were handed off to Belkin.
  8. The ability to officially modify the HD or Ram has been steadily diminished, and has now reached iOS levels of non-interchangeability.
  9. All Mac laptop designs from last two years now only have two (kinds) of ports – usb-c headphones.

At this point, there seems to be a very clear pattern regarding hardware designed in the last year or so:

An iOS device == screen cpu/hard + drive/memory + touch input + single charging/data port headphone jack. The desired interface between an iOS device and the rest of the world is bluetooth or Wifi

A Mac == screen cpu/hard + drive/memory + keyboard input mouse input + a unified type of charging/data port+  headphone jack. The desired interface between a mac device and the rest of the world is bluetooth, Wifi or possibly USB-C

The only significant difference is the kind of input that each type of device relies on.

Read More »

Discovery Of The Day/ Variables View

In my quest to rediscover the most basic of functionality in Xcode that has been sitting in front of my face for the last couple years, I have discovered the value of the Variables view.

What is that you ask? Oh, that’s the white panel that I am always in a hurry to shove out of my way so that I can get to the lldb command line in the console view in order to po object.value. Let me show you what the Variables view does:

oh-thats-pretty-helpful

Yes, you are correct, it shows the value of every variable that is currently within scope.

Too bad Apple hid it so well. Maybe they should do something about that in their documentation. 😉

variables-view-apple

Discovery Of The Day- Git Branches in Xcode

I was already that when you commit code in Xcode (alt-⌘-c), you get a side-by-side view of the changes that you’ve made.

You can also go to the Source Control menu and look at a number of things, but it lacked an intuitive way to navigate branches.

But, wow, come to find out, that hidden in plain sight all along, was a button that turns the assistant editor into a viewer to look at the diff of the current file for any commit in any branch in your current repo. NOTE: so it’s not a great way to compare the difference between entire commits, but it is great for single files.

git-button-in-xcode

when you tap that you get the side-by-side editors (unless your a monster and you have them arranged top-bottom)

Then if you tap down at the bottom left corner of either view, you can choose commits and branches.

git-branches-xcode

As usual with such discoveries, I am torn between “WOW!!!” and “Jeeezzz, how did I not know about this?!?!”

Programming, Functions and Time

One thing that I often think about is what makes programming different than math.

Taking the overly simplified version of functional program to an extreme leads me to conclude that at a basic level, I might expect a complete equivalence between any program and a single (very long) mathematical function.

But this isn’t quite true. There is a time component in the equation. And this time component is unpredictable. This is probably the single most confounding aspect of programming, at least in my experience.

So I think that programming is like solving a mathematical equation in real time and the outcome of the equation is impacted by when and how quickly I solve the problem.

Application state and transitions are difficult to think through because I often don’t anticipate the variety of things that can happen at unexpected times.

I think that rightly many proponents of functional programming aim to maximize the number of computations that happen in a completely predictable time-independent fashion. UIKit is not written in such a paradigm and absolutely grates against such sensibilities. And rightly so!!

But animations, transitions that happen in response to user input and network responses need to happen in time and as the iOS platform is maturing, we are seeing more and more of the frameworks become less fragile with regards to time-dependence.

UIViewPropertyAnimator is a good example of this. In the past, the animation of a property was kicked off and the app didn’t have much or any opportunity to interrupt it. But now we have the ability to interrupt or even modify an animation midstream. Of course, this does come at the cost of complexity, because working out things in realtime means managing the state. I sat through the WWDC session on this. Even the basic example was a lot more complicated than just calling a simple [UIView animateWithDuration:]

I don’t have a grand conclusion. Just noodling a bit here.