TheMetalCode

fastlane/fastlane#13833

This script may be useful to you if you use fastlane for iOS CI builds and your Apple developer portal account uses 2-factor authentication. There is reason to suppose that Apple may not be persisting these sessions for as long as they used to, and hence you might find yourself needing to update FASTLANE_SESSION for your CI projects more often than usual.

This script is a way to mostly automate the process of updating FASTLANE_SESSION if you use CircleCI as your CI provider. It expects to find your Apple username in env as FASTLANE_USER, your Apple password as FASTLANE_PASSWORD, and your CircleCI API token as CIRCLE_API_TOKEN. It then executes fastlane spaceauth and waits for you to put in your 2FA code. From there, it parses out the session data and then uses the CircleCI API to populate the specified projects with the newly updated FASTLANE_SESSION. You'll

EnsekiTT

%YAML:1.0

#--------------------------------------------------------------------------------------------
# Camera Parameters. Adjust them!
#--------------------------------------------------------------------------------------------

# Camera calibration and distortion parameters (OpenCV) 
Camera.fx: 1467.836136
Camera.fy: 1471.712197
Camera.cx: 941.204100

lattner

Swift Concurrency Manifesto

Author: Chris Lattner

Chinese Translation by Jason Yu

Contents

• Introduction
• Overall Vision

lattner

Async/Await for Swift

• Proposal: SE-XXXX
• Authors: Chris Lattner, Joe Groff

Introduction

Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.

This paper introduces a first class Coroutine model to Swift. Functions can opt into to being async, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.

numist

import Darwin // Provides: sin/cos/tan

// memoize function from https://gist.github.com/berkus/8a9e104f8aac5d025eb5
func memoize<T: Hashable, U>( body: ( (T)->U, T )->U ) -> (T)->U {
    var memo = Dictionary<T, U>()
    var result: ((T)->U)!
    result = { x in
        if let q = memo[x] { return q }
        let r = body(result, x)
        memo[x] = r

anhar

Setting up iOS Universal Links

Table of Contents

• Resources
  • General link resources
  • Validation tools
• Server configuration
  • Apple JSON Metadata file
• Create a JSON file called apple-app-association

trevnorris

While the standard 80 character limit for source code can be traced back to the
IBM punch card[1] it can still be seen as a good upper bound for how long lines
of text should be on modern high definition displays.

First thing we must acknowledge is that source code is not read in the
traditional sense. Instead developers scan the source using non-linear eye
movements[2] or stay fixated in a small area of code while working out the
logical details of code being written. The fixation on a single location, even
for more than a few seconds, leads to a loss of visual accuity. Which occurs
when the eyes do not perform frequent saccadic eye movements.[3] Further

beccadax

let color = "blue"
let num = 42

localized("Colorless green ideas sleep furiously.")
localized("Colorless \(color) ideas sleep furiously.")
localized("\(num.formatted("%05d")) colorless green ideas sleep furiously.")

FredericJacobs

#import "AppDelegate.h"

@implementation AppDelegate

- (void)applicationDidFinishLaunching:(UIApplication *)application {
    NSLog(@"Hello Bitcode!");
}

@end

djspiewak

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

• Two developers working on independent features must never be blocked by each other
  • No code freeze! Ever! For any reason!
• A developer must be able to base derivative work on another developer's work, without waiting for any third party
• Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
• Developers must be able to work on multiple features simultaneously, or at lea