Rich Hickey • 3 years ago
Sorry, I have to disagree with the entire premise here.
A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness. By constantly switching from one thing to another you are always reaching above your comfort zone, yes, but doing so by resetting your skill and knowledge level to zero.
Mastery comes from a combination of at least several of the following:
Inspired by "Parsing CSS with Parsec".
Just quick notes and code that you can play with in REPL.
By @kachayev
#The Problem We just described standard design issues you have when you start creating layers of services, DAOs and other components to implement an application. That blog/gist is here.
The goal is to think through some designs in order to develop something useful for an application.
#Working through Layers If you compose services and DAOs the normal way, you typically get imperative style objects. For example, imagine the following:
object DomainObjects {
After finding a lot of other posts on the topic that didn't work out for me this one did the trick so I'm reposting for my own sense of self preservation.
Copy the Virtualbox autostart plist template file to your system's LaunchDaemons folder.
sudo cp \
/Applications/VirtualBox.app/Contents/MacOS/org.virtualbox.vboxautostart.plist \
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
| ######################################### | |
| ## Set prompt, iTerm2 window and tabs ## | |
| ######################################### | |
| # Color constants used in the prompt | |
| BLACK="%{[0m%}" | |
| BOLD_BLACK="%{[1;30m%}" | |
| RED="%{[0;31m%}" | |
| BOLD_RED="%{[1;31m%}" | |
| GREEN="%{[0;32m%}" |
| 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 |
| (* | |
| Probe Menu Bar | |
| This script uses UI element scripting to return a list of every menuitem | |
| of every menu for every application currently running. | |
| If "Enable access for assistive devices" is not checked, | |
| this script will open the Universal Access System Preference and ask | |
| the user to check the checkbox. |
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
