Skip to content

Instantly share code, notes, and snippets.

View dvliman's full-sized avatar

David Liman dvliman

View GitHub Profile
#!/bin/bash
PIDFILE=/var/run/os-<%= @name %>.pid
# Start the service
start() {
if [ -f $PIDFILE ]; then
echo "<%= @name %> already running, process `cat $PIDFILE`."
exit 1
fi
urlencode() {
# urlencode <string>
local length="${#1}"
for (( i = 0 ; i < length ; i++ )); do
local c="${1:i:1}"
case "$c" in
[a-zA-Z0-9.~_-]) printf "$c" ;;
' ') printf + ;;
*) printf '%%%X' "'$c"

Business Models

Advertising

Models Examples
Display ads Yahoo!
Search ads Google
#!/bin/bash
usage() {
cat << EOF
Usage: $0 [OPTION]... COMMAND
Execute the given command in a way that works safely with cron. This should
typically be used inside of a cron job definition like so:
* * * * * $(which "$0") [OPTION]... COMMAND
Arguments:
@dvliman
dvliman / crdt system
Last active August 29, 2015 14:01 — forked from pozorvlak/sitrep.md
Here's where I understand the state of the art to be:
- In [this INRIA tech report](http://hal.inria.fr/docs/00/55/55/88/PDF/techreport.pdf), Shapiro, Preguiça, Baquero and Zawirski (SPBZ) prove, amongst other things, that a sufficient condition for CRDTs to achieve eventual consistency on networks which may reorder and duplicate packets (which I'll call **flaky** networks, henceforth) is that
1. the underlying datatype forms a semilattice,
2. messages are full states,
3. incoming messages are combined with the node's current state using the least-upper-bound operation in the semilattice.
- It's possible to relax condition 2 and still achieve eventual consistency over flaky networks by fragmenting the state into independent parts and transmitting updates to each part separately. For instance, in the G-Set CRDT (an add-only bitset) one can transmit only the index of the element to be added.
- In [these slides from a talk at Dagstuhl](http://www.dagstuhl.de/mat/Files/13/13081/13081.BaqueroCarlos.Sl
RATE_LIMIT_SCRIPT = r'''
local now = tonumber(ARGV[1])
local required = tonumber(ARGV[2])
local rate = tonumber(ARGV[3])
local per_secs = tonumber(ARGV[4])
local do_subtract = tonumber(ARGV[5]) == 1
local full_at = tonumber(redis.call('GET', KEYS[1])) or 0
local score, result
if full_at < now then
score = rate
#!/bin/sh
# modified by jfro from http://www.cnysupport.com/index.php/linode-dynamic-dns-ddns-update-script
# Update: changed because the old IP-service wasn't working anymore
# Uses curl to be compatible with machines that don't have wget by default
# modified by Ross Hosman for use with cloudflare.
#
# Place at:
# /usr/local/bin/cf-ddns.sh
# run `crontab -e` and add next line:
# 0 */5 * * * * /usr/local/bin/cf-ddns.sh >/dev/null 2>&1

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

So you're curious in learning this new thing called (Functional) Reactive Programming (FRP).

Learning it is hard, even harder by the lack of good material. When I started, I tried looking for tutorials. I found only a handful of practical guides, but they just scratched the surface and never tackled the challenge of building the whole architecture around it. Library documentations often don't help when you're trying to understand some function. I mean, honestly, look at this:

Rx.Observable.prototype.flatMapLatest(selector, [thisArg])

Projects each element of an observable sequence into a new sequence of observable sequences by incorporating the element's index and then transforms an observable sequence of observable sequences into an observable sequence producing values only from the most recent observable sequence.

Simple Ruby Server:
# ruby -run -e httpd -- -p 5000 .
Simple Python Server:
# python -m SimpleHTTPServer

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns                     on recent CPU
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 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs 4X memory