λ🏺 codekiln

In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

query
mutation

Reference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.

Tabs and Windows

Function	Shortcut
New Tab	`⌘` + `T`
Close Tab or Window	`⌘` + `W` (same as many mac apps)
Go to Tab	`⌘` + `Number Key` (ie: `⌘2` is 2nd tab)
Go to Split Pane by Direction	`⌘` + `Option` + `Arrow Key`
Cycle iTerm Windows	`⌘` + `backtick` (true of all mac apps and works with desktops/mission control)

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

Interface Versioning (InterVer)

Never break backcompat, keep the API nimble

An extension of SemVer with a stricter (yet more realistic) backcompat guarantee, that provides more flexibility to change the API, for libraries that are packaged and downloaded (not services accessed remotely over the Internet (see Note 4)).

Get Git log in JSON format

git log --pretty=format:'{%n  "commit": "%H",%n  "abbreviated_commit": "%h",%n  "tree": "%T",%n  "abbreviated_tree": "%t",%n  "parent": "%P",%n  "abbreviated_parent": "%p",%n  "refs": "%D",%n  "encoding": "%e",%n  "subject": "%s",%n  "sanitized_subject_line": "%f",%n  "body": "%b",%n  "commit_notes": "%N",%n  "verification_flag": "%G?",%n  "signer": "%GS",%n  "signer_key": "%GK",%n  "author": {%n    "name": "%aN",%n    "email": "%aE",%n    "date": "%aD"%n  },%n  "commiter": {%n    "name": "%cN",%n    "email": "%cE",%n    "date": "%cD"%n  }%n},'

The only information that aren't fetched are:

%B: raw body (unwrapped subject and body)
%GG: raw verification message from GPG for a signed commit

This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.

In that post I talked about 3 main reasons for moving from require.js to webpack:

Common JS support
NPM support
a healthy loader/plugin ecosystem.

Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.

	Byobu is a suite of enhancements to tmux, as a command line
	tool providing live system status, dynamic window management,
	and some convenient keybindings:

	F1 * Used by X11 *
	Shift-F1 Display this help
	F2 Create a new window
	Shift-F2 Create a horizontal split
	Ctrl-F2 Create a vertical split
	Ctrl-Shift-F2 Create a new session

	{
	// http://eslint.org/docs/rules/

	"env": {
	"browser": true, // browser global variables.
	"node": false, // Node.js global variables and Node.js-specific rules.
	"worker": false, // web workers global variables.
	"amd": false, // defines require() and define() as global variables as per the amd spec.
	"mocha": false, // adds all of the Mocha testing global variables.
	"jasmine": false, // adds all of the Jasmine testing global variables for version 1.3 and 2.0.

	# -- coding:utf-8 --
	from __future__ import absolute_import
	from __future__ import unicode_literals
	from __future__ import print_function

	import json
	import uuid
	import time
	import gevent


	class Rover:
	pass