Skip to content

Instantly share code, notes, and snippets.

View jessesquires's full-sized avatar
🏴
free labor

Jesse Squires jessesquires

🏴
free labor
View GitHub Profile
@jessesquires
jessesquires / update_xcode_plugins.sh
Last active April 4, 2016 20:35 — forked from neonichu/update_xcode_plugins
Update DVTPlugInCompatibilityUUIDs for installed plugins
#!/bin/sh
# ID='A16FF353-8441-459E-A50C-B071F53F51B7' # Xcode 6.2
# ID='992275C1-432A-4CF7-B659-D84ED6D42D3F' # Xcode 6.3
# ID='AABB7188-E14E-4433-AD3B-5CD791EAD9A3' # Xcode 7b5
# ID='7265231C-39B4-402C-89E1-16167C4CC990' #Xcode 7.1.1
ID='F41BD31E-2683-44B8-AE7F-5F09E919790E' # Xcode 7.2
PLIST_BUDDY=/usr/libexec/PlistBuddy
@leemorgan
leemorgan / AutoAssets.md
Last active August 29, 2015 14:25
Xcode build script to generate a Swift file enumerating the project's assets
@nicklockwood
nicklockwood / gist:21495c2015fd2dda56cf
Last active August 13, 2020 13:57
Thoughts on Swift 2 Errors

Thoughts on Swift 2 Errors

When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.

So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.

Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?

I'm going to cover three things in this post:

Swift Don'ts

  • Don't add code cruft. Avoid parentheses around conditions in if-statements or with the return keyword. Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line.
  • Don't use ALL_CAPS; use camelCase
  • Don't fight type inference. Use enumeration prefixes, self-references, and class names (with constructors) only when necessary or to clarify coding intent.
  • Don't use var when let is appropriate, especially for properties. The compiler better optimizes let statements for items whose values will not change during their lifetime. For example, Apple writes, "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
  • Don't use classes when structs will do. Use class
@AlamofireSoftwareFoundation
AlamofireSoftwareFoundation / alamofire-04-27-2015-statement.md
Last active January 10, 2020 06:25
A response to recent concerns about security vulnerabilities in AFNetworking

Last week, a number of publications ran a story about 1,000's of apps allegedly being vulnerable due to an SSL bug in AFNetworking. These articles contain a number of inaccurate and misleading statements on this matter.

We are publishing this response to clarify and correct these statements.

Background Information

For those not familiar with AFNetworking, here are some relevant details about the library for this story:

  • AFNetworking is an open source, third-party library that provides convenience functionality on top of Apple's built-in frameworks.
  • One component of AFNetworking is AFSecurityPolicy, which handles authentication challenges according to a policy configured by the application. This includes the evaluation of X.509 certificates which servers send back when connecting over HTTPS.
@implementation NSManagedObject (TCCreation)
+ (instancetype)tc_insertIntoContext:(NSManagedObjectContext*)ctx
{
for(NSEntityDescription *desc in [ctx.persistentStoreCoordinator.managedObjectModel entities]) {
if([desc.managedObjectClassName isEqual:NSStringFromClass(self)]) {
return [[self alloc] initWithEntity:desc insertIntoManagedObjectContext:ctx];
}
}
NSAssert(NO, @"This class does not exist in the managed object model for %@", ctx);
return nil;
@airspeedswift
airspeedswift / ProtocolsVsGenerics.swift
Last active November 25, 2015 18:50
Timing the difference between protocols and protocol-constrained generics
import Darwin
import CoreFoundation.CFDate
protocol NumberGeneratorType {
mutating func generateNumber() -> Int
}
struct RandomGenerator: NumberGeneratorType {
func generateNumber() -> Int {
return Int(arc4random_uniform(10))
// integerWithBytes.swift
// as seen in http://natecook.com/blog/2015/03/a-sanatorium-for-swift-generics/
//
// (c) 2015 Nate Cook, licensed under the MIT license
protocol BitshiftOperationsType {
func <<(lhs: Self, rhs: Self) -> Self
func >>(lhs: Self, rhs: Self) -> Self
func <<=(inout lhs: Self, rhs: Self)
func >>=(inout lhs: Self, rhs: Self)
@natecook1000
natecook1000 / NSScanner+Swift.swift
Created March 3, 2015 20:13
Swift-friendly NSScanner methods
// NSScanner+Swift.swift
// A set of Swift-idiomatic methods for NSScanner
//
// (c) 2015 Nate Cook, licensed under the MIT license
import Foundation
extension NSScanner {
// MARK: Strings
@krzyzanowskim
krzyzanowskim / integerWithBytes
Last active May 30, 2018 03:36
integerWithBytes Swift way
// Playground - noun: a place where people can play
import Foundation
typealias Byte = UInt8
protocol GenericIntegerType: IntegerType {
init(_ v: Int)
init(_ v: UInt)
init(_ v: Int8)