evgenyneu

#!/bin/sh

#
# Script for Xcode and Carthage
# ------------------------------
#
# Dismisses changes to all the frameworks except the given frameworks in the iOS build folder.
# This is used to undo the changes done to the framework build after `carthage update` command.
#
#

rbobbins

Wil Turner, Brook Callhan: Speakers

##3 Main components/concepts that enable UI Testing:##

• UITesting
  • Find and interact w/ UI elements
  • Validate UI properties and state
• UIrecording
  • Updated test reports to include UI testing data
  • UI testing is enabled by XCTest and UI Accesibility

jackreichert

extension NSURL {
    func getKeyVals() -> Dictionary<String, String>? {
        var results = [String:String]()
        var keyValues = self.query?.componentsSeparatedByString("&")
        if keyValues?.count > 0 {
            for pair in keyValues! {
                let kv = pair.componentsSeparatedByString("=")
                if kv.count > 1 {
                    results.updateValue(kv[1], forKey: kv[0])
                }

lucasdavila

# see the current limits
$ sysctl -a | grep maxproc

# increase it
$ sudo sysctl -w kern.maxproc=xxxx
$ sudo sysctl -w kern.maxprocperuid=xxx

# run at startup
$ sudo vim /etc/sysctl.conf

correia

//
//  Swift-KVO
//
//  Created by Jim Correia on 6/5/14.
//  Copyright (c) 2014-2015 Jim Correia. All rights reserved.
//
//  Update: 6/17/2014
//
//  KVOContext has gone away; use the same idiom you'd use from Objective-C for the context
//

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.