First, learn JSON. It's not programming language, not even close. Just follow syntax rules and you will be fine.
// This gist demonstrates how you can implement versioning for a Codable struct to support loading | |
// old serialized data after changing the structure. Notable features of this solution: | |
// | |
// * No need to make new properties optional, or to perform post-processing on the struct after | |
// loading in ordeer to populate missing values | |
// * No need to change the call site - from the outside this struct behaves just the same | |
// as if we had implemented codable directly in the normal way. | |
// * Versioning can be applied individually to parents or leaves in a larger tree of | |
// structs without affecting the other elements | |
// * This approach will work even if the original struct was not designed with versioning in mind |
// | |
// XCUIElement+Wait.swift | |
// | |
// Created by Ryan Paterson on 12/12/2020. | |
// | |
import XCTest | |
extension XCUIElement { | |
/// The period of time in seconds to wait explicitly for expectations. |
class FairPlayer: AVPlayer { | |
private let queue = DispatchQueue(label: "com.icapps.fairplay.queue") | |
func play(asset: AVURLAsset) { | |
// Set the resource loader delegate to this class. The `resourceLoader`'s delegate will be | |
// triggered when FairPlay handling is required. | |
asset.resourceLoader.setDelegate(self, queue: queue) | |
// Load the asset in the player. |
const puppeteer = require('puppeteer'); | |
(async () => { | |
const browser = await puppeteer.launch(); | |
const page = await browser.newPage(); | |
// Adjustments particular to this page to ensure we hit desktop breakpoint. | |
page.setViewport({width: 1000, height: 600, deviceScaleFactor: 1}); | |
await page.goto('https://www.chromestatus.com/samples', {waitUntil: 'networkidle'}); |
<?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
<plist version="1.0"> | |
<dict> | |
<key>PreferenceSpecifiers</key> | |
<array> | |
<dict> | |
<key>DefaultValue</key> | |
<string></string> | |
<key>Key</key> |
If a project has to have multiple git repos (e.g. Bitbucket and Github) then it's better that they remain in sync.
Usually this would involve pushing each branch to each repo in turn, but actually Git allows pushing to multiple repos in one go.
If in doubt about what git is doing when you run these commands, just
POST /osc/commands/execute | |
{ | |
"name": "camera.startSession", | |
"parameters": {} | |
} | |
#shoot | |
192.168.1.1/osc/commands/execute | |
{ | |
"name": "camera.takePicture", |
What xcode project/workspace file we're using. If you specify a project on the command-line and that project has an associated workspace, the project is still aware of its existence within the workspace. As an example, worspace level schemes will be available to xcodebuild even if you specify a project on the command line.
Specify the scheme to use for build. Schemes specify multiple build/test targets along with environment args and command line parameters. Schemes must be marked "shared" in the xcode UI in order to be available to xcodebuild. For any particular build/test action there is a default configuration when you use a scheme from the Xcode UI.
# --------------------------------------------------------------------------- | |
# | |
# Description: This file holds all my BASH configurations and aliases | |
# | |
# Sections: | |
# 1. Environment Configuration | |
# 2. Make Terminal Better (remapping defaults and adding functionality) | |
# 3. File and Folder Management | |
# 4. Searching | |
# 5. Process Management |