davbeck

import UIKit


extension UIViewContentMode: CustomStringConvertible {
	public var description: String {
		switch self {
		case .scaleToFill:
			return "scaleToFill"
		case .scaleAspectFit:
			return "scaleAspectFit"

davbeck

Async Await

I love this proposal so much. Much of it is exactly how I’ve thought Swift’s concurrency model should look over the last year.

Making async a return attribute just like throws seems like the right solution to me. Building on top of callbacks (rather than introducing futures/promises) is also the right approach for swift. I think this proposal nails the problem right on the head: callbacks don't work well with the rest of Swift's error handling, is awkward, error prone, and yes, looks ugly.

One point that I've gone back and forth on is how strictly to enforce excecution order. For instance, in this example. it would make sense to allow the first 2 lines to excecute in parallel and excecute the third line once they both complete:

let a = await foo()

davbeck

Swift build time profiling

Linkdin (of all companies) published a shocking blog today on the performance of Swift build times. They claim that their project compiles faster on their lower speced MacBook Pros (and even a Mac mini) than their 12 core Mac Pros. Even though the Mac Pro is 4 years out of date, the raw number of cores gives it quit an advantage over the 4 core MacBook Pro and especially the 2 core Mac mini. What's even more shocking, is that when they lowered the number of threads available to the compiler, their build times actually went up. It's an interesting article and worth reading. I decided to test their numbers with my own project.

First, I tried building from the command line, cleaning each time to get consistent results:

time xcodebuild -workspace Engagement.xcworkspace -scheme Engagement -sdk iphoneos -configuration Debug clean build | xcpretty

davbeck

//
//  ServerObjectID.swift
//  Engagement
//
//  Created by David Beck on 3/10/17.
//  Copyright © 2017 ACS Technologies. All rights reserved.
//

import Foundation
import CoreData

davbeck

class TimelineManager<T> {
	weak var delegate: TimelineManagerDelegate?
}

protocol TimelineManagerDelegate: class {
	func timelineDidLoad<T>(timeline: TimelineManager<T>)
}

davbeck

	func testFormatterKit() {
		let timeFormatter = TTTTimeIntervalFormatter()
		timeFormatter.presentTimeIntervalMargin = 60
		timeFormatter.usesIdiomaticDeicticExpressions = true
		
		self.measure {
			let timeFormatter = TTTTimeIntervalFormatter()
			timeFormatter.presentTimeIntervalMargin = 60
			timeFormatter.usesIdiomaticDeicticExpressions = true
			

davbeck

#!/usr/bin/env bash

rm -rf /Users/davbeck/Library/Developer/Xcode/DerivedData

osascript -e 'quit app "Simulator"'
osascript -e "tell application \"Xcode\"
	close every window
end tell"
osascript -e 'quit app "Xcode"'

davbeck

let realmTimeZoneLookup: [String:String] = [
	"Dateline Standard Time": "GMT-1200",
	"UTC-11": "GMT-1100",
	"Hawaiian Standard Time": "Pacific/Honolulu",
	"Alaskan Standard Time": "America/Halifax",
	"Pacific Standard Time (Mexico)": "America/Tijuana",
	"Pacific Standard Time": "America/Los_Angeles",
	"US Mountain Standard Time": "America/Phoenix",
	"Mountain Standard Time (Mexico)": "America/La_Paz",
	"Mountain Standard Time": "America/Denver",

davbeck

Workflow

We use Jira to track bugs and features and git flow to track changes to the code. The workflow for a ticket goes as follows:

1. The developer moves a ticket into the "In Progress" column, assigning it to themselves.

2. The developer creates a new branch off of develop (or another feature branch if necessary) naming it feature/REALM-XXXXX-description where "REALM-XXXXX" is the ticket number in Jira and "description" is a 1-3 word description of the ticket.

3. Any changes needed to fulfill the ticket are performed in 1 or more commits. Each commit should start with the ticket number, as in REALM-XXXXX Added link to make a gift. Prefixing the ticket number here causes the commit to appear in Jira.

davbeck

Swift options

Recently, 2 Swift Evolution proposal results have really disappointed me. Together they move Swift away from the flexibility of using method parameters as option lists.

SE-0060 Enforcing order of defaulted parameters, which was accepted, removes the ability to provide optional parameters in any order you like. I had actually hoped to go the other direction and extend this ability to include required parameters. Now, as you add and remove parameters to a call site, you have to make sure to do so in the proper order. As the number of parameters a method takes grows, and as the relation between them gets weaker, it becomes more and more difficult to determine the correct positioning without referring to documentation.

SE-0084 Allow trailing commas in parameter lists and tuples was rejected. This proposal so