***revisit
Notes
http://www.meetup.com/ctoschool/events/220150188/
===
Eric Tang @ericxtang @ Wildcard
ELK+influxdb
15 eng to 1 infra eng (100 aws ec2)
metrics:
cluster perf (cpu, ram, etc)
custom events (ex rate, throughput)
all data=time series
influxDB
graphana on top of influxDB
'easier and prettier than graphite'
influxdb takes UDP
event tracking: aggregation on non-timestamp fields,
eg click counts by country
ELK: elasticsearch, logstatch, kibana stack
log files/metrics/scripts go to redis, redis to logstash,
logstash to elasticsearch. kibana to read.
logstash: input/filter/output. custom config lang not json.
kibana4: just came out
ELK: redis buffer helpful to not overwhelm LS
events client has to be async (remember the logentries issue)
ES index should fit in memory
packetbeat.com
process: define metric, implement, measure
===
asciidoc (*.adoc)
markdown with images/include files
mostly for publishing
asciidoctor.js chrome ext
"why I love java:"
"* more than 9 mil developers use it - large workers pool"
yuk
===
Michael Hamrah
***consul
https://github.com/mhamrah/consul-demo
https://www.consul.io/
env variables is the way to go
service config via template ('ha' files)
kill simple-web.py - sonsul sees service check is failing
has ACL for passwords/etc
docker friendly (tool: https://github.com/gliderlabs/registrator )
still a packer.io fan
===
Wes Chow @ chartbeat
pre-mortems and task forces
culture: move fast, dark secrets, product focused
how do you move it?
John Shook
to change culture: change thinking to change behavior
http://www.lean.org/WhoWeAre/LeanPerson.cfm?LeanPersonId=4
http://www.lean.org/shook/DisplayObject.cfm?o=1166
***Pre-mortem: design doc
* >what are the assumptions (eg: usage rate)
* product launches then fails, what is the most likely cause
* are failures isolated
* expected db write rate
See https://hbr.org/2007/09/performing-a-project-premortem
The Pre-Mortem: A Simple Technique To Save Any Project From Failure
***task forces:
IETF motto: "rough consensus and running code"
https://en.wikipedia.org/wiki/Rough_consensus
engineer leads a task force, then have a meeting (these are numbered,
eg pep8) does not involve management
weird consequences:
project naming proposal: "short and descriptive"
reply: not a good idea because projects move - better to pick random name
revisit assumptions? haven't been doing it long enough.
first task force: where do we caputure task forces?
next one: unit tests
onboarding process
===
pair code review - Dan Levenson
dleve123
healthify.us
***invite to healthcare on aws
social needs of low income populations
clients: healthcare payers that are on the hook
***pair code review
problem: 114 comments on PR
process:
1) story/etc/code
2) code review (has a cycle of: comment, amend, repeat) -
problem: multiple handoff cycles
3) merge pr/deploy
problems:
* not agile: no face to face conv
* "i'll review it later"
* dead time due to lack of CR scheduling
* large PRs are daunting, even longer time
scrum->kanban - minimize cycle time
code review takes way too long
process:
* developer and reviewer agree to 1 hr time period adap
* reviewer leads review and asks dev questions
* reviewers comments on pr to doc actions during the meeting
* developer revises (usually only once)
pros:
* scheduding -> less dead time
* long comments replaced by quick convs
* breeds pairing culture (but not dogmatic)
cons:
* bias of developer can affect reviewers
===
Architecture design meetings
Nichola Grasset
makespace.com
any idea on process or tech: make a same day meeting to discuss
eg:
* should we migrate to new db?
* need diff js framework?
* can you plug analytics into your mobile app?
process:
* expose problem
* suggest solution, usually on whiteboard
* team tries to identify blockers
** blockers are the most important determinant in deciding progress
why: move fast and slow
===
Steven Saporta, CTO, SwipeToSpin
CTO weekly tech report
audience: ceo/coo/others
1 doc/sheet per week
health of tech team/health of product
opened/closed issues metrics (filters in jira)
metrics by customer help drive account manager intervention
===
Jean interlude:
***Jira: dot is magic keyboard shortcut (commands list)
status change search: `updated >= -1d and status changed to closed`
===
perf management
Colin Steele, CTO @ Room Key
"the major problems are not technological, but sociological"
-- tom demarco
put the biggest hecklers on the steering committee of the perf management
task force
What went well/poorly/action items (ala retrospective)
Alex Lo Engineering Blog 
Reply