Couldn't find the text of this for a while...
#!/bin/sh | |
# | |
# The MIT License (MIT) | |
# | |
# Copyright (c) 2013 Chris Yuen | |
# | |
# 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 |
#include <stdio.h> | |
#include <stdlib.h> | |
#include <string.h> | |
#include <errno.h> | |
/* pop culture test case: | |
./unhtml "Gangnam+Style+(%EA%B0%95%EB%82%A8%EC%8A%A4%ED%83%80%EC%9D%BC).mp4" | |
*/ | |
/* fix Windows macros */ |
Hi Kyle, | |
My name is Tammy and I am on the team at Riviera Partners. Your name surfaced | |
in several of my searches today and across various filters - from distributed | |
systems to Clojure and encompassing Ruby and JavaScript. Well-rounded | |
individual, are we? I also heard from a former colleague of mine that your | |
programming began at the tender age of 2.... impressive! I just signed up for | |
CodeAcademy - should be interesting! | |
I am not sure how things are going for you at Boundary (are you still there)? |
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
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 |
Adrian -
I appreciate that you spent time in writing this post. I know I've been up until 2am writing similarly long ones as well. I will take responsibility for having what is likely an irrational response (I blame Twitter for that) to the term "NoOps", but I invite you to investigate why that might be. I'm certainly not the only one who feels this way, apparently, and thus far have decided this issue is easily the largest distraction in my field I've encountered in recent years. I have had the option to simply ignore my opposition to the term, and just let the chips fall where they may with how popular the term "NoOps" may or may not get. I have obviously not taken that option in the past, but I plan to in the future.
You're not an analyst saying "NoOps". Analysts are easy (for me) to ignore, because they're not practitioners. We have expectations of engineering maturity from practitioners in this field of web engineering, especially those we consider leaders. I don't have any expectations from analysts,
#!/usr/bin/env bash | |
# bash 3.2.25(1) Ubuntu 7.10 Date : 2012-02-15 | |
# | |
# _______________| freqy : sort and order lines by frequency of appearance. | |
# | |
# Usage: freqy [optional: file(s)] | |
# | |
# Notes: Will work in a pipe. | |
# Does not alter the file(s) themselves. | |
# |
public static final String SPACE = "[\\s\u3000]"; | |
public static final String NUMBER = "[0-9\uff10-\uff19]"; // 0-90-9 | |
public static final String HYPHEN = "[-\uff0d\u2212]"; | |
public static final String NOT_NUMBER_OR_HYPHEN = "[^" + NUMBER.substring(1, NUMBER.length()-1) + HYPHEN.substring(1); | |
public static final String NUMBERS = "([0-9\uff10-\uff19\u4e00\u4e8c\u4e09\u56db\u4e94\u516d\u4e03\u516b\u4e5d]+)"; // 0-90-9一二三四五六七八九 | |
public static final String CHOUME = "\u4e01\u76ee"; // 丁目 | |
public static final String BANCHI = "\u756a\u5730?"; // 番地 | |
public static final String GOU = "\u53f7"; // 号 |
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