qconsp2018 - https://qconsp.com/schedule/tabular

dia 1

performance (netflix) - https://qconsp.com/system/files/keynotes-slides/qcon_sp_keynote_-_martin_spier.pdf
 - metricas impressionantes deles (requests, logs, latencia, instancias etc)
 - arquitetura (caches nos provedores)
 - 3 regioes aws
 - ec2 reserved (se nao tá streaming, usa pra recomendacoes, encoding etc)
 - build: amis ubuntu
 - deploy: 4000 por dia
 - tudo stateless
 - ferramentas (captura de metricas da redhat, flamegraph, flamescope etc)

commons pitfalls microservice integration (camundo) - https://qconsp.com/system/files/presentation-slides/3commonpitfallsmicroservicesintegrationqconsp2018camunda-180510165746.pdf
 - nao deixe a falha espalhar (circuit breaker)
 - nao faca um servico ter modos diferentes de comunicacao (ou eh REST, ou eh fila)
 - comunicacao async
 - retry em cada camada (nao na ponta)
 - workflow engine

arquiteturas de dados que quebram (lucidworks) - 
- data gravity
- cluster sem cabeca
- puxadinhos

microservices em producao (digital ocean)
 - lei de conway
 - service catalog
 - notas de maturidade do sistema (-1, 0, 1, 2, 3): ajuda a focar trabalho
 - arquitetura de microservicos: logica, log, metrics, rastreamento, tolerancia falhas, transporte
 - desses acima, deixar logica em um lado, todo o resto de outro (componentes diferentes dentro do servico)
 - service meshes (envoy)

cloud & ai (microsoft) - https://qconsp.com/system/files/presentation-slides/building_web_apps_with_cloud_and_ai.pptx
 - how-old.net
 - analise texto (extrai palavras principais)
 - bitcoin (indexacao noticias, tweets, analise sentimentos)
 - azure search (busca pela copa 2014, olimpiadas 2016 - zika virus)
 - jfk files (busca em texto escrito a mao, correcao entre pessoas e eventos)
 - cego com oculos que descreve a imagem

arquitetura e microservices (nubank) - https://qconsp.com/system/files/presentation-slides/arquiteturamicroservices4anos.pdf
- greenfield (sem legado)
- datomic, clojure, kafka
- microservices
- CD blue/green
- 140 engenheiros
- imutabilidade em tudo (clojure, datomic, kafka, docker, deploy blue/green)
- funcoes puras (static - sem "efeitos colaterais"): facil entender e testar, paralelizavel
- testes generaticos (property based testing)
- funcoes impuras movidas para borda do fluxo
- bibliotecas compartilhadas por toda empresa
- tudo padronizado (linguagem, logs, monitoramento, ferramentas de debug, tecnologias etc)
- postel's law: conservador no que produz, liberal no que recebe - tolerant readers
- ports and adapters (arquitetura hexagonal)
- logica de negocio / controller / io da app (diplomat) / canal de comunicacao (portas)
- portas (kafka, email, http, banco): teste de integracao
- diplomat: testes com mock das portas
- controller: teste de integracao / mock
- logica: teste unidade / generativos
- microservicos: nao compartilham banco / comunicam com 1 das portas - teste ponta a ponta

dia 2

blur physical x real world (thoughtworks) - nao tem slides
- automacao de fabricas, cidades, casas, carros

stress test (twitter) - https://qconsp.com/system/files/presentation-slides/stress_testing_twitter_ptbr_-_herval_freire.pptx
- picos: desenho japones, natal, oscar, copa 2014
- prealocar é caro
- 2 tipos: subto e breve / menor amplitude com maior duracao
- stress testing: pequenas API, duracao determinada
- redline testing: até quebrar
- omni testing: todo o sistema
- usar base de dado representativa
- scalding: ferramenta
- cuidado: nao afete users reais
- teste bom é teste em producao (ambiente de teste / qa / staging quase nunca tem todas as variaveis)
- ter forma de abortar trafego rapidamete (usam o zookeeper)
- fazer plano de teste para que todos fiquem sabendo
- sistemas degradaveis X auto-corretivos


redes neurais pytorch (kunumi) - sem slides (coding demo)
 - comparacao tensorflow
 - exemplo convergencia pontos
 - exemplo diabetes
 - exemplo imagens 32x32

evolutionary architecture (toughtworks) - https://qconsp.com/system/files/presentation-slides/principlesevolarch.pdf
- last responsible moment
- evolvability (quebre funcionalidades, documentacao e ferramentas leves, focas em hotspots)
- reversability
- postel's law
- conway's law
- choreography
- continuos delivery
- contract testing

nuconta (nubank) - https://qconsp.com/system/files/presentation-slides/qcon_presentation_-_construindo_a_nuconta_-_v03.pdf
- microservicos
- kafka async / http sync
- exemplo de transferencia de dinheiro, cenarios de falha e solucoes
- event sourcing
- como mudar funcionalidades trocando pequenas partes (transferencia para outros bancos, pagamento com cartoes externos etc)
- 2 requerimentos: at-least-once e idempotencia
- at-least-once: envia kafka, repete até chegar confirmacao
- idempotencia: id com sistema anterior / transaction_id
- BFF: backend do fron (para apps)
- graphql para diminuir quebras de contrato nas mudancas da api

distributed traces (uber) - sem slides (live demo)
- jaeger
- como identificar servico lento
- uber tem entre 5000 e 10000 servicos (o apresentador nao sabia exatamente)

legado (olx) - https://qconsp.com/system/files/presentation-slides/copia_de_qcon_2017_-_duplicado_-_desapegando_do_legado_-_wide_screen.key
- sistema de 1996, em C, feito na suecia (php, apache httpd)
- banco unico
- quebra em squads e dar independencia nao funcionou (cada um repetia o legado, em menor escala)
- solucao squad multidisciplinar
- mensagens async entre sistemas
- usam sns / sqs (tem os mesmos problemas que tivemos... fora de ordem, msgs duplicadas...)
- overhead gerencial (multiplicacao de microservicos)
- AWS ECS para containers

dia 3

cryptocurrency com data sciente e machine learning (coinbase) - nao compartilhou slides
- varios exemplos de fraudes
- como fizeram para contornar as fraudes

distributed tracing (petabridge - akka) - https://qconsp.com/system/files/presentation-slides/introduction_to_distributed_tracing.pdf
- zipkin
- opentracing
- trace / span/ spancontext / tracer
- codigo para coletar dados
- exemplo de como o trace é propagado entre os servicos
- formato do dado nas reqs

rust (mozilla) - https://qconsp.com/system/files/presentation-slides/rust_qcon.pdf
- high level code / low level performance
- sem problemas comuns (controle/felixbilidade, double free, dangling pointers, buffer overflow, data races)
- facilidade de paralelizar
- mais rapido do que C em varios casos (exemplo do isBlank())
- npm é em RUST
- data races: sharing X mutation X no ordering (escolha 2 desses 3)
- falha a compilacao (nao deixo erro aparecer no runtime)
- sistema de ownershipt e borrowing
- 3 modos: owned, shared reference, mutable reference
- exemplo paralelismo que roda em outras linguagens e falha a compilacao no rust
- arquitetura de desenvolvimento (core simples, features plugaveis via "unsafe")
- integracao com node, ruby, python, c++
- exemplo node 140x mais rapido (crypto validation)
- exemplo CSS paralelizado no firefox (em 7 anos nao conseguiram fazer em c++, fizeram em 3 meses com rust)
- exemplo sistema de monitoracao que gastava memoria e agora roda bem leve (skylight)

webassembly (microsoft - xamarin) - https://qconsp.com/system/files/presentation-slides/rodrigo-kumpera-webassembly.pdf
 - c/c++, rust, go
 - exemplo c#
 - chamar javascript dentro do c#
 - chamar c# dentro do javascript

containers em producao (getup) - https://qconsp.com/system/files/presentation-slides/getup_desafios_containers_producao_qcon_201805.pdf
- algumas dicas de seguranca (nao rodar como root etc)
- apresentacao foi bem ruim (durou 20 minutos)

monitoramento (netflix) - https://qconsp.com/system/files/presentation-slides/qcon_sp_talk_-_martin_spier.pdf
- importancia da monitoracao de alta precisao
- dificuldade de tirar metricas de um monte de sistemas diferentes (pcs, tvs, celulares, videogames)
- dificuldade em sistemas limitados (pouca memoria, pouco cpu, pouca banda)
- dificuldades em fazer rodar no mundo todo (na india nao dá pra metrica afetar o streaming)
- zilhoes de metricas: abrir app, abrir primeiro frame do video, click em tudo quanto é lugar, wall time, TTI, TTR, play delay
- coisas em c++, java, js
- centenas de bilhoes de eventos por dia (petabytes de dados)
- spark, presto, druid
- data sketches (modelagem com poucos dados que representam uma massa muito maior) - usam o t-digest
- tomar cuidado com dados que podem mentir pra vc (exemplo de brazil mais lento do que india)
- automacao: deteccao de anomalias - standard deviation funcionou muito bem... sufisticaram com RAD (robust anomaly detection)
- evitar eventos frequentes (afeta usuario)
- com sampling vc perde casos que acontecem raramente
- solucao: usar dispositivos dos users como map-reducers (buckets com contadores das metricas) - otimizacao: bucket tamanho exponencial (precisao nos que importam)
- magic modem para os devs simularem todas as condicoes do mundo

kubernetes (magazine luiza) - https://qconsp.com/system/files/presentation-slides/arnaldo_-_qcon_-_duas_black_fridays_depois.pdf
- foram early-adopters (kube 1.3 / 2016)
- desenvolveram varias coisas "em casa" pq nao existiam na epoca
- teresa: api pra fazer deploy e monitorar
- kube-watch: verifica crashloop
- bot do slack pra alterar deployments
- problema: HPA lento