Skip to content

Instantly share code, notes, and snippets.

View jallspaw's full-sized avatar

John Allspaw jallspaw

View GitHub Profile
# Project 1b - Voting Booth
# Sadie Allspaw -- period 10
#### PEER FEEDBACK
# No major bugs, but it didn’t specify how it counted votes entered that weren’t the candidate
# There are no bugs that I ran into
# I didn’t notice any.
ballot = [] # start the list off as empty
#!/bin/sh
FILE=$1
sed 's/U02D34WJF/Philip Luedtke/' $FILE | sed 's/U03HCD2V5/Lew Cirne/'| sed 's/U03QC3DMZ/Goro Harumi/'| sed 's/U03QFP4HA/Aaron Bento/'| sed 's/U03U84Q9M/Roger Gilliam/'| sed 's/U04LBV8RG/Jojo Cruz/'| sed 's/U050GSKMU/Evan Nelson/'| sed 's/U050H5GL6/Ben Weintraub/'| sed 's/U0515BD3H/Tim Krajcar/'| sed 's/U052AESSE/Rich Vanderwal/'| sed 's/U052C72SD/Caleb Troughton/'| sed 's/U052GTQ89/Steven Minor/'| sed 's/U052HNEDH/Shane Delight/'| sed 's/U0555D564/Bryan White/'| sed 's/U0555DGCS/Leslie Strauss/'| sed 's/U055JBKQ6/Carol Jones/'| sed 's/U06BXF2EL/Andrew Bloomgarden/'| sed 's/U06C509K7/Tony Mancill/'| sed 's/U06CDJU7K/Ben Summer/'| sed 's/U06CHQDGB/Nikolas Davis/'| sed 's/U06CHT3HP/Dave Peterson/'| sed 's/U06RP89PH/Andy Cunningham/'| sed 's/U06RQELV7/Yonatan Schultz/'| sed 's/U06T09J5V/Jason Van Pelt/'| sed 's/U07HZTQE8/Vince Foley/'| sed 's/U07J4BD9R/Jared Stanbrough/'| sed 's/U081J565S/Sean Kane/'| sed 's/U0D1NRQQ4/Nathan Rodman/'| sed 's/U0DPJB8AX/Bryce Buchanan/'| sed 's/U0DPLRLHW/Gus Sh
#!/bin/sh
FILE=$1
jq -r '.[] | [ .type, .subtype, .ts, .thread_ts, .name, .text ] | @tsv' $FILE | awk -F\t '{print $3"\t"$5"\t"$6}' | dconv -S -i "%s.%N" -f "%Y-%m-%d %H:%M:%S" > $FILE-import

Keybase proof

I hereby claim:

  • I am jallspaw on github.
  • I am allspaw (https://keybase.io/allspaw) on keybase.
  • I have a public key ASAMgrgz_6hnZDBxtJ80auTrunHocGHZuEASjeSYq-__ago

To claim this, I am signing this object:

@jallspaw
jallspaw / gist:bc60f27c38a2d9009f34
Created April 1, 2015 13:02
Summing up contextual influence on systems architecture
1. Monolithic applications and architectures can vary in their monolithness. This is an under-specified description.
2. Microservice applications and architectures can vary in their microness. This is an under-specified description.
3. Microservices and monolithic architectures have both benefits and disadvantages.
4. Organizations will exploit those benefits while working around any weaknesses.
5. Success of the business is a large influence on the exploitation of benefits and implementation and costs of workarounds.
6. All benefits and work arounds are context-sensitive. Meaning that they are both technically and socially constructed by the organization that navigates them.
7. Path dependency is a thing. History matters and manifests in these architectural decisions and evolution in an organization.
8. Patterns exist to inform practice, not dictate it. Zealous adherence to an architectural pattern brings peril when it is to the exclusion of cultural context in actual practice.
9. Architectural patterns w
Myth: during a retrospective investigation, something is waiting to be “found”
I’ll cut to the chase: there is nothing waiting to be found, or “revealed.” These “causes” that we’re thinking we’re “finding”? We’re constructing them, not finding them. We’re constructing them because we are the ones that are choosing where (and when) to start asking questions, and where/when to stop asking the questions. We’ve “found” a root cause when we stop looking. And in many cases, we’ll get lazy and just chalk it up to “human error.”
As Erik Hollnagel has said (Hollnagel, 2009, p. 85):
“In accident investigation, as in most other human endeavours, we fall prey to the What-You-Look-For-Is-What-You-Find or WYLFIWYF principle. This is a simple recognition of the fact that assumptions about what we are going to see (What-You-Look-For), to a large extent will determine what we actually find (What-You-Find).”
More to the point: “What-You-Look-For-Is-What-You-Fix”
@jallspaw
jallspaw / gist:a2f3a5920ff12e60e7f4
Last active August 29, 2015 14:16
The rest of the 'Unwritten Laws of Engineering' section on making estimates
This is excerpted from: http://rotorlab.tamu.edu/me489_SP11/README/2010%20ASME%20Unwritten_Laws_of_Enginering.pdf
Promises, schedules, and estimates are necessary and important instruments in a well-ordered business.
Many engineers try to dodge making commitments. You must make promises based upon your best estimates
for your part of the job, together with estimates obtained from contributing departments for theirs. No one
should be allowed to avoid the issue by saying, “I can’t give a promise because it depends upon so many
uncertain factors.” Of course it does. You must account for them, estimating best and worse cases, and then
provide neither laughably padded nor unrealistically optimistic schedules. Both extremes are bad; good
Pinterest (Velocity Santa Clara)
Tumblr (Velocity Berlin)
Box (Velocity London)
Etsy (Percona)
Flickr (MySQL Conf)

"Jazz Improvisation and Organizing: Once More from the Top" http://web.cba.neu.edu/~mzack/articles/jazzorg/jazzorg.htm

"Resilience, Adaptation and Improvisation: increasing resilience by organising for successful improvisation" http://www.sintef.no/project/Building%20Safety/Publications/3rd%20RE%20symposium,%20resilience_adaptation_improvisation,%20TOG.pdf

"Space Operations Officers As Jazz Musicians" http://www.smdc-armyforces.army.mil/Pic_Archive/ASJ_PDFs/ASJ_VOL_9_NO_1_008.pdf

"Supporting Improvisation Work in Inter-Organizational Crisis Management"

# Give a little warning about what is required before we start.
msg="Before running this script, make sure:
1. You are not on ${THIS_HOST}.
This backup was generated on ${THIS_HOST}. It cannot be applied to
${THIS_HOST}.
2. You have removed the broken mysql server from the prod conf via
deployinator.
3. There is no data on this host. THIS SCRIPT WILL DESTORY THE CURRENT MYSQL
INSTALLATION. THERE WILL BE NO GOING BACK.