| == Rules == | |
| On Infrastructure | |
| ----------------- | |
| There is one system, not a collection of systems. | |
| The desired state of the system should be a known quantity. | |
| The "known quantity" must be machine parseable. | |
| The actual state of the system must self-correct to the desired state. | |
| The only authoritative source for the actual state of the system is the system. | |
| The entire system must be deployable using source media and text files. |
| #To Get List of Hardware | |
| sudo networksetup -listallhardwareports | |
| #To Disable IPv6 on Wifi Adapter | |
| sudo networksetup -setv6off wi-fi | |
| #To Disable IPv6 on Built-in Ethernet Adapter | |
| sudo networksetup -setv6off Ethernet |
| Chrome | |
| Alfred | |
| Dropbox | |
| 1Password | |
| Sizeup | |
| Coconut Battery | |
| Dash | |
| XCode | |
| Caffeine |
As a mentor for thoughtbot's Prime service, I've provided coaching to over 100 developers.
In my talk, I'll share the questions I'm asked repeatedly, and how I answer them.
This discussion will be targeted at beginner and intermediate developers striving to improve.
Likely discussion includes:
| enum EnumBullshit { | |
| A(5), B(6), C(-4); | |
| public final int i; | |
| private static final Map<Integer, EnumBullshit> map = new HashMap<>(); | |
| static { | |
| for (EnumBullshit bullshit : values()) { | |
| map.put(bullshit.i, bullshit); | |
| } |
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.
Locate the section for your github remote in the .git/config file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = [email protected]:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
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
| git clone https://github.com/kevinweil/elephant-bird.git | |
| ant nonothing | |
| cp lib/google-collect*jar lib/json-simple*jar /tmp/x | |
| cd build/classes | |
| jar -cf /tmp/x/elephant-bird.jar com | |
| REGISTER google-collect-1.0.jar; | |
| REGISTER json-simple-1.1.jar; | |
| REGISTER elephant-bird.jar; |
| def self.factory(plugin, &block) | |
| candidates = self.plugin_paths.map do |path| | |
| Dir["#{path}/#{plugin.to_s.downcase}.rb"][0] | |
| end | |
| candidate = candidates.detect(&:any?) | |
| if candidate | |
| require candidate | |
| Plugin.const_get(plugin.to_s.capitalize.to_sym).new(&block) | |
| else | |
| raise YourSystem::PluginNotFound, "The #{plugin} plugin could not be loaded" |