Dismiss a Modal UIViewController created in Interface Builder

There are a number of posts on this subject on Stack. They involve re-instantiating (this seems slower to me) or yanking the view from a UIButton (this feels dirty).

I’d rather just update the UIBarButtonItem that I already have:



All I needed to do, was attach the appropriate target and action to the UIBarButtonItem:

Using PonyDebugger on a device

PonyDebugger is awesome. I use it mostly for Core Data debugging. Most of the time, I find it easier then firing up SQLite Professional

When using the simulator, hitting localhost:9000 is fine. On a device, not so much; you need to hit your machine. xip.ioto the rescue! What it is: xip.io is a magic domain name that provides wildcard DNS for any IP address. We use this heavily at work if the machine we’re on isn’t hooked up to a subdomain or Vagrant Share.

We can use this wildcard to have our iPhone hit our laptop’s instance of PonyDebugger.

First, get your IP. I use this Alfred workflow. Take note of your local IP.

Start PonyDebugger listening on that IP:

For handy access, alias this command: 

Load Pony in your browser by appending your IP to the a xip.io URL:

To access via the simulator or a device:

UITapGestureRecognizer in Swift

I have a subclass of UIView that has a label:

I want to attach a Tap Gesture to it:


Creating a conforming delegate (UITableViewDelegate) in Swift

This tripped me up for a bit so I hope this helps someone.

I started out with this class, thinking I could just continue on my merry way. This errors in Xcode with: “class does not conform to NSObjectProtocol

Hmm ok, but much there yet, what did I miss? This should definitely be a class; not a protocol (I have methods to implement), not a @class_protocol (wrong use, based on the docs), hmm.

This obviously behaves different than in objective-c. What is inherent in the obj-c version of this that would conform to NSObjectProtocol? NSObject. Every class and C eventually rolls up to this…

This is working so far:

I’ll report back here if this solution changes


Why I turned off email notifications

Just about a week ago I had an epiphany:
Email is a constant. It will never end.

More often than not nothing is actionable
I made a quick change — turn off all notifications for email. None shall pass.

NO EMAIL NOTIFICATIONS. I’ve been doing this for about a year now on my phone and it’s amazing. I’ve been doing it for 3 years on my laptop. I don’t know why I didn’t do it on all my devices sooner. (I don’t get outlook or gmail notifications). It lowers stress and helps me focus on actual tasks instead of context switching into email all the time. Context switching is expensive

Reply too fast, expectations are set

No arguments here. If someone thinks you respond to emails within 5 mins, they will expect it. When you don’t, you’ll be under delivering.

If it’s urgent, why are you using email?

This is a huge pet peeve of mine. "Did you have a chance to respond to that email I sent you 30 seconds ago?" drives me nuts. If it’s an emergency, send me an IM. If I’m offline or don’t respond, get up off your ass and walk over. If I’m remote and offline for some reason, text me.


Coding Under Par

when it’s midnight and I’m on a perceived roll with some coding challenge, there doesn’t appear to be any stopping me. I “have all night,” or at least that’s what my monkey brain says. Of course, the smarter half of me knows I should be getting calling it a day and getting some much-needed rest.

I hear this. As I get older, and keep to a rigid sleep schedule, I tend to find myself being useless after 9pm. I do miss the old days io burning through until 2am. Now that flux exists to take care of the circadian issues, we should be able to burn all night. Right? RIGHT!?!


Looping through subviews and downcasting in Swift

I’ve been playing around with Auto-Layout. This snippet was helpful to see what constraints were set on what views in my View Hierarchy.

Getting the downcast right on the subviews Array took a few tries:


Functions or Read-Only Properties in Swift?

I’m not sure which is better.  If it’s returning something that is directly tied to the class: a slice/dice of properties is already has, I’m leaning towards properties. Because of the many examples I feel like read-only properties are the way to do.  I’m not the only person wondering, so that’s validating.



[sourcecode wraplines=false gutter=false autolinks=false]
Fool by randomness and the black swan

   foo fo fo fo offoofoofo offo


Parsing sentences from a String in Swift

I’ve been looking at how to parse sentences from text recently. While I’m still looking for a more Machine Learning approach, I found NSStringEnumerationBySentences which can get me there faster (for now).  I need to get all of the sentences from a given String.  This could easily be an Objective-C category method.  But, I’m trying to learn as much Swift as I can. I haven’t played with extensions yet. Here we go.

enumerateSubstringsInRange:options:usingBlock: is what I’ll need, but I need the extension first:

Fiddling with Swift’s closure syntax for a little while, and using the shorthand for NSStringEnumerationBySentences, I end up with this:

This could have been condensed even more, but I find this very hard to read:

Ah, but alas. Now I can’t use this in Objective-C. It won’t see the String extension.  It needs to be NSString:

I haven’t quite figured out the naming convention for Swift Extension files yet. Right now, I have this in StringExtentions.swift in my categories folder.  Though…. I guess to be proper it should be NSStringExtentions.swift…