Guy Kisel guykisel

npm shrinkwrap is useful, but maddening (once it's in place and you want to update a package).

Say you've got a package.json with module ember-cli as a devDependency currently at version 1.13.1. And you have an npm-shrinkwrap.json file too, generated with the --dev flag.

If you change the version of ember-cli to, say, 1.13.8 in package.json and run npm install, nothing will happen.

If you do that and manually change references in the shrinkwrap file, you will still have trouble (as nested dependencies may now be incorrect).

So what do we actually do?

So you want to ask for help? Fill in this template. It'll save us all a lot of time.

Short summary of the problem

What are you doing? What's going wrong? Why do you need help? Keep this short and simple.

What's your best guess of what's causing the problem?

If you haven't already, take a moment to think about this. Do you have any ideas?

ANNOUNCEMENT

I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!

\

Update HISTORY.md
Commit the changes:

git add HISTORY.md
git commit -m "Changelog for upcoming release 0.1.1."

Update version number (can also be minor or major)

bumpversion patch

Update May 2017

Eric Bidelman has documented some of the common workflows possible with headless Chrome over in https://developers.google.com/web/updates/2017/04/headless-chrome.

Update

If you're looking at this in 2016 and beyond, I strongly recommend investigating real headless Chrome: https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md

Windows and Mac users might find using Justin Ribeiro's Docker setup useful here while full support for these platforms is being worked out.

Creating a Happy Git Environment on OS X

Step 1: Install Git

brew install git bash-completion

Configure things:

git config --global user.name "Your Name"

git config --global user.email "[email protected]"

	node {
	echo 'Results included as an inline comment exactly how they are returned as of Jenkins 2.121, with $BUILD_NUMBER = 1'
	echo 'No quotes, pipeline command in single quotes'
	sh 'echo $BUILD_NUMBER' // 1
	echo 'Double quotes are silently dropped'
	sh 'echo "$BUILD_NUMBER"' // 1
	echo 'Even escaped with a single backslash they are dropped'
	sh 'echo \"$BUILD_NUMBER\"' // 1
	echo 'Using two backslashes, the quotes are preserved'
	sh 'echo \\"$BUILD_NUMBER\\"' // "1"

	Philosophical:
	* writing lines of code is one of the least valuable things I can do
	* cultivate your impatience
	* reject the status quo, unless we can re-derive it from first-principles
	* engineers imprint on the first languages (techniuqes, frameworks or technology) that we find success with (unconsciously seen as caregivers, which we defend w/o always knowing why)
	* we tend to overvalue the familiar/known; we tend to undervalue the unfamiliar/unknown, this interferes with our receptiveness to new ideas and personal growth
	* we're 90% composed of bad habits; many of our best habits become bad as time passes; this allows us to filter for the fundamental; the great
	* make doing the right thing easier than any other thing, or we will fail to achieve greatness, or break bad habits
	* be conscious, be intentional
	* "is this the highest we can aim?" (I prefer this over "is this the best we can do", the former is aspirational, the latter is judgemental)

	This gist includes oozie workflow components (streaming map reduce action) to execute
	python mapper and reducer scripts to parse Syslog generated log files using regex;
	Usecase: Count the number of occurances of processes that got logged, by month, and process.

	Pictorial overview of workflow:
	--------------------------------
	http://hadooped.blogspot.com/2013/07/apache-oozie-part-5-oozie-workflow-with.html

	Includes:
	---------

	"use strict";

	// `f` is assumed to sporadically fail with `TemporaryNetworkError` instances.
	// If one of those happens, we want to retry until it doesn't.
	// If `f` fails with something else, then we should re-throw: we don't know how to handle that, and it's a
	// sign something went wrong. Since `f` is a good promise-returning function, it only ever fulfills or rejects;
	// it has no synchronous behavior (e.g. throwing).
	function dontGiveUp(f) {
	return f().then(
	undefined, // pass through success