Chang Liu fluency03

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Pull Request Process

Ensure any install or build dependencies are removed before the end of the layer when doing a

People

`:bowtie:`	😄 `:smile:`	😆 `:laughing:`
😊 `:blush:`	😃 `:smiley:`	☺️ `:relaxed:`
😏 `:smirk:`	😍 `:heart_eyes:`	😘 `:kissing_heart:`
😚 `:kissing_closed_eyes:`	😳 `:flushed:`	😌 `:relieved:`
😆 `:satisfied:`	😁 `:grin:`	😉 `:wink:`
😜 `:stuck_out_tongue_winking_eye:`	😝 `:stuck_out_tongue_closed_eyes:`	😀 `:grinning:`
😗 `:kissing:`	😙 `:kissing_smiling_eyes:`	😛 `:stuck_out_tongue:`

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil

	# Elasticsearch Cheatsheet - an overview of commonly used Elasticsearch API commands

	# cat paths
	/_cat/allocation
	/_cat/shards
	/_cat/shards/{index}
	/_cat/master
	/_cat/nodes
	/_cat/indices
	/_cat/indices/{index}

	// @cpdean
	// demonstrates how to have one promise kick off
	// an additional arbitrary number of promises, and
	// then merge their results down again after
	// all the promises are complete.
	var Q = require('q'); // "q": "~1.0.0"


	// initial query that generates seed data for more work to be done
	function fakeQuery(){

	return promises.reduce(function (accumulated, value) {
	return Q.when(accumulated, function (accumulated) {
	return Q.when(value, function (value) {
	return accumulated + value;
	});
	});
	})

	// Q sample by Jeff Cogswell

	/*===========
	We want to call these three functions in sequence, one after the other:

	First we want to call one, which initiates an ajax call. Once that
	ajax call is complete, we want to call two. Once two's ajax call is
	complete, we want to call three.

	BUT, we don't want to just call our three functions in sequence, as this quick

	// `promise` is some operation that may succeed (fulfill) or fail (reject)
	var newPromise = promise.then(
	function () {
	return delay(1000);
	},
	writeError
	);

	// If `promise` fulfills, `newPromise` will fulfill in 1000 ms.
	// If `promise` rejects and writing to the error log succeeds,

	"use strict";

	// Uses jQuery and Q.

	var API_KEY = "whatever";

	function getFlickrResponseAsync(method, responseProperty, params) {
	var deferred = Q.defer();

	$.ajax("http://www.flickr.com/services/rest/", {

	'use strict';
	var Q = require('q');

	/*
	Here are some basic examples of promises using the Q library https://github.com/kriskowal/q).
	To run a specific scenario, install an execution environment and uncomment the respective
	method call (runScenarioX()).
	The code is tested using node.js v0.12.7 (https://nodejs.org/en/) and Q v1.4.1 library
	(https://www.npmjs.com/package/q).
	*/