- Ubuntu 14.04, 16.04, or 16.10
- Open up terminal
- Install core deps:
sudo apt-get install clang libicu-dev git
/* | |
MKR1000 + PIXIE 3w leds | |
without sofrwareSerial | |
UNO -> 1(TX) | |
MKR1000 -> 14(TX) | |
*/ | |
//#include "SoftwareSerial.h" | |
#include "Adafruit_Pixie.h" |
struct Keycode { | |
// Layout-independent Keys | |
// eg.These key codes are always the same key on all layouts. | |
static let returnKey : UInt16 = 0x24 | |
static let enter : UInt16 = 0x4C | |
static let tab : UInt16 = 0x30 | |
static let space : UInt16 = 0x31 | |
static let delete : UInt16 = 0x33 | |
static let escape : UInt16 = 0x35 |
I recently switched over to neovim (see my screenshots at the bottom). Below is my updated config file.
It's currently synchronized with my .vimrc
config except for a block of neovim-specific terminal key mappings.
This is still a work in progress (everyone's own config is always a labor of love), but I'm already extremely pleased with how well this is working for me with neovim. While terminal mode isn't enough to make me stop using tmux, it is quite good and I like having it since it simplifies my documentation workflow for yanking terminal output to paste in a markdown buffer.
These days I primarily develop in Go. I'm super thrilled and grateful for fatih/vim-go,
File > New > Project...
Create a Package.swift
file in your root project directory, add dependencies, then run swift package fetch
on the command line in the same directory. We’re not going to run swift build
because it will just complain.
#include <Servo.h> | |
Servo myservo; | |
const int servoPin = 9; | |
const int buttonPin = 12; | |
const int ledPin = 13; | |
void setup() { | |
myservo.attach(servoPin); |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
Installation procedure for pre-build actions to automatically populate Xcode Info.plist with dynamic data.
Edit Xcode Scheme and add a pre-action script.
Copy the contents of preaction.sh
into the pre-action script box.
Keeping a private key in a keychain is a great way to secure it. The key data is encrypted on disk and accessible only to your app or the apps you authorize. However, to use the key, you must briefly copy a plain-text version of it into system memory. While this presents a reasonably small attack surface, there’s still the chance that if your app is compromised, the key could also become compromised. As an added layer of protection, you can protect a private key using the Secure Enclave. >
let styles: [UIFont.TextStyle] = [ | |
// iOS 17 | |
.extraLargeTitle, .extraLargeTitle2, | |
// iOS 11 | |
.largeTitle, | |
// iOS 9 | |
.title1, .title2, .title3, .callout, | |
// iOS 7 | |
.headline, .subheadline, .body, .footnote, .caption1, .caption2, | |
] |