Opening Remarks - Jesse Demonstrates Caffeine IV
John Allspaw is being graduated as a co-chair of the program of the conference. (sponsors thanks).
Career Development
Theo Schlossnagle is talking about career. He has been a system engineer before being into Web Operations.
A career is a journey, a willingness to mature, a patience to become exceptional
Whatever we do we must treat it as a craft
- step 1: educate yourself
- step 2: be disciplined. It takes time to be a master, it is a long eay
- step 3: learn and share with your peers.
- step 4: be patient: experience takes time
your website is a SaaS, whatever the type of site as soon as you have users. The product (Web site) is one copy and has to evolve, perform and deliver. COO is someone responsible for daily operations. DevOps is bullshit. DevOps is incomplete and too limited. We need .*Ops You need operational mentality for delivering to users expectations. The job will require a lot of competences such as languages, and Ops’ Job were deployment, resources management, etc. There is no magic. The cloud is not a solution. Virtualization is the interesting part. Provisioning is not an operation jobs. Being in the cloud is not a guarantee. Security is not a feature, it is a state of mind, everything has to have security. Operations is the same. Everything have to be thought. We are responsible for everything and be on call. If you break things at 3am you have to be responsible for it, it means fixing it.
- rule 1 : what you build will break.
Operational thinking… there is a need for more ops into dev. To be able to debug in production because it is where things break. Titles don’t matter. Everyone of us is responsible. This mentality is the beginning of your career.
@postwait
JavaScript & Metaperformance
Douglas Crockford time! 
Javascript was
not really efficient but it has changed. There is no time for optimizing
because javascript is mostly executed on load. There is a trade-off
between optimization and portability. Portability is the best thing for
the Web. Java is the biggest failure in the histore of software
development. Failed security model, lack of portability, awful UI
toolkit, horrendous startup times.
Optimize as you go. It is a style which has been developed for the self language and applied later on to JS. The new engines are fast, but it is complicated to understand how they are faster. Having an accurate answer is almost impossible to know. Benchmarks tend to be written by people who don’t really know the language. There is a bias. JSMeter showed that benchmarks have no correlation with real use cases, but you need them to have numbers.
The browsers are basically a black box. Browser platform contains some deep inefficiencies with little visibility of them. The DOM is a bottleneck. The DOM is the PITA for making faster browsers. Optimizing JS code is not really effective. Premature is the root of all evil —Knuth. Web dev have a tendency to optimize in advance because they think they will not have a chance to do it later. They sometimes use the winner instead of something that will scale better. Benchmarks driving engine performance driving programming style and in the end discourage good programming practices.
JS has good parts (book plug). JSLint will help to improve the code. The benchmarks do not reflect the characteristics of a good program. JSLint.js is a benchmark. The results show only what they do against the browser.
from 2.80s to 0.54s with opera in the middle. (photo)
Because of this everyone is getting much much better.
Look at Your Data
John Rauser is introducing on how to look to your data. Timeline series give us hindsight. Analogy with a piece of arts and how we analyze them. Is it not always meaningful.An average and the medium are very lossy compression algorithm. There is a lot of complexity behind the mean. A simple line might hide a lot of stories.
How can we look more deeply at our data?
Histogram is a first step, but be careful they can hide things too. Each curves have hidden meaning. For example do a latency vs count in histogram. If the customers are well behaved you get a game curve. But with more complex shapes you might show different types of customers.
(remind me the story of RDS data)
By manipulating data you will reveal little by little patterns and become aware of what seems to be wrong in the data. Sometimes you have to look at individual hits to understand.
Some low techniques can help a lot, grep, printing on paper, etc. might help to understand. The screen is sometimes too limiting. You have to sculpt the data. Your brain and your eyes are a tremenduous pattern matching tool. The size of impacts can be sometimes smaller than a pixel in a curve but might give a very bad experience for users.
Look at your data to understand your business and your customers.
Testing and Monitoring Mobile Apps
Vik Chaudhary, Manny Gonzalez giving a sales speech.