This gist is part of a blog post. Check it out at:
http://jasonrudolph.com/blog/2011/08/09/programming-achievements-how-to-level-up-as-a-developer
Drop in replace functions for setTimeout() & setInterval() that | |
make use of requestAnimationFrame() for performance where available | |
http://www.joelambert.co.uk | |
Copyright 2011, Joe Lambert. | |
Free to use under the MIT license. | |
http://www.opensource.org/licenses/mit-license.php |
This gist is part of a blog post. Check it out at:
http://jasonrudolph.com/blog/2011/08/09/programming-achievements-how-to-level-up-as-a-developer
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
#include <stdio.h> | |
#include <string.h> | |
#include <stdlib.h> | |
// initialize the tape with 30,000 zeroes | |
unsigned char tape[30000] = {0}; | |
// set the pointer to point at the left-most cell of the tape | |
unsigned char* ptr = tape; |
/* | |
* C11 <threads.h> emulation library | |
* | |
* (C) Copyright yohhoy 2012. | |
* Distributed under the Boost Software License, Version 1.0. | |
* (See copy at http://www.boost.org/LICENSE_1_0.txt) | |
*/ | |
#ifndef EMULATED_THREADS_H_INCLUDED_ | |
#define EMULATED_THREADS_H_INCLUDED_ |
This benchmark has been misleading for a while. It was originally made to demonstrate how JIT compilers can do all sorts of crazy stuff to your code - especially LuaJIT - and was meant to be a starting point of discussion about what exactly LuaJIT does and how.
As a result, its not indicative of what its performance may be on more realistic data. Differences can be expected because
#!/usr/bin/env ruby | |
#------------------------------------------------------------------------------ | |
# Aggregate Print useful information from /proc/[pid]/smaps | |
# | |
# pss - Roughly the amount of memory that is "really" being used by the pid | |
# swap - Amount of swap this process is currently using | |
# | |
# Reference: | |
# http://www.mjmwired.net/kernel/Documentation/filesystems/proc.txt#361 |
This is a proof-of-concept of a couple of concurrent data structures written in Ruby.
The implementations are heavily commented for those interested. There are benchmarks (with results) included below. The results are interesting, but, as always, take with a grain of salt.
AtomicLinkedQueue
is a lock-free queue, built on atomic CAS operations.
#!/bin/bash | |
# Sometimes you need to move your existing git repository | |
# to a new remote repository (/new remote origin). | |
# Here are a simple and quick steps that does exactly this. | |
# | |
# Let's assume we call "old repo" the repository you wish | |
# to move, and "new repo" the one you wish to move to. | |
# | |
### Step 1. Make sure you have a local copy of all "old repo" | |
### branches and tags. |
This is a plain-text version of Bret Victor’s reading list. It was requested by hf on Hacker News.
Highly recommended things!
This is my five-star list. These are my favorite things in all the world.
A few of these works have had an extraordinary effect on my life or way of thinking. They get a sixth star. ★