emerleite/gist:3621544

## gistfile1.txt
http://estelle.github.com/mobileperf/#slide55

https://github.com/impressiver/velocity2012

https://github.com/jonlives/velocity_resources


Chef - Jon Cowie (Etsy)

Ele tem um handler que consegue mandar o que falha para or irc usando
irccat e irc.

knife for chef - procura nos nós por alguma coisa. Por evemplo um
erro.

Usar a gem  knife-lastrun

syslog-ng
(http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/overview)


Foodcritic
* Tipo um JSLint só que pra chef
* http://acrmp.github.com/foodcritic/
* Jekins Integration - #!/usr/bin/env rvm-shell 1.9.2 foodcritic -f
correctness .

A Etsy tem alguns padrões que eles usaram para customizar o
Foodcritic, por exemplo, não permitir update automático de pacotes.
https://github.com/etsy/foodcritic-rules

Knife Spork (wrapper environment)

* dá um boost no esquema dos environments
* https://github.com/jonlives/knife-spork
* Consegue mostrar as versões de um pacote e quais estão frozen
* Tem um wrapper para upload já com freeze
* Usa o Foodcritic no Upload

--------------------------------------------------------------------------------
Dev vs. Prod
============

mod_pagespeed - A forma de não ter um dev env e dev prod mais próximo
na visão do palestrante. Preciso formular algo a respeito favorável ou
contrário para apresentar no tech talk.

https://developers.google.com/speed/pagespeed/mod

---------------------------------------------------------------
Juju - https://juju.ubuntu.com/

* Juju gerencia serviços, não máquinas
* apt-get, só que para várias máquinas

Charms - http://jujucharms.com/
------
São scripts que fazem o trabalho

### Charm store
Compartilhado com todos. Existe uma oficial, mas é configurável para
você apontar para qualquer diretório, local, etc.

juju bootstrap -> Inicia o ambiente da máquina
juju status -> Mostra o andamento de uma tarefa

A boa é usar um Puppet ou Chef para Configurar mount, permissões de
usuários, e similares e usar o Juju para os serviços (e.g mysql,
mongo, http server, rails, etc).

--------------------------------------

Investigating anomalies - John Rauser
=====================================

* Frase de efeito: Explaining anomalies makes your system more bulet proof
* Usou o exemplo da cólera
* John Snow pesquisou a fundo os acontecimentos além dos dados
estatísticos de alto nível. Foi além do básico.
* HTTP archive
* Olhar as estatísticas de performance pelas pontas (mais rápido ou
mais lento), geralmente mostra erros ou casos que não ajudam.

Resilient User Experience - Mike Brittain - Etsy
================================================

* Exemplo do mercado com uma pia vazando água interrompe as compras de
  todos pedindo para eles sair da loja, o que não faz sentido, pois não
  é um problema que impede o usuário de comprar.

* Se uma das ofertas da página falha eu não deveria deixar o site todo
  com erro.

* Ele considera que lidar bem com isso é uma forma de graceful
  degradation.

* A parte mais importante da página deve estar presente. Os acessórios
  podem não ser renderizados.

* Os serviços acessórios podem perfeitamente ser carregados com Ajax.

* Na minha opinião, ao implementar isso, é importante identificar a
  parte semântica (relevante para a busca) e manter no HTML que é
  cacheado e que será usado pelos mecanismos de busca.

* É muito importante também identificar o critical path para saber
  qual serviço pode e qual não pode falhar.

Predicting User Activity to Make the Web fast - Arvind Jain and Dominic Hamon
=============================================================================
Dados se baseiam nas métricas do Chrome.

* http://httparchive.org/ - Verificar o temanho das páginas durante o tempo.
* O que tem feito ficar mais rápido são os browsers melhorando, a internet ficando mais rápida e o hardware melhorando.
* Páginas mais rápidas tem seu papel, mas ainda não é do jeito que deveria, talvez
* ~ 3 segundos para digitar uma URL
* ~ 15 para selecionar um resultado da busca
* Algorítimo para definir qual o resultado mais interessa ao usuário.
* Page Visibility API
* <link rel="prerender"> nos links onde você sabe o fluxo do usuário para melhorar a experiência do usuário
* prerender-test.appengine

Implications of Responsive Web Design - Jason Grigsby
=====================================================

* https://speakerdeck.com/u/grigs/p/performance-implications-of-responsive-design
* Performance?
* Mobile First Web Design (progressive enhancement) - http://bradfrostweb.com/blog/mobile/anatomy-of-a-mobile-first-responsive-web-design/

Melhorando o responsive
1. Desenhar primeiro o mobile
  * Respond.js ou condicionais para carregar um css diferente para um IE
menor que o IE 9
  * Timkadlec.com
2. Carregar o JS condicionalmente de acordo com a tela
  * usar o matchMedia() - https://github.com/paulirish/matchMedia.js/

4. Enviar imagens diferentes de acordo com a resolição
  * https://github.com/scottjehl/picturefill - data-src e data-media
  * Sencha.io
  * https://github.com/adamdbradley/foresight.js
  * https://github.com/filamentgroup/Southstreet (essa é a parada)

Real-time systems at twitter
============================

* Monorail - Monolitic Ruby on Rails application - Era o twitter monolítico
* Não tinha uma estrutura de serviços
* Finagle - http://twitter.github.com/finagle/
* Zipkin - http://engineering.twitter.com/2012/06/distributed-systems-tracing-with-zipkin.html
* Iago - http://twitter.github.com/iago/
* Monorail virou o Woodstar
* Tinham o desafio de componentizar o ambiente para conseguir ter times pequenos trabalhando no mesmo produto, mas em projetos diferentes
* 45% do trafego do twitter hoje é servido pela stack da JVM

Node.js - @sh1mmer
==================

* Uma Bosta

Stabiity Patterns - Michael Nygard (Relevance, Inc.)
=================

* O cara que escreveu o ReleaseIt

The Performance of Web vs. Apps - Ben Galbraith e Dion Almaer
=============================================================

* Experiência Mativa é sempre melhor (obvio)
* Uso de Node.JS para decidir onde vai renderizar. No server ou no client.
* http://functionsource.com/


Mobile Browsers - Opera Mobile and Opera Mini: Top Speed in a Tiny Package
==========================================================================

* Não faz a request http direto, mas vai via um proxy para um opera
  server que pega a página e faz o cache pra devolver para os clientes
* Dropei o resto para fazer a avaliaçõa

Chrome
======

* Falou sobre Smooth Graphics and Memory footprint

JavaScript Timers, Power Consumption, and Performance - Nicholas Zakas
======================================================================

* Usar muitos timers no browser caga a bagaça.
* Para animação use requestAnimationFrame()
* Processamento use Web Workers
* Slides - http://www.slideshare.net/nzakas
* Artigo - http://www.nczonline.net/blog/2011/09/19/script-yielding-with-setimmediate/

Scaling Pinterest
=================

* Remodelaram a arquitetura diversas vezes
* Utilizam amazon EC2 + S3
* MySQL e Redis
* Eles preferiram fazer sharding do que fazer um cluster de um NoSQL por exemplo. O argumento é que por algumas vezes o algorítimo do cluster estava bugado e ferrou com eles.
* Montaram uma estrutura de sharding prórpia.
* Pra pegar dados antigos criaram o Pyres - https://github.com/binarydud/pyres
* Redis para cachear os mapeamentos e Memcache para fazer o cache dos objetos


2 Essential tools for UI performance - @stubbornella - http://www.stubbornella.org/
===================================================================================

* Rodar o web pag test com css desligado para ver quanto o css está pesando
* Inserir no dom é lento
* Webkit e Gecko implementaram melhorias de performance nos seletores CSS e os outros browsers estão implementando
* Child selectors tem mais performance
* :hover ficou mais performático
* []
* .foo + .bar aplica o estilo no .foo e no .bar sequente apenas
* .foo ~ .bar aplica o estilo no .foo em todos os .bar sequentes
* + e ~ são lentos e não funcionam direito em todos os browsers
* Chrome tem um CSS selector profile
* TILT - Firefox extension - Testar no site da CNN (Muito DOM, muito lento. SEMPRE)
* Stickies - Marca tempo
* Alexa - http://www.alexa.com/toolbar
* Chrome Selector Audit - https://developers.google.com/chrome-developer-tools/docs/overview
* -show-paint-rects -> na linha de comando para habilitar a visualização de como as coisas estão sendo desenhadas do chrome

Living with technical debt - Nathan Yergler - Principal Engineer - Eventbrite - @nyergler
=========================================================================================

* Nada de interessante
	http://estelle.github.com/mobileperf/#slide55

	https://github.com/impressiver/velocity2012

	https://github.com/jonlives/velocity_resources


	Chef - Jon Cowie (Etsy)

	Ele tem um handler que consegue mandar o que falha para or irc usando
	irccat e irc.

	knife for chef - procura nos nós por alguma coisa. Por evemplo um
	erro.

	Usar a gem knife-lastrun

	syslog-ng
	(http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/overview)


	Foodcritic
	* Tipo um JSLint só que pra chef
	* http://acrmp.github.com/foodcritic/
	* Jekins Integration - #!/usr/bin/env rvm-shell 1.9.2 foodcritic -f
	correctness .

	A Etsy tem alguns padrões que eles usaram para customizar o
	Foodcritic, por exemplo, não permitir update automático de pacotes.
	https://github.com/etsy/foodcritic-rules

	Knife Spork (wrapper environment)

	* dá um boost no esquema dos environments
	* https://github.com/jonlives/knife-spork
	* Consegue mostrar as versões de um pacote e quais estão frozen
	* Tem um wrapper para upload já com freeze
	* Usa o Foodcritic no Upload

	--------------------------------------------------------------------------------
	Dev vs. Prod
	============

	mod_pagespeed - A forma de não ter um dev env e dev prod mais próximo
	na visão do palestrante. Preciso formular algo a respeito favorável ou
	contrário para apresentar no tech talk.

	https://developers.google.com/speed/pagespeed/mod

	---------------------------------------------------------------
	Juju - https://juju.ubuntu.com/

	* Juju gerencia serviços, não máquinas
	* apt-get, só que para várias máquinas

	Charms - http://jujucharms.com/
	------
	São scripts que fazem o trabalho

	### Charm store
	Compartilhado com todos. Existe uma oficial, mas é configurável para
	você apontar para qualquer diretório, local, etc.

	juju bootstrap -> Inicia o ambiente da máquina
	juju status -> Mostra o andamento de uma tarefa

	A boa é usar um Puppet ou Chef para Configurar mount, permissões de
	usuários, e similares e usar o Juju para os serviços (e.g mysql,
	mongo, http server, rails, etc).

	--------------------------------------

	Investigating anomalies - John Rauser
	=====================================

	* Frase de efeito: Explaining anomalies makes your system more bulet proof
	* Usou o exemplo da cólera
	* John Snow pesquisou a fundo os acontecimentos além dos dados
	estatísticos de alto nível. Foi além do básico.
	* HTTP archive
	* Olhar as estatísticas de performance pelas pontas (mais rápido ou
	mais lento), geralmente mostra erros ou casos que não ajudam.

	Resilient User Experience - Mike Brittain - Etsy
	================================================

	* Exemplo do mercado com uma pia vazando água interrompe as compras de
	todos pedindo para eles sair da loja, o que não faz sentido, pois não
	é um problema que impede o usuário de comprar.

	* Se uma das ofertas da página falha eu não deveria deixar o site todo
	com erro.

	* Ele considera que lidar bem com isso é uma forma de graceful
	degradation.

	* A parte mais importante da página deve estar presente. Os acessórios
	podem não ser renderizados.

	* Os serviços acessórios podem perfeitamente ser carregados com Ajax.

	* Na minha opinião, ao implementar isso, é importante identificar a
	parte semântica (relevante para a busca) e manter no HTML que é
	cacheado e que será usado pelos mecanismos de busca.

	* É muito importante também identificar o critical path para saber
	qual serviço pode e qual não pode falhar.

	Predicting User Activity to Make the Web fast - Arvind Jain and Dominic Hamon
	=============================================================================
	Dados se baseiam nas métricas do Chrome.

	* http://httparchive.org/ - Verificar o temanho das páginas durante o tempo.
	* O que tem feito ficar mais rápido são os browsers melhorando, a internet ficando mais rápida e o hardware melhorando.
	* Páginas mais rápidas tem seu papel, mas ainda não é do jeito que deveria, talvez
	* ~ 3 segundos para digitar uma URL
	* ~ 15 para selecionar um resultado da busca
	* Algorítimo para definir qual o resultado mais interessa ao usuário.
	* Page Visibility API
	* <link rel="prerender"> nos links onde você sabe o fluxo do usuário para melhorar a experiência do usuário
	* prerender-test.appengine

	Implications of Responsive Web Design - Jason Grigsby
	=====================================================

	* https://speakerdeck.com/u/grigs/p/performance-implications-of-responsive-design
	* Performance?
	* Mobile First Web Design (progressive enhancement) - http://bradfrostweb.com/blog/mobile/anatomy-of-a-mobile-first-responsive-web-design/

	Melhorando o responsive
	1. Desenhar primeiro o mobile
	* Respond.js ou condicionais para carregar um css diferente para um IE
	menor que o IE 9
	* Timkadlec.com
	2. Carregar o JS condicionalmente de acordo com a tela
	* usar o matchMedia() - https://github.com/paulirish/matchMedia.js/

	4. Enviar imagens diferentes de acordo com a resolição
	* https://github.com/scottjehl/picturefill - data-src e data-media
	* Sencha.io
	* https://github.com/adamdbradley/foresight.js
	* https://github.com/filamentgroup/Southstreet (essa é a parada)

	Real-time systems at twitter
	============================

	* Monorail - Monolitic Ruby on Rails application - Era o twitter monolítico
	* Não tinha uma estrutura de serviços
	* Finagle - http://twitter.github.com/finagle/
	* Zipkin - http://engineering.twitter.com/2012/06/distributed-systems-tracing-with-zipkin.html
	* Iago - http://twitter.github.com/iago/
	* Monorail virou o Woodstar
	* Tinham o desafio de componentizar o ambiente para conseguir ter times pequenos trabalhando no mesmo produto, mas em projetos diferentes
	* 45% do trafego do twitter hoje é servido pela stack da JVM

	Node.js - @sh1mmer
	==================

	* Uma Bosta

	Stabiity Patterns - Michael Nygard (Relevance, Inc.)
	=================

	* O cara que escreveu o ReleaseIt

	The Performance of Web vs. Apps - Ben Galbraith e Dion Almaer
	=============================================================

	* Experiência Mativa é sempre melhor (obvio)
	* Uso de Node.JS para decidir onde vai renderizar. No server ou no client.
	* http://functionsource.com/


	Mobile Browsers - Opera Mobile and Opera Mini: Top Speed in a Tiny Package
	==========================================================================

	* Não faz a request http direto, mas vai via um proxy para um opera
	server que pega a página e faz o cache pra devolver para os clientes
	* Dropei o resto para fazer a avaliaçõa

	Chrome
	======

	* Falou sobre Smooth Graphics and Memory footprint

	JavaScript Timers, Power Consumption, and Performance - Nicholas Zakas
	======================================================================

	* Usar muitos timers no browser caga a bagaça.
	* Para animação use requestAnimationFrame()
	* Processamento use Web Workers
	* Slides - http://www.slideshare.net/nzakas
	* Artigo - http://www.nczonline.net/blog/2011/09/19/script-yielding-with-setimmediate/

	Scaling Pinterest
	=================

	* Remodelaram a arquitetura diversas vezes
	* Utilizam amazon EC2 + S3
	* MySQL e Redis
	* Eles preferiram fazer sharding do que fazer um cluster de um NoSQL por exemplo. O argumento é que por algumas vezes o algorítimo do cluster estava bugado e ferrou com eles.
	* Montaram uma estrutura de sharding prórpia.
	* Pra pegar dados antigos criaram o Pyres - https://github.com/binarydud/pyres
	* Redis para cachear os mapeamentos e Memcache para fazer o cache dos objetos


	2 Essential tools for UI performance - @stubbornella - http://www.stubbornella.org/
	===================================================================================

	* Rodar o web pag test com css desligado para ver quanto o css está pesando
	* Inserir no dom é lento
	* Webkit e Gecko implementaram melhorias de performance nos seletores CSS e os outros browsers estão implementando
	* Child selectors tem mais performance
	* :hover ficou mais performático
	* []
	* .foo + .bar aplica o estilo no .foo e no .bar sequente apenas
	* .foo ~ .bar aplica o estilo no .foo em todos os .bar sequentes
	* + e ~ são lentos e não funcionam direito em todos os browsers
	* Chrome tem um CSS selector profile
	* TILT - Firefox extension - Testar no site da CNN (Muito DOM, muito lento. SEMPRE)
	* Stickies - Marca tempo
	* Alexa - http://www.alexa.com/toolbar
	* Chrome Selector Audit - https://developers.google.com/chrome-developer-tools/docs/overview
	* -show-paint-rects -> na linha de comando para habilitar a visualização de como as coisas estão sendo desenhadas do chrome

	Living with technical debt - Nathan Yergler - Principal Engineer - Eventbrite - @nyergler
	=========================================================================================

	* Nada de interessante