bazzargh

#!/usr/bin/env ruby

# hackertyper-style playback of series of tty recordings created by
# ttyrec.
#
# usage:
# hacker slides/*
#
# - Type randomly to move forward inside file
# - backspace to skip back or prev file

ianschenck

import interface


class IFoo(interface.Interface):

    def foo(self):
        """foo this object."""


class IBar(interface.Interface):

gvaughn

I'd like to share some git aliases that you might find useful if you handle pull requests from others.

Add these to your ~/.gitconfig in the [alias] section:

copr = "!f() { git fetch -fu origin refs/pull/$1/head:pr-$1; git checkout pr-$1; } ; f"
prunepr = "!git for-each-ref refs/heads/pr-* --format='%(refname:short)' | while read ref ; do git branch -D $ref ; done"

Now you can "git copr #{pr_number}" (check out pull request is the mnemonic) and it will pull down the PR in a local branch of pr-#{pr_number} and check it out for you. To do it right, you must pronounce it "Copper" with a James Cagney gangster accent.

mwender

#import <Foundation/Foundation.h>
#import <Cocoa/Cocoa.h>
#import <unistd.h>
BOOL copy_to_clipboard(NSString *path)
{
  // http://stackoverflow.com/questions/2681630/how-to-read-png-image-to-nsimage
  NSImage * image;
  if([path isEqualToString:@"-"])
  {
    // http://caiustheory.com/read-standard-input-using-objective-c 

oakes

Contents

• Why care about Rust?
• The Toolchain
• Creating a New Project
• Modules
• Crates
• Types
• References
• Mutability

aphyr

(require '[clojure.test :as test])

; Rewrite clojure.test to generate data structures instead of writing to
; stdout
(def ^:dynamic *results*
  "Bound dynamically to an atom wrapping a vector of test report maps")

(defn add-name
  "Given a testing report map, assoc's on a :name derived from the current
  `clojure.test/testing` context."

acolyer

Internet Scale Services Checklist

A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."

• http://mvdirona.com/jrh/talksandpapers/jamesrh_lisa.pdf

Basic tenets

• Does the design expect failures to happen regularly and handle them gracefully?
• Have we kept things as simple as possible?

tmm1

FranklinChen

-- Response to https://twitter.com/mfeathers/status/495979138365149184
-- Based on http://git.zx2c4.com/spark/tree/spark.c

import System.IO (hPutStrLn, stderr)
import System.Environment (getArgs)
import qualified Data.ByteString as B
import qualified Data.ByteString.Char8 as C

main :: IO ()
main = do

gvaughn

Vim and Git in Code Demos

I want to give a code demo that shows progression of the code. I thought it would be great if I could craft the series of commits on a branch and have a single vim keystroke that would checkout the next (or previous) commit and force my buffers to reload. That would allow me to show one commit, then give me the freedom to live code how the next step is done, but when I advance to the next commit I know I'll have working code. It's like a safety harness for live coding.

Here's how it's supposed to work:

• I created a test_forward branch, and, yeah, it's hardcoded in the vimscript :-(
• Then I created 3 consecutive commits with one line changes in my README
• optional: I used "git tag $tag_name" to give a friendly name in my bash prompt for each commit (I wish the fugitive statusline would use it too though)
• I checked out the 1st of the demo commits