theothermattm

Some of the greatest info I've seen on creating a healthy engineering courtesy of Spotify:

Spotify Engineering Culture Part 1

TODO make notes on this one

Spotify Engineering Culture Part 2

• 0:50 - "We aim to make mistakes faster than anyone else" - Fail Fast and Improve Fast.
• 1:30 - "Fail Friendly Environment" - Encourage sharing of failures so everyone can learn from them. Some teams have "Fail walls" showing off their failures.

theothermattm

# original source based on: https://github.com/fabiohbarbosa/docker-healthcheck-oracle/blob/master/assets/healthcheck.sh

CHECK=$(${ORACLE_HOME}/bin/sqlplus -s ${HEALTHCHECK_USER}/${HEALTHCHECK_PASSWORD}@localhost/${HEALTHCHECK_SERVICE_NAME} as sysdba <<END
  --set pagesize 0 feedback off verify off heading off echo off;
  -- the simplest type of health check
  --select count(*) from dual;
  -- this will check if a 
  SELECT count(*) FROM V\$INSTANCE where INSTANCE_NAME = 'xe' and DATABASE_STATUS = 'ACTIVE';
  exit;
END

theothermattm

-- https://stackoverflow.com/questions/1690404/how-to-drop-all-user-tables

BEGIN
   FOR cur_rec IN (SELECT object_name, object_type
                     FROM user_objects
                    WHERE object_type IN
                             ('TABLE',
                              'VIEW',
                              'PACKAGE',
                              'PROCEDURE',

theothermattm

Tom Chi - Learning Through Prototyping

()[https://www.youtube.com/watch?v=kuqgrvUPc5g]

• Better to reason with experience/data than guesses
  • Find the quickest path to experience
  • Doing is the best kind of thinking.
• Smart people will always have good defenses of their guesses
• "Am I hearing a guess, or am I hearing direct experience?"
• We want experience

theothermattm

rsync -azP --delete --filter=":- .gitignore" . targethost:/targetdirectory

theothermattm

# from https://github.com/nodejs/node/issues/3742#issuecomment-225939382

openssl x509 -inform der -in /Path/to/the.crt -out /Path/to/the/file.pem

theothermattm

Follow ups:

• stand up webpage test internally: https://sites.google.com/a/webpagetest.org/docs/private-instances
  • docker image?
  • convert AMI to an VMware image?
  • need windows machines for agents
• sign up for thewebahead.net podcast - @jensimmons
• responsive design podcast - ethan marcotte and karen mcgrane
• mailtoself.com
• hipmunk.com - for travel

theothermattm

# sync everything excluding things in .gitignore
# delete anything on target not in source
# include dotfiles and symlinks, also use compression
rsync -azP --delete --filter=":- .gitignore" . my-target-host:/my/target/directory

theothermattm

# attaches to the first running docker container containing the name passed
# in as the first argument to the command
# example: attachto projects
function attachto () {
        echo "Attaching to first running docker container with name: $1 You might need to press ctrl+c to start entering commands..."
        docker attach $( docker ps | grep $1 | head -n 1 |  cut -d' ' -f1)
}

theothermattm

A list of things I find myself always referring to, or I SHOULD always refer to 😄

The source of this is a Gist and is located here

Architecture/Design

• High Level Overview of Architecture Patterns
• The 8 Fallacies of Distributed Systems
• The Unix Philosophy

Many pressures tend to make programs more complicated (and therefore more expensive and buggy). One such pressure is technical machismo. Programmers are bright people who are (often justly) proud of their ability to handle complexity and juggle abstractions. Often they compete with their peers to see who can build the most intricate and beautiful complexities. Just as often, their ability to design outstrips their ability to implement and debug, and the result is expensive