hexmanshu

Stevey's Google Platforms Rant

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real

Rectifier

The diode bridge is the simplest rectifier I know.

Rectifier lets you share a directory with a docker container (just like $yourvm shared folders).

You don't have to install anything in your containers, and you only need to install diod in the host. diod is packaged on Ubuntu/Debian distros, and will automatically be apt-get install-ed if needed.

Since it uses diod to make a bridge, I called it rectifier. Yeah, that sucks, so if you have a better name, I'll steal it!

Using dtruss on vim's `:w`

Ever wonder what happens when you save a file in vim? There's quite a lot more happening than open, write, and close. I found this out while working on some code to monitor changed files using the node.js fs.watch API, which abstracts (or obscures) Mac OS X's kqueue API.

To find out exactly what vim is doing when saving a file, we'll use a tool included with DTrace that reports on another process's system calls. We need the process ID of vim, which is already open and editing my file:

How to set up stress-free SSL on an OS X development machine

One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.

Most workflows make the following compromises:

Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying

a simple git branching model (written in 2013)

This is a very simple git workflow. It (and variants) is in use by many people. I settled on it after using it very effectively at Athena. GitHub does something similar; Zach Holman mentioned it in this talk.

Update: Woah, thanks for all the attention. Didn't expect this simple rant to get popular.

303 See Other

Location: https://github.com/wsargent/docker-cheat-sheet

Hi there!

The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.

Please click on the link above to go to the cheat sheet.

	ּ_בּ
	בּ_בּ
	טּ_טּ
	כּ‗כּ
	לּ_לּ
	מּ_מּ
	סּ_סּ
	תּ_תּ
	٩(×̯×)۶
	٩(̾●̮̮̃̾•̃̾)۶

	#!/usr/bin/env ruby -w

	# pnginator.rb: pack a .js file into a PNG image with an HTML payload;
	# when saved with an .html extension and opened in a browser, the HTML extracts and executes
	# the javascript.

	# Usage: ruby pnginator.rb input.js output.png.html

	# By Gasman <http://matt.west.co.tt/>
	# from an original idea by Daeken: http://daeken.com/superpacking-js-demos

	0e3647e8592d35514a081243582536ed3de6734059001e3f535ce6271032
	334b041de124f73c18011a50e608097ac308ecee501337ec3e100854201d
	40e127f51c10031d0133590b1e490f3514e05a54143d08222c2a4071e351
	45440b171d5c1b21342e021c3a0eee7373215c4024f0eb733cf006e2040c
	22015e420b07ef21164d5935e82338452f42282c1836e42536284c450de3
	043b452e0268e7eb005a080b360f0642e6e342005217ef04a42f3e43113d
	581e0829214202063d70030845e5301f5a5212ed0818e22f120b211b171b
	ea0b342957394717132307133f143a1357e9ed1f5023034147465c052616
	0c300b355c2051373a051851ee154a023723414c023a08171e1b4f17595e
	550c3e13e80246320b0bec09362542243be42d1d5d060e203e1a0c66ef48

	#!/usr/bin/env bash

	# load history -- necessary because Bamboo runs a "git clean" on the build directory
	cp -r /opt/plato-report .

	plato -r -d plato-report \
	-l .jshintrc \
	-t "My Project" \
	-x '(jquery\|min.js\|libs/(backbone\|underscore\|require))' \
	path/to/my_project