JaviSoto

blueprint:
  name: ZHA - Moes Tuya Smart Knob (TS004F) controller for light dimming
  description: Control a light with a Tuya smart knob.
  domain: automation
  source_url: https://gist.github.com/JaviSoto/0a419981a2f3a8d5be0c88a9d4f7bd6d#file-zha-moes-zigbee-rotary-smart-knob-remote-control-yaml
  input:
    remote:
      name: Smart Knob Device
      description: Moes Tuya Smart Knob Device to use
      selector:

JaviSoto

Following the tradition from last year, here's my complete list of all interesting features and updates I could find in Apple's OSes, SDKs and developer tools that were announced at this year's WWDC. This is based on the keynotes, the "What's New In ..." presentations and some others, Apple's release notes, and blog posts and tweets that I came across in the last few weeks.

If for some reason you haven't watched the talks yet, I really recommend watching at least the "State of the Union" and the "What's New In" intros for the platforms you're interested in. The unofficial WWDC Mac app is great way to download the videos and keep track of what you've already watched.

If you're interested, here are my WWDC 2015 notes (might be useful if you're planning to drop support for iOS 8 now and start using some iOS 9 APIs).

---

OSX → macOS 10.12 Sierra

JaviSoto

#!/bin/bash

set -e
trap "exit;" SIGINT SIGTERM

unset TOOLCHAINS

ALIAS=mxcl
VERSION="3.0.0-${ALIAS}+$(date +%Y%m%d)"
PREFIX="$HOME/Library/Developer/Toolchains"

JaviSoto

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 

JaviSoto

#!/bin/bash

# https://gist.github.com/949831
# http://blog.carbonfive.com/2011/05/04/automated-ad-hoc-builds-using-xcode-4/

# command line OTA distribution references and examples
# http://nachbaur.com/blog/how-to-automate-your-iphone-app-builds-with-hudson
# http://nachbaur.com/blog/building-ios-apps-for-over-the-air-adhoc-distribution
# http://blog.octo.com/en/automating-over-the-air-deployment-for-iphone/
# http://www.neat.io/posts/2010/10/27/automated-ota-ios-app-distribution.html

JaviSoto

// Smart little helper to find main thread hangs. Enable in appDidFinishLaunching.
// Only available with source code in DEBUG mode.
@interface PSPDFHangDetector : NSObject
+ (void)startHangDetector;
@end


@implementation PSPDFHangDetector
+ (void)startHangDetector {
#ifdef DEBUG