Tim Hwang
- PM identifies 🔎 user requirements
- UX designs 🎨 them
Last week the transcript of a talk Stanley Druckenmiller gave went a little viral on #financetwitter. | |
(http://covestreetcapital.com/Blog/wp-content/uploads/2015/03/Druckenmiller-_Speech.pdf) | |
Only problem- it's been traveling around in the form of an image PDF, | |
making it hard to cut + paste or search for your favorite quotes. | |
So I ran it through a couple programs, and bleepblorp, a text transcript is below. | |
If you want *just the text,* and not this surrounding web page, click "Raw" in the corner above. |
SELECT | |
t.TABLE_SCHEMA, | |
t.TABLE_NAME, | |
c.COLUMN_NAME, | |
IFNULL( | |
kcu.CONSTRAINT_NAME, 'Not indexed' | |
) AS `Index` | |
FROM | |
information_schema.TABLES t | |
INNER JOIN information_schema.`COLUMNS` c ON c.TABLE_SCHEMA = t.TABLE_SCHEMA |
This is an example of a function whose logic lives in the type definition rather than in the function body.
/**
* @name `curryRecord`
*
* Takes a unary function that takes a record as an argument, and makes the
* record partially applicable. Returns a new function that takes a partial of
This post explores several common ways of handling visibility of conditional fields. Our sample form will have the following schema:
foo
: always presentbar
: dependent on form state (value of foo)baz
: dependent on other application state (e.g. user permissions)Below is our form, prior to implementing visibility logic:
#!/bin/sh | |
sleep .1; printf "[1J[r[48;2;146;134;162m⣽[0m[48;2;134;124;150m⣩[0m[48;2;137;123;148m⣺[0m[48;2;138;123;150m⣻[0m[48;2;137;123;148m⣾[0m[48;2;134;123;148m⣺[0m[48;2;134;124;150m⣻[0m[48;2;138;127;153m⣿[0m[48;2;143;131;161m⣿[0m[48;2;141;128;158m⡿[0m[48;2;141;126;155m⠟[0m[48;2;139;125;151m⠙[0m[48;2;123;110;131m⠀[0m[48;2;124;110;131m⢀[0m[48;2;122;109;128m⣀[0m[48;2;123;108;127m⡀[0m[48;2;121;107;123m⠀[0m[48;2;120;106;122m⢀[0m[48;2;121;107;125m⣠[0m[48;2;123;110;130m⣨[0m[48;2;123;110;131m⣨[0m[48;2;126;112;134m⣨[0m[48;2;134;120;146m⣼[0m[48;2;136;125;150m⣿[0m[48;2;142;131;156m⣿[0m[48;2;150;132;159m⣿[0m[48;2;141;128;154m⣿[0m[48;2;148;134;163m⣿[0m[48;2;150;138;170m⣿[0m[48;2;153;137;170m⣿[0m[48;2;147;131;159m⣿[0m[48;2;130;115;137m⣸[0m[48;2;124;110;131m⠀[0m[48;2;124;111;132m⠀[0m | |
[48;2;139;128;156m⣿[0m[48;2;140;128;159m⣿[0m[48;2;140;128;157m⣿[0m[48;2;150;137;170m⣿[0m[48;2;146;132;162m⣿[0m[48;2;145;131;161m⣿[0m[48;2;145;130;161m⣿[0m[4 |
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
const I = x => x; | |
const K = x => y => x; | |
const A = f => x => f(x); | |
const T = x => f => f(x); | |
const W = f => x => f(x)(x); | |
const C = f => y => x => f(x)(y); | |
const B = f => g => x => f(g(x)); | |
const S = f => g => x => f(x)(g(x)); | |
const P = f => g => x => y => f(g(x))(g(y)); | |
const Y = f => (g => g(g))(g => f(x => g(g)(x))); |
import React from "react"; | |
import { isEqual } from "underscore"; | |
/** | |
* HOC for diagnosing unnecessary renders and identifying faulty selectors | |
* | |
* Adds a logger function to a component that lists all changed props | |
* Also checks if changed props are deeply equal | |
* | |
* Usage: Decorate the component you are investigating with renderDoctor: |