View react-logger.js
// put this at the top of your app
const setState = Component.prototype.setState
Component.prototype.setState = function(nextState) {
if (this.shouldComponentUpdate) {
console.log('shouldComponentUpdate', (
this.shouldComponentUpdate(this.props, nextState)
View GPG and git on

GPG and git on macOS


No need for homebrew or anything like that. Works with and the command line.

  1. Install -- I'd suggest to do a customized install and deselect GPGMail.
  2. Create or import a key -- see below for
  3. Run gpg --list-secret-keys and look for sec, use the key ID for the next step
  4. Configure git to use GPG -- replace the key with the one from gpg --list-secret-keys
View provideContext.js
import React from 'react'
const provideContext = (contextKey, contextType) => (
childContextTypes: {
[contextKey]: contextType
getChildContext() {
const { children, ...props } = this.props
View .profile
# In order for gpg to find gpg-agent, gpg-agent must be running, and there must be an env
# variable pointing GPG to the gpg-agent socket. This little script, which must be sourced
# in your shell's init script (ie, .bash_profile, .zshrc, whatever), will either start
# gpg-agent or set up the GPG_AGENT_INFO variable if it's already running.
# Add the following to your shell init to set up gpg-agent automatically for every shell
if [ -f ~/.gnupg/.gpg-agent-info ] && [ -n "$(pgrep gpg-agent)" ]; then
source ~/.gnupg/.gpg-agent-info
From #electron Slack
Hi guys, I'm really confused by autoUpdater API on windows. On one hand, I believe windows autoUpdater
has an uniform API with OSX, but on the other hand, I know squirrel handles OSX and Windows quite differently.
So my question is do I need to handle to squirrel events? Or I ONLY need to use the autoUpdater events to
handle update logic?
On windows
And also I'm confused when squirrel handles install and when squirrel handles update. If write install logic
into main.js, does that mean every time my app starts squirrel will try to re-install?
apt-get -y update
apt-get -y install nginx-extras build-essential libpcre3-dev libssl-dev libgeoip-dev libpq-dev libxslt1-dev libgd2-xpm-dev
wget -c
tar zxvf openresty-
cd openresty-
./configure \
--sbin-path=/usr/sbin/nginx \
--conf-path=/etc/nginx/nginx.conf \
View rabbitmq.txt
rabbitmqctl add_user test test
rabbitmqctl set_user_tags test administrator
rabbitmqctl set_permissions -p / test ".*" ".*" ".*"
View oauth

HMAC over Basic Auth

This is a pattern I use fairly frequently for administrative APIs. It's a sort of OAuth lite for non-public APIs that produces good quality tokens. Once you build it a few times, it's not any harder than using arbitrary basic auth in your APIs.

The client and the app share a secret, which is never transmitted across the wire. The client uses this secret to create an HMAC digest of a payload consisting of the current time and a random nonce value. The nonce is provided as the Basic Authorization user, and the resulting HMAC digest is provided as the Basic Authorization password.

A similar process is followed on the server side. The server uses the supplied nonce, its own time, and its own copy of the shared secret. It may want to check against several tokens across a small window of times to account for clock drift.

  • Using HMAC means the secret is never transmitted across the wire. Theoretically these are safe across plaintext connections, but you're using TLS anyway, right?
  • The i
jhead -n%Y-%m-%d\ %H.%M%.%S *.jpg
View gist:5b876d9c5eea4c9e411c
import AVFoundation
import Foundation
// The maximum number of audio buffers in flight. Setting to two allows one
// buffer to be played while the next is being written.
private let kInFlightAudioBuffers: Int = 2
// The number of audio samples per buffer. A lower value reduces latency for
// changes but requires more processing but increases the risk of being unable
// to fill the buffers in time. A setting of 1024 represents about 23ms of