radar

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"

jedisct1

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;

chitchcock

Stevey's Google Platforms Rant

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

piscisaureus

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 = git@github.com: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:

adamwiggins

Make it real

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.

Ship 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.

Do it with style

chris-martin

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);
        }

r00k

Frequently Asked Questions

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:

• What should I do if I inherit an app with no tests?

coreyhaines

Chrome
Alfred
Dropbox
1Password
Sizeup
Twitter
Coconut Battery
Dash
XCode
Caffeine

mestizo

#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

coliver

== 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.