briancavalier

function keepTrying(otherArgs, promise) {
	promise = promise||new Promise();
	
	// try doing the important thing
	
	if(success) {
		promise.resolve(result);
	} else {
		setTimeout(function() {
			keepTrying(otherArgs, promise);

chitchcock

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

gre

/*
 * This work is free. You can redistribute it and/or modify it under the
 * terms of the Do What The Fuck You Want To Public License, Version 2,
 * as published by Sam Hocevar. See the COPYING file for more details.
 */
/*
 * Easing Functions - inspired from http://gizma.com/easing/
 * only considering the t value for the range [0, 1] => [0, 1]
 */
EasingFunctions = {

endolith

MIT License

Copyright (c) 2012 endolith

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

ChickenProp

Introduction

This is a dead-simple way to test that GPIO on the Raspberry Pi is working. I have an SKPang Raspberry Pi starter kit A. But all you need is

• A Raspberry Pi.
• An LED.
• A button.
• A resistor, approximately 270Ω.
• Some way to connect these to each other and the GPIO pins.

benbuckman

/*
Elevator algorithm
by Ben Buckman, for a job interview process 7/18/12
*/

// == INSTRUCTIONS ==
// Iterate through the elevators list and return the elevator that is:
//    closest, AND
//    moving in the right direction (or idle), 
//        - [ben] this could mean 2 things:

dtchepak

        // SAMPLE ONLY -- DON'T USE FOR REAL STUFF UNLESS YOU'VE REVIEWED AND TESTED :)
        // Needs work to make robust: check property type's class has default ctor and so on.
        // Can also filter out interfaces as these will be auto-subbed.
        public static T SubFor<T>() where T : class
        {
            var gettableVirtualProps = typeof(T).GetProperties()
                .Where(x => x.CanRead && x.GetGetMethod().IsVirtual)
                .Select(x => x);

            var sub = Substitute.For<T>();

julionc

How to install PhantomJS on Ubuntu

Version: 1.9.8

Platform: x86_64

First, install or update to the latest system software.

sudo apt-get update
sudo apt-get install build-essential chrpath libssl-dev libxft-dev

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

n0ts

# http://stackoverflow.com/questions/5735666/execute-bash-script-from-url
bash <(curl -s http://mywebsite.com/myscript.txt)

# http://stackoverflow.com/questions/4642915/passing-parameters-to-bash-when-executing-a-script-fetched-by-curl
curl http://foo.com/script.sh | bash -s arg1 arg2