(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="" |