Steve Brambilla stevebrambilla

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

My Git Deploy Workflow

I use this for static and simple [Sinatra][1] based sites -- great for prototyping simple apps. Credit goes to http://toroid.org/ams/git-website-howto for the original idea.

If you don't know what this is, here's an example of how I deploy my website/app to a server:

# create/update/delete files in my site
git add .
git commit -m "description of the changes I made"

git push

	Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right.
	If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it.
	If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately.
	If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions.
	If you remove possibilities (for example, Swift removes the possibility of things being nil unless

	// See: https://devforums.apple.com/message/1000934#1000934

	import Foundation

	// Logic

	operator prefix ¬ {}
	@prefix func ¬ (value: Bool) -> Bool {
	return !value
	}

	// Taken from the commercial iOS PDF framework http://pspdfkit.com.
	// Copyright (c) 2014 Peter Steinberger, PSPDFKit GmbH. All rights reserved.
	// Licensed under MIT (http://opensource.org/licenses/MIT)
	//
	// You should only use this in debug builds. It doesn't use private API, but I wouldn't ship it.

	// PLEASE DUPE rdar://27192338 (https://openradar.appspot.com/27192338) if you would like to see this in UIKit.

	#import <objc/runtime.h>
	#import <objc/message.h>

	//
	// Copyright (c) 2012-2015 Cédric Luthi / @0xced. All rights reserved.
	//

	#import <Foundation/Foundation.h>

	#if TARGET_OS_SIMULATOR

	static const char *fakeCarrier;
	static const char *fakeTime;