muhqu

#!/bin/bash
if [ -z "$1" ]; then
  echo "Usage: sudo $0 /dev/sdh1"
  exit 1;
fi

dd if=$1 of=/dev/null & pid=$!
while true; do
  ps -p$pid --no-heading || break;
  echo "-- $(date) ------------------";

aras-p

// Just before switching jobs:
// Add one of these.
// Preferably into the same commit where you do a large merge.
//
// This started as a tweet with a joke of "C++ pro-tip: #define private public",
// and then it quickly escalated into more and more evil suggestions.
// I've tried to capture interesting suggestions here.
//
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_,
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant,

swanson

Things I track or would like to be able to track in GA (and other tools when GA falls down)

• Page views
• Accurate time on page google for "bounce rate time on page issues")
• Referral traffic URL (it's great that I got 50 views from reddit, but which post so I can go read comments - currently have to use Reddit Domain search)
• Amazon Affiliates reports (I have affiliate links on book review posts)
• Twitter stats (tweets, retweets, etc - currently have to use Twitter Search)
• RSS Subscribers
• Conversion from reader to RSS/Email/other CTA
• Page load time (one number ala github dashboard, link)

jnunemaker

catspam() {
  curl -vvvv -d "{\"Body\":\"${1}\"}" -H "Content-Type: application/json" http://catspammer.com/api/cat
}

desertmonad

; /usr/local/bin/nasm -f macho 32.asm && ld -macosx_version_min 10.7.0 -o 32 32.o && ./32 

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; The .data section is for storing and naming constants.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
section .data

msg:    db    "Hello world!", 10
.len:   equ   $ - msg

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?