(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
#!/usr/bin/env python | |
from pocket import Pocket | |
import webbrowser, sys | |
# Get consumer key from cmd line | |
consumer_key = sys.argv[1] | |
request_token = Pocket.get_request_token( | |
consumer_key=consumer_key, |
<?xml version="1.0" encoding="UTF-8"?> | |
<Bucket | |
type = "2" | |
version = "2.0"> | |
<Breakpoints> | |
<!-- All Exceptions --> | |
<BreakpointProxy | |
BreakpointExtensionID = "Xcode.Breakpoint.ExceptionBreakpoint"> | |
<BreakpointContent |
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:
#!/usr/bin/env bash | |
set -e | |
## Developer Environment | |
# setup | |
mkdir -p ~/setup | |
cd ~/setup |
Note: as @clibois mentioned below, due to the DRM Netflix uses, all decoding has to be done in CPU, making it somewhat choppy.
Note 2: Even the RPi 3 suffers from these CPU limitations. There is the potentially risky option of overclocking your RPi 3, but I haven't tried this.
If you manage to get smooth playback, please contact me, or post your solution here
UPDATE: I can no longer get this method to work. I have tried using Chromium v47, and v48, and both result in Netflix error "Oops, something went wrong" / C7053-1807, for which I can find no description online. If you manage to get things up and running, please contact me!
# No results from tests or mocks files: | |
Workspace - None of the following conditions are met - Filename - matches regex | |
(.*(Spec|Test|Mock)s?\.)|(Mock).* | |
# Only search in swift files: | |
Workspace - All of the following conditions are met - File Extension - is Equal to | |
swift | |
When you look up how to compile swift faster for debug builds, people very earnestly give advice that seems contradictory: you should "try using the whole module optimization flag," and also "never use whole module optimization for debugging". [^1]
This is confusing because some of us are using these two general words:
compilation: "turning text into an executable program"
#!/bin/zsh | |
cd "$(dirname "$0")/.." | |
if [[ -n "$CI" ]] || [[ $1 == "--fail-on-errors" ]] ; then | |
FAIL_ON_ERRORS=true | |
echo "Running in --fail-on-errors mode" | |
ERROR_START="" | |
COLOR_END="" | |
INFO_START="" |