djmitche

Getting Started

• See the 30-second guide

My Usage

I've been using this for almost ten years now, so here are some of the ways I have set it up to be most productive. See my taskrc below for implementation details.

In general, I've had the most success by keeping lists of tasks short and to the point, avoiding the anxiety of seeing 100 tasks and feeling like I'm going to drown.

jwhitlock

#!/usr/bin/env python
'''
Parse a Kuma papertrail log, mostly to count IP addresses to find the scrapers.

To get some log entries, use command line papertrail, like:

papertrail --min-time '2017-11-12 4:00 AM' --max-time '2017-11-12 5:00 AM' -g portland -- mdn-prod_web '-"GET /readiness"' '-"GET /healthz"' '-"- - HTTP/1.0"' > trouble.log

A simplier version can be used to just count IP addresses, but I was being bolder,
so I could parse on other elements.

jwhitlock

#!/usr/bin/env python
from datetime import date, datetime, timedelta, tzinfo
import argparse
import requests
import requests_cache
import csv
import pprint

current = date.today()

smith

Habitat Notes

Things I'm learning while using Habitat, written down so I remember them.

Cache artifacts in a Mac studio

export HAB_DOCKER_OPTS="-v /Users/nathansmith/.hab/cache/artifacts /hab/studios/src/hab/cache/artifacts"

Find reverse dependencies for a package

glogiotatidis

#!/bin/bash
#
# Script to remove GPG key from git-crypt
#
# It will re-initialize git-crypt for the repository and re-add all keys except
# the one requested for removal.
#
# Note: You still need to change all your secrets to fully protect yourself.
# Removing a user will prevent them from reading future changes but they will
# still have a copy of the data up to the point of their removal.

Avaq

const I  = x => x
const K  = x => y => x
const A  = f => x => f (x)
const T  = x => f => f (x)
const W  = f => x => f (x) (x)
const C  = f => y => x => f (x) (y)
const B  = f => g => x => f (g (x))
const S  = f => g => x => f (x) (g (x))
const S_ = f => g => x => f (g (x)) (x)
const S2 = f => g => h => x => f (g (x)) (h (x))

zeeshanlakhani

Testing Stateful Code

So far, all the properties we have written have tested stateless code. Stateless code is made up of pure functions and is inherently easier to test than stateful code with side effects. The chief problem with testing stateful code is that the input to output mapping depends on the current state of the program. Previous operations can cause the same function to return different output given the same input. Therefore, in order to test stateful code, our tests must maintain some state of their own. This state is known as the model state and is updated as part of the testing process.

andelf

#!/usr/bin/env escript
% -*- mode: erlang -*-

main([BeamFile]) ->
    {ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(BeamFile,[abstract_code]),
    io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).

bookshelfdave

Add mechanism to indicate if objects were dropped and a fullsync is needed

Several new stats added:

rt_source_errors - non-persistent
rt_sink_errors   - non-persistent (sink errors detected on the *source* side)
rt_dirty         - persistent across restarted, cleared by a successful fullsync

bookshelfdave

#Testing the Riak YCSB Implementation ###To build:

# Dependencies: Maven, Java 1.6+
git clone https://github.com/metadave/YCSB.git
cd YCSB
mvn clean package
# see if the build worked using the "basic" driver (ie not Riak)
./bin/ycsb load basic -P workloads/workloada
./bin/ycsb run basic -P workloads/workloada