Terceiro e ultimo dia de QConSP 2014

Este post demorou um pouco para sair porque no ultimo dia do QCon meu notebook ficou sem bateria e o hotel não tinha nenhuma tomada no padrão novo, pode isso? Até tentei escrever o texto no aplicativo do Blogger no celular, mas acabei desistindo depois de perder o texto duas vezes. O dia logo após o término do QCon foi consumido pela viagem de volta para casa e uma confraternização; o dia subsequente foi consumido por um passeio turístico em outra cidade. Mas, finalmente estou em casa e, mesmo cansado, escrevo este post para nossa alegria.

O terceiro e ultimo dia do QConSP 2014 começou com a apresentação Introduction to Hadoop. Achei bem estranho uma keynote com "Introduction" no título. Acredito que ficou como keynote apenas por causa do palestrante: Todd Lipcon, um membro-fundador do Hadoop. Achei uma apresentação bem introdutória e não motivadora, logo não mereceria destaque como uma keynote. Na mesma lógica, não terá destaque neste post, até porque não tem muito o que falar mesmo. A parte memorável foi ver ele tentando fazer um notebook com Ubuntu e uma espécie de Fluxbox funcionar para projetar a apresentação. Deu dó. Depois de uns cinco minutos se batendo com a resolução, ele abriu uma máquina virtual com Windows XP para abrir a apresentação PPTX dele. Ha-ha. Mas daí a resolução não encaixou e ele se rendeu à utilizar um Macbook de um organizador.

Design-Driven Development & Context-Driven Experience

A segunda keynote do dia foi de um designer que trabalha na Prezi. Mostrou um pouco de história e do processo de desenvolvimento interno: iterativo e incremental. Parece que todo mundo reforça o modelo "fail fast, iterate".

Trouxe a tona um fato interessante: muita gente no evento estava usando Pebble Smartwatch e que as próximas tecnologias dominantes serão "vestíveis". Curiosamente isto combinou com um artigo que li no mesmo dia afirmando que o fundador do Evernote disse que "Apps Will Soon Be Obsolete".

O apresentador falou que é necessário pensar em três coisas a respeito da experiência do usuário para atender multi-dispositivos:

1. Consistente: A experiência deve ser consistente com o dispositivo sendo utilizado. Cada dispositivo terá uma maneira diferente de apresentar e de interagir com o usuário.
2. Contínua: A experiência deve ser contínua entre os dispositivos. Ele não deve ter que pensar toda vez que for mudar de dispositivo, e.g. ao começar a ler um livro no smartphone, ao pegar o tablet, o livro deve abrir na mesma página.
3. Complementar: A experiência de um dispositivo pode complementar a de outro. A experiência pode iniciar em um dispositivo, continuar em outro e terminar em um terceiro. Um complementando o outro, e.g. comprar um ticket pelo notebook e utilizar o smartphone como carteira virtual.

Track talks

Java 8 na prática, do Lambda às novas APIs: Mostrou novas APIs do Java 8 para tratamento de datas e como ficou a sintaxe das expressões lambdas. Achei a sintaxe e as APIs apresentadas bem agradáveis. Apesar de serem mudanças bem suaves, mostram que a linguagem está evoluindo.

Monadic Java: Functional Programming Patterns Applied: Detectou três monads na nova API do Java 8 e tentou explicar de forma simples o que é um monad. Achei a apresentação válida, mas a explicação de monad foi fraca, não sei se o apresentador conseguiu atingir o objetivo. Eu achei tranquilo porque já passei por algumas tentativas de implementar monads no Java, já presenciei os problemas relacionados ao sistema de tipos do Java em relação à isto, então a apresentação dele me pareceu bem entendível e palatável. De qualquer forma, a melhor explicação que eu vi sobre monads até hoje está no YouTube no vídeo Brian Beckman: Don't fear the Monad.

Falling in Love with APIs without divorcing legacy software: Apresentação falou do uso do Mulesoft para expor APIs de código legado. Foi uma apresentação agradável e bem animadora. O produto deles parece estar muito bom.

Multithreading e Java EE: pouca mudança no código e muita nos resultados: Mostrou a utilização da anotação @Asynchronous em JavaEE. JavaEE é uma coisa estranha: é um padrão despadronizado. Cada servidor faz de um jeito. Durante a apresentação ocorreram duas exceções completamente alienígenas, mas que o apresentador já conhecia, então ele resolveu rápido. Não gosto muito de coisas que acontecem de forma demasiadamente mágica, que dependem do contexto em questão.

Arquiteturas na nuvem com os custos sob controle: processando bilhões de páginas na AWS sem estourar o cartão: Contou como eles fazem para utilizar a infraestrutura da AWS sem gastar muito. Desenvolveram um sistema interno para otimizar a compra de máquinas por leilão (spot instances). Achei muito interessante. Comentaram que pretender abrir como open source, então fiquem ligados nas noticias da TailTarget.

FIM. Pois é, acabou. Assim, sem mais e nem menos. Quando saí da apresentação anterior, os patrocinadores já estavam se recolhendo e os nerds estavam indo embora. Ano passado teve um keynote no final que permitiu que a organização fizesse um breve discurso de encerramento. Este ano não teve isto, achei bem estranho e meio "tosco", podiam pelo menos ter dito "até mais, e obrigado pelos peixes", ou qualquer frase curta para deixar o pessoal brevemente empolgado e falando bem do evento.

Gostou dos posts que fiz sobre o QCon? Então adiciona meu blog nos teus feeds. Nem falei de Haskell nesse post, o que mostra que também posso ser um cara legal! Afinal, eu podia estar falando de Haskell, mas tô aqui pedindo sua assinatura... :)

Segundo dia de QConSP 2014

O segundo dia de QConSP 2014 começou com duas keynotes fantásticas. O primeiro a falar foi um membro do Jet Propulsion Lab da NASA: Rob Witoff, seguido por Jarrod Overson, que trabalha na RIOT Games (a empresa por trás de League of Legends). Depois começaram as tracks com palestras simultâneas, escolhi participar das que tinham algum relacionamento direto com desenvolvimento. Post rápido!

Building a Data Science Program at NASA/JPL with Visual Analytics

O palestrante é um data scientist que trabalha na NASA. Fez uma analogia interessante, em resumo do que minha memória permite: "uma vasta porção do nosso universo é dark matter, que nós ainda não entendemos; da mesma forma os dados que nós temos e não entendemos são dark data; podemos ter muito conhecimento interessante escondido nos nossos silos de armazenamento de dados".

Ele elencou passos importantes para explorar a dark data:

1. Liberate data: consistem em liberar este dado escondido e torná-lo acessível. Eles fizeram muito nisso e tornaram vários dados acessíveis através de APIs Web públicas, i.e. torne fácil de acessar os dados, construa uma camada em cima deles, esqueça strings de conexão cabulosas para acessar os repositórios.
2. Enable engineers: torne possível que as pessoas possam interagir com os dados, que eles consigam fazer o que precisa ser feito: filtrar, combinar, analisar, etc.
3. Infuse data science: coloque data science em tudo isso, correlacione os dados, encontre padrões.
4. Innovate: agora você já tem tudo que precisa para inovar, então vá e inove! Mostre estes dados de formas diferentes e tire conclusões sobre eles, construa camadas em cima de camadas e continue inovando.

A NASA possui um negócio bem interessante chamado "innovation vacation" que consiste em tirar "férias" para inovação. Um profissional tem uma ideia; a ideia é boa; este profissional irá tirar "férias para inovação" para construir a ideia junto com o pessoal de inovação, são no máximo duas semanas em que a pessoal fica completamente isolada do resto da empresa: sem acesso a e-mails, sem reuniões, etc; o time do palestrante faz uma espécie de coaching deste profissional durante este período; este tempo possui três "marcos" fundamentais: alinhamento, demo e entrega, i.e. é feito um alinhamento inicial da ideia e das expectativas, depois de um certo trabalho é feito uma demonstração para ver se está indo no caminho certo e no final do ciclo é feita a entrega e fim, não há adiamentos ou prolongamentos.

Dois slides desta apresentação me deixaram muito feliz, que fala como funciona a parte de inovação da NASA e que apoiam o que escrevi no post sobre otimização prematura de negócio e com alguns comentários do post sobre o primeiro dia de QCon:

• Fail fast. Iterate.
• Run like a startup

Scaling League of Legends: managing culture, extreme complexity and 30 million active users

Achei que esta apresentação seria mais técnica, mas falou do problema de escalar pessoas, processos, etc. Comentou que o quê funciona no "pequeno" não funciona no "grande". A apresentação trouxe a Web como exemplo de algo que escalou muito bem e o apresentador afirma que ela escalou porque ela precisava escalar de um jeito ou de outro e podemos aprender com ela:

1. Ela precisa ser distribuída, pessoas do mundo inteiro irão acessar conteúdos espalhados por todo lugar.
2. Precisa ser assíncrona e levar em consideração timezones diferentes.
3. Todos são iguais, não importa se você tem doutorado ou ainda está no colégio, você tem o direito de ver e publicar conteúdo.

Ele relaciona estes pontos da Web para tornar uma empresa escalável: você precisa ter formas de comunicação assíncronas, reuniões não são escaláveis; você precisa ter uma maneira de colaboração, em que todos são ouvidos; você precisa lidar com times remotos; etc. (A parte em ênfase foi a que achei top da balada.)

Depois ele entrou mais em detalhes da parte Web, mostrando que ela passou a ser um target de compilação válido. Unity está compilando jogos para rodar na web; Asm.js está fazendo o Javascript ser mais nativo/rápido; Web Components estão aí; HTTP2.0 irá revolucionar a forma de trabalho. Achei interessante, pois depois relacionei isto com as demais apresentações e é notável de que tudo parece estar com uma perna nas tecnologias fundamentais para a Web (HTML, CSS, JS). O que me fez ver mais valor ainda em iniciativas como o Haste (compilador Haskell com target para Javascript).

Track talks

Vou tentar resumir as talks das tracks, pois não achei nenhuma que merecesse destaque.

Programação funcional reativa: Lidando com código assíncrono: Interessante, pelo menos ele falou que gosta de Haskell. Mostrou como funciona o RxJS, um framework com grande influência de FRP (Functional Reactive Programming) para Javascript.

JavaScript Funcional: Bem didática e boa abordagem, porém muito introdutório, aproveitei pouco, exceto por ter conhecido o link FunctionalTalks.org.

Uma startup em Scala: Dos patterns à produção: Muita introdução, mais do mesmo. Ver código Scala sempre me dá vontade de vomitar. É verborrágico de mais. O pessoal se gaba do type-system, mas o negócio leva décadas para compilar. Me gusta Haskell, great type system, great compilation time.

C# e C++/CX - O que há de novo nas linguagens para suportar o desenvolvimento de aplicações modernas: Esta trouxe uma visão legal da unificação que a Microsoft está fazendo em suas quatro plataformas: Smartphone, Tablet, Desktop e XBox. A interoperabilidade que ela está fazendo me pareceu fantástica: código C++/CX chamado de Javascript e vice-versa, C# no meio, novos conceitos de "aplicações modernas".

Building a Cloud IDE you might not hate: the Orion experience and beyond: Comentou sobre a construção da IDE na nuvem chamada Orion e mostrou alguns concorrentes, nada muito interessante até o momento, apenas mostra que existe um movimento forte de várias empresas e iniciativas da comunidade para uma IDE na nuvem.

Primeiro dia de QConSP 2014

Hoje foi o primeiro dia do evento QConSP 2014. Vou tentar resumir minhas percepções sobre este primeiro dia de evento. O dia foi composto de dois tutoriais: um de manhã e um a tarde e finalizava com três apresentações curtas (short-talks). Elaborei este post de forma rápida, desculpe se o texto está difícil de entender.

Iniciando com Continuous Delivery

O primeiro tutorial que participei falava sobre entrega contínua (Continuous Delivery). Algo que já estou estudando e tentando praticar, porém até agora somente em provas de conceito e testes, nada colocado em produção de fato. Decidi participar deste tutorial para ver se conseguia conectar com as minhas experiências.

Quanto mais estudo sobre arquitetura orientada a serviços, integração contínua e entrega contínua mais percebo que são assuntos cada vez mais consolidados e todos eles se resumem basicamente em atitude. Que inclusive foi algo comentado pelos palestrantes Fabricio Leoti e Rodrigo Russo. Não existe uma bala de prata para a "nova indústria de software", o que existem são profissionais com atitude comprometidos em fazer algo funcionar; profissionais que estão acima de crenças e de seus próprios egos; o novo profissional de software deve fazer o melhor possível para integrar várias ferramentas de mercado em seu favor, sempre buscando eliminar sua própria existência como uma necessidade para a empresa, i.e. automatizar e tornar mais eficientes todos os processos para que fique livre para explorar coisas mais interessantes e que tragam valor para a corporação.

Este novo modelo de trabalho está se tornando cada vez mais forte. O que percebo é que é uma questão de tempo: quem não se adaptar, não conseguirá captar e reter os melhores profissionais e consequentemente, com o tempo, não conseguirá mais entregar valor para seus clientes, que procurarão fornecedores que acompanhem o novo ritmo do mundo. A entrega contínua faz parte desse novo mundo: todos que querem se manter atualizados precisam aprender e se adaptar.

Para obter a entrega contínua é preciso disciplina: é preciso ter processos de provisionamento automatizados e um processo de integração contínua funcionando 100%. A preparação deve ser feita na parte cultural da equipe: todos precisam querer e buscar este nível de excelência.

Acredito que as partes deste tutorial que mais podem contribuir com meu trabalho atualmente são:

1. Todos devem ser responsabilizados por tudo: a qualidade não é responsabilidade só do time de testes; a evolução do produto não é só responsabilidade do gerente de produto; o erro não é responsabilidade só do time de desenvolvimento. Todos precisam se sentir envolvidos e donos do produto final. É como se a equipe se tornasse uma startup: todos comemorarão com os sucessos e todos sofrerão com os fracassos.
2. Uma funcionalidade só é considerada "entregue" quando ela está em produção e em uso pelos clientes. Pensando bem, não sei como não cheguei nesta conclusão por conta própria. É um pensamento completamente razoável e com sentido. Na verdade, pensar de outra forma é que não faz o menor sentido: como você pode considerar uma funcionalidade como "entregue" se não tem ninguém usando? Frases como "está pronto, só faltam os testes" ou "está pronto, só falta jogar para produção" não fazem o menor sentido!

NoSQL Aplicado

Compareci neste tutorial para ver na prática as aplicações de bases NoSQL. Estou começando a trabalhar um pouco com o MongoDB, mas sempre ouço falar bem do Cassandra, HBase, etc. Gostaria de aproveitar este tempo para ver as aplicações destes diferentes bancos para evitar ter que passar por processos de tentativa e erro ou grandes sessões de leitura para poder decidir qual banco utilizar para cada situação.

Confesso que me decepcionei com a apresentação. Ela se resumiu em apresentar as bases NoSQL e um pouco da arquitetura interna delas. Coisas que são relativamente fáceis de buscar na internet e que eu já tinha uma noção básica. No final das contas, o conteúdo apresentado não me fez saber melhor qual base utilizar em cada situação e não vi nenhuma aplicação do NoSQL, i.e. "aplicado" só no título do tutorial.

Mas, apesar de não satisfazer minhas expectativas, foi possível aproveitar um pouco do conteúdo do tutorial. O mais relevante para mim na verdade ficou como tarefa de casa: aprender ZooKeeper.

Short-talks

As apresentações curtas que assisti foram "Hadoop: Mãos à massa!", "Cassandra no Desenvolvimento de Serviços para Apps Mobile" e "Play, do zero ao deploy em 20 minutos". Mas estas tiveram o mesmo problema que ocorreu na edição de 2013 do evento: o tempo é curto de mais! Todos os apresentadores estouraram o tempo. Mesmo se não tivessem estourado, o conteúdo passado sempre é demasiadamente superficial.

Os palestrantes foram ótimos, todos os três. A de Hadoop utilizou humor, a de Cassandra trouxe um caso do mundo real e a do Play foi direta ao ponto. Mas são apresentações que só servem para despertar o interesse do ouvinte. Como eu já tinha visto da história de Hadoop no tutorial de NoSQL, foi meio repetitivo; a de Cassandra conseguiu ter mais "NoSQL Aplicado" do que o tutorial, mas como foi muito rápido só ficou como aprendizado: "é possível começar um serviço com base relacional e trocar por um NoSQL depois", que vai de encontro com o que escrevi no post passado sobre otimização precoce; a última que falou do Play Framework despertou um interesse muito saudável, vou procurar saber mais sobre ele por algumas propriedades dele que brilharam aos meus olhos, principalmente static checking.

Organização

Este ano o evento está muito melhor organizado. O evento está acontecendo no WTC SP que possui um espaço muito melhor do que o local do ano passado. O credenciamento foi bem tranquilo, apesar de que só recebi a credencial à tarde, mas porque a compra do dia de tutoriais foi feita em cima da hora (ontem). As pausas com café entre as apresentações também estão mais generosas e com uma distribuição melhor pelo local, em nenhum momento senti falta de suco, café, água e alimentação.

Comentários

Alguns pensamentos que passaram pela minha cabeça hoje durante o evento:

1. Com o crescimento de bases NoSQL e de BigData, o papel exclusivo de um administrador de banco de dados parece estar perdendo força. Juntando com a entrega contínua, em que todo mundo se responsabiliza por tudo, os desenvolvedores precisam pensar em como o dado será lido antes de armazená-lo, precisa entender da topologia de onde ficarão os dados e etc. Será que faz sentido ainda ter um papel exclusivo para isto?
2. Entrega contínua significa metodologia ágil. Não sei como colocar um processo cascata que faz entrega contínua. Já é difícil fazer com que todos se sintam responsáveis pelo produto em uma metodologia tradicional.
3. O número de apresentações sobre programação funcional cresceu do ano passado para cá. Mas não sei se todos estão preparados para esta mudança. Teve um tutorial exclusivo de Clojure este ano, gostaria de ter participado, mas a de entrega contínua pareceu mais fácil de "aplicar na vida real". Por mais que eu seja um entusiasta de Haskell e querer que a programação funcional se torne mainstream, parece que ainda há uma barreira natural para que isto aconteça. Ouvi comentários de que "programação orientada à funções era estranho". De certa forma não tiro razão destes comentários, ouvi que a apresentação de "Lambdas em Java" falou de estruturas persistentes e deu como exemplo a da estrutura de árvore, que é "modafoca" para entender. Acho que isto é uma falha dos entusiastas das linguagens funcionais: nós ficamos tão empolgados com as inúmeras "qualidades" deste modelo, que atravessamos tudo e tentamos passar todo conhecimento em uma única apresentação.

Otimização prematura: não é apenas sobre código

Quando falamos sobre desempenho, não devemos olhar apenas para desempenho da execução de código. Existem mais tipos que devemos prestar atenção, como tempo para mercado, tempo de desenvolvimento e processos. Na verdade, não devemos olhar qualquer uma destas medidas de desempenho de uma única perspectiva. Penso que todas estas medidas se unificam para constituir um único valor de desempenho de negócio.

Existem muitas coisas que podem desacelerar seu negócio, e se você tiver um negócio devagar, será difícil acompanhar o ritmo de seus concorrentes. A partir do momento que você vê que algumas áreas da sua empresa podem estar te atrasando, você pode sentir-se tentado a adicionar indicadores de desempenho em cada passo, tentando espremer todo valor possível de cada parte do seu processo. Isto pode trazer um monte de novos problemas, seu negócio pode ser visto como um sistema complexo e ele irá se adaptar para mostrar bons resultados mesmo em cenários caóticos. [1]

Então, para evitar ficar maluco com indicadores para todos os lados, você decide evitar gargalos desde o princípio. Para cada coisa nova que você precisa entregar, começará uma rotina de planejamento preciso, escolhendo entre uma infinidade de fornecedores, tecnologias e unicórnios para evitar a todo custo ter um novo gargalo no futuro. Isto é o que gosto de chamar de otimização prematura de desempenho de negócio.

De forma simples: você não pode ter um negócio se você não tiver um negócio. Como você pode saber de todos os eventos futuros que irão impactar na decisão que você toma hoje? Você não pode. Não estou dizendo que planejar é errado ou uma Coisa Ruim™. O que eu realmente quero é evitar perder energia em coisas que não farão a menor diferença. Você pode gastar um ano inteiro escolhendo entre maçãs e laranjas, e no final ser esmagado por algum maluco brincando com tecnologias esquisitas. Por quê? Porque ele não estava preocupado com gargalos futuros. Ele estava realmente tentando fazer algo legal, e ele fez isto enquanto você estava discutindo em intermináveis reuniões sem propósito.

Você sempre está escolhendo entre medidas de desempenho. Por exemplo, todo mundo está falando a respeito de arquitetura orientada a serviços (SOA), mas o que isso significa em termos de negócio? Significa uma troca entre desempenho de execução de código e outros benefícios para o negócio como um todo, como crescimento descentralizado e entrega contínua. Ou, você pode olhar nas diferenças entre os modelos da App Store da Apple e a Play Store do Google. Existe uma troca gigantesca entre garantia de qualidade e tempo de mercado entre estes dois jogadores: um oferece a seus clientes (donos de smartphones), aplicativos com qualidade assegurada; o outro oferece a seus clientes (usuários do sistema operacional), tempo para lançamento ao mercado acelerado para seus aplicativos.

A grande questão realmente é: o quê você está tentando entregar ao seu cliente? Você está tentando entregar software sobre tempo ou valor sobre tempo? Eu aposto que a maioria de vocês estão tentando entregar valor sobre tempo, então por quê se preocupar com otimização prematura de tecnologias ou processos? Deixe que as coisas ruins morram por si só: falhar rápido é dezenas de vezes melhor do que não fazer nada. E deixe que as coisas boas te acompanhem para onde você quer ir.

Não gaste seu tempo adivinhando o futuro, abrace a incerteza da vida: você não pode prever como um sistema complexo irá se comportar, você não pode saber como seus sistemas, serviços ou seja lá o que você esteja fazendo, irão se comportar no mundo real. Coloque eles para funcionar, receba as reclamações e ajuste o que for preciso (ou jogue tudo fora), isto é um processo constante. [2]

Comece a medir quanto você está entregando em determinado tempo e pare de planejar tanto. Seu objetivo final é entregar coisas. O mundo não poderia se importar menos com o que você consegue fazer, ele só se importa com o que você faz.

Referências

1. Complex Systems and Key Performance Indicators - Márcio Geovani Jasinski
2. Complaint-Driven Development - Jeff Atwood