Matt Ray mattray

Adrian -

I appreciate that you spent time in writing this post. I know I've been up until 2am writing similarly long ones as well. I will take responsibility for having what is likely an irrational response (I blame Twitter for that) to the term "NoOps", but I invite you to investigate why that might be. I'm certainly not the only one who feels this way, apparently, and thus far have decided this issue is easily the largest distraction in my field I've encountered in recent years. I have had the option to simply ignore my opposition to the term, and just let the chips fall where they may with how popular the term "NoOps" may or may not get. I have obviously not taken that option in the past, but I plan to in the future.

You're not an analyst saying "NoOps". Analysts are easy (for me) to ignore, because they're not practitioners. We have expectations of engineering maturity from practitioners in this field of web engineering, especially those we consider leaders. I don't have any expectations from analysts,

Start a feature branch based off the develop branch and do your changes.

git flow feature start some_new_things

Bump the version number of each cookbook you work on, major numbers are for api changes, minor numbers are for new features and release numbers are for bugfixes.

Environment files are where we control the version of cookbooks that run

	Latency Comparison Numbers (~2012)
	----------------------------------
	L1 cache reference 0.5 ns
	Branch mispredict 5 ns
	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 us
	Send 1K bytes over 1 Gbps network 10,000 ns 10 us
	Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD

	check out pry screencast here http://pry.github.com/screencasts.html

	install pry
	$ gem install pry pry-doc

	start shef
	$ shef

	# load pry
	chef> require 'pry'

	Web Operations
	http://www.amazon.com/Web-Operations-Keeping-Data-Time/dp/1449377440/

	Scalable Internet Architectures
	http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X/

	The Art of Capacity Planning
	http://www.amazon.com/Art-Capacity-Planning-Scaling-Resources/dp/0596518579/

	The Visible Ops Handbook

	#!/usr/bin/env ruby
	# Processor for Github flavored markdown, inspired by:
	# https://github.com/alampros/Docter/blob/master/bin/github-flavored-markdown.rb
	#
	# Current version of this script can be found here:
	# https://gist.github.com/1300939
	#
	# Adapted for Redcarpet version 2 by Ralph von der Heyden
	# http://github.com/ralph
	# http://twitter.com/ralph

	#!/usr/bin/env ruby

	cbdir=ARGV[0]
	output = "./deps.dot"

	puts "Running on #{cbdir}..."

	cb_meta = Dir.glob("#{cbdir}/*/metadata.rb")

	fp=File.open(output,"w")

	# Use Chef resources in an application via solo mode.
	# Could also be configured in client mode, and then use a server.

	require 'rubygems'
	require 'chef'
	require 'chef/client'
	require 'chef/run_context'

	Chef::Config[:solo] = true
	Chef::Config[:log_level] = :info

	Chef::Log.level = :debug

	# your recipe

	Chef::Log.level = Chef::Config[:log_level]

	[Mon, 07 Mar 2011 20:38:02 -0700] INFO: Starting Chef Run (Version 0.9.14)
	[Mon, 07 Mar 2011 20:40:02 -0700] INFO: remote_file[/Users/jtimberman/.chef/cache/Emacs.dmg]: Creating /Users/jtimberman/.chef/cache/Emacs.dmg
	[Mon, 07 Mar 2011 20:40:04 -0700] INFO: Ran execute[hdid /Users/jtimberman/.chef/cache/Emacs.dmg] successfully
	[Mon, 07 Mar 2011 20:40:08 -0700] INFO: Ran execute[cp -r '/Volumes/Emacs/Emacs.app' '/Applications'] successfully
	[Mon, 07 Mar 2011 20:40:09 -0700] INFO: Ran execute[hdiutil detach '/Volumes/Emacs'] successfully
	[Mon, 07 Mar 2011 20:40:22 -0700] INFO: Chef Run complete in 140.384327 seconds
	[Mon, 07 Mar 2011 20:40:22 -0700] INFO: cleaning the checksum cache
	[Mon, 07 Mar 2011 20:40:22 -0700] INFO: Running report handlers
	[Mon, 07 Mar 2011 20:40:22 -0700] INFO: Report handlers complete