davbeck

_actionDelayTimer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:[NSBlockOperation blockOperationWithBlock:^{
    NSLog(@"Well this is useless.");
}] selector:@selector(start) userInfo:nil repeats:YES];

davbeck

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

davbeck

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

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

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

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

import Foundation
import CoreData

davbeck

//
//  NSImage+TMStretchable.h
//  ThinkMessenger
//
//  Created by David Beck on 1/11/12.
//  Copyright (c) 2012 ThinkUltimate. All rights reserved.
//

#import <AppKit/AppKit.h>

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

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

import UIKit


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

davbeck

- (void)drawRect:(CGRect)drawRect
{
	CGContextRef context = UIGraphicsGetCurrentContext();
    
    CGContextSaveGState(context);
    CGContextClipToDrawing(context, self.bounds, ^(CGContextRef maskContext, CGRect rect){
        UIGraphicsPushContext(maskContext);
        
        [[UIColor whiteColor] setFill];
        CGContextFillRect(maskContext, rect);