Nate Abele nateabele

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

This is a post by Joel Spolsky. The original post is linked at the bottom.

This is such a common question here and elsewhere that I will attempt to write the world's most canonical answer to this question. Hopefully in the future when someone on answers.onstartups asks how to split up the ownership of their new company, you can simply point to this answer.

The most important principle: Fairness, and the perception of fairness, is much more valuable than owning a large stake. Almost everything that can go wrong in a startup will go wrong, and one of the biggest things that can go wrong is huge, angry, shouting matches between the founders as to who worked harder, who owns more, whose idea was it anyway, etc. That is why I would always rather split a new company 50-50 with a friend than insist on owning 60% because "it was my idea," or because "I was more experienced" or anything else. Why? Because if I split the company 60-40, the company is going to fail when we argue ourselves to death. And if you ju

Most active GitHub users (git.io/top)

The list would not be updated for now. Don't write comments.

The count of contributions (summary of Pull Requests, opened issues and commits) to public repos at GitHub.com from Wed, 21 Sep 2022 till Thu, 21 Sep 2023.

Because of GitHub search limitations, only 1000 first users according to amount of followers are included. If you are not in the list you don't have enough followers. See raw data and source code. Algorithm in pseudocode:

githubUsers

The Liang-Barsky algorithm is a cheap way to find the intersection points between a line segment and an axis-aligned rectangle. It's a simple algorithm, but the resources I was pointed to didn't have particularly good explanations, so I tried to write a better one.

Consider a rectangle defined by x_min ≤ x ≤ x_max and y_min ≤ y ≤ y_max, and a line segment from (x_0, y_0) to (x_0 + Δ_x, y_0 + Δ_y). We'll be assuming at least one of Δ_x and Δ_y is nonzero.

(I'm working with Flash, so I'll be using the convention that y increases as you go down.)

We want to distinguish between the following cases:

	<?php

	namespace lambent\core;

	use ReflectionClass;

	class Object
	{
	protected static $_defaults = array(
	'_config' => true,

	Copyright 2012 Shin Suzuki<[email protected]>

	Licensed under the Apache License, Version 2.0 (the "License");
	you may not use this file except in compliance with the License.
	You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,

	function lens(get, set) {
	var f = function (a) { return get(a); };
	f.set = set;
	f.mod = function (f, a) { return set(a, f(get(a))); };
	return f;
	}

	var first = lens(
	function (a) { return a[0]; },
	function (a, b) { return [b].concat(a.slice(1)); }

	#!/usr/bin/python
	## gitsh (pronounced like "glitch"), an interactive wrapper for git.
	##
	## gitsh parses the output of "git status" and numbers the files for
	## you, for easy operations on multiple files.
	##
	## $ gitsh status
	## 1) M foo/bar.py
	## 2) M foo/baz.py
	## 3) A blah.sh

	Latency Comparison Numbers (~2012)
	----------------------------------
	L1 cache reference 0.5 ns
	Branch mispredict 5 ns
	L2 cache reference 7 ns 14x L1 cache
	Mutex lock/unlock 25 ns
	Main memory reference 100 ns 20x L2 cache, 200x L1 cache
	Compress 1K bytes with Zippy 3,000 ns 3 us
	Send 1K bytes over 1 Gbps network 10,000 ns 10 us
	Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD

	#!/bin/bash
	# A simple script to backup an organization's GitHub repositories.

	#-------------------------------------------------------------------------------
	# NOTES:
	#-------------------------------------------------------------------------------
	# * User @jimklimov (and probably some others called out in the long comment
	# thread below) have modified this script to make it more robust and keep
	# up with various changes in the GitHub API and response format at:
	# https://github.com/jimklimov/github-scripts