Meu nome é Paulo Caroli,estou na Thoughtworks a quatro anos. Estive na TW nos Estados Unidos, Índia e agora Brasil. Meu nome é Martin Fowler, também trabalho para a Thoughtworks e eu sou um boca grande, blogger, speaker, um grande "fanfarrão".
Existem dois pontos aqui. Quando as pessoas falam sobre programação poliglota em geral significa a utilização de mais de uma linguagem em um mesmo projeto. Frequentemente é uma "general purpose language", que fazemos o tempo inteiro de qualquer maneira.Mas as vezes podem ser "multiple purpose languages" que resolvem diversas partes de problemas.
Retomando o assunto de testes funcionais, um dos projetos que temos aqui no Brasil para um website importante.
O coração do sistema é feito todo em Java. Mas todos os testes são feitos em Ruby utilizando Selenium. O que acaba sendo uma maneira mais eficiente para criação de testes funcionais.
A idéia de programação poliglota é a de misturar linguagens distintas para objetivos distintos.O segundo ponto é se programadores devem aprender outras linguagens para se aperfeiçoarem. Eu sou a favor, a sugestão do Pragmatic Programmer de aprender uma linguagem nova a cada ano, que seja uma linguagem diferente: se você já sabe Java, aprender C# não conta.Não necessariamente uma linguagem que você espera utilizar no trabalho do dia a dia,mas uma que expanda seus horizontes, abra sua cabeça para novas possibilidades.
O que descobri quando no início do trabalho de consultoria,e as duas principais linguagens eram Smalltalk e C++.
Eu possuia grandes vantagens conhecendo ambas pois eu trazia idéias de Smalltalk para C++ e ocasionalmente algumas idéias úteis de C++ para Smalltalk. Conhecer as duas me dava uma boa visão e se tornou ainda mais valioso com a popularização do Java.
A resposta é algo que existe desde a primeira vez que falamos de extreme programming,é a criação de um processo de build (build pipeline), isto é, ter duas fases de build.
Dessa maneira você pode ter um conjunto de testes rápidos que rodam em menos de 10 minutos e fornecem um feedback rápido. Em geral esses testes possuem granularidade menor, unitários,com todas as depêndencias lentas como banco de dados simuladas através de stubs,você não vai rodá-los em geral pelo navegador.Com excessões possíveis, como javascript. Mas a maior parte não executará em um navegador.E então você tem os testes de aceitação que passam pelo banco de dados e utilizam o navegador em uma segunda fase.
E, sim, eles levarão mais tempo para rodar, minutos ou horas, mas o ciclo de commit é baseado no primeiro conjunto de testes. Eu gostaria de adicionar algo, uma coisa é o processo de build onde testes distintos rodam em fases distintas,e outra coisa é rodar os testes em paralelo, que antigamente era mais díficil de se fazer.
Para isso você terá que se preocupar com algumas coisas: não deixe os testes interdependentes, para que não haja necessidade de rodá-los sequencialmente.Depois você precisa de poder suficiente, máquinas suficientes para rodar
os testes em paralelo,e depois as ferramentas, você mencionou o Selenium, usamos o Selenium Grid.Enquanto os testes podem rodar em paralelo, use o selenium grid e pronto. Podemos usar até mesmo as ferramentas de configuração de processo de build, como o Go. O Go pode permite organizar e selecionar o que será rodado em paralelo.Essa é outra maneira de mesmo com muitos testes, quebrá-los para rodar em paralelo.
4. O que seria um período de tempo razoável para receber o feedback do build?
Para a fase de commit? Desejamos mantê-lo abaixo de 10 minutos, esse é o pensamento geral das equipes da Thoughtworks. Acredito que esse seja o tempo que você não deseja ultrapassar. Para fases seguintes do build, o processo pode demorar muito mais, dependendo de suas necessidades. Seguindo o que o Paulo comentou sobre paralelismo, um exemplo que demonstra o extremo disso é o Mingle. Ele usa javascript de uma maneira bem pesada, com dezenas de cartões e quadros virtuais sendo movidos de um lado para o outro. Esses testes devem rodar em cada combinação de sistema operacional e navegador que os usuários podem utilizar. Rodando em paralelo após o ciclo de commit, levam bastante tempo, mas grande parte do feedback é recebido cedo.
Eu não sei. O motivo do livro era descrever as técnicas de escrever DSLs para todos, para que se torne mais fácil escrevê-las. Essencialmente, acredito que as pessoas não utilizam pois não compreendem
direito a técnica.E a pergunta que surge é se a medida que elas se tornarem mais conhecidas e melhor compreendidas,será que isso levará a maior adoção de DSLs? Eu não sei.Mas tenho certeza que vale a pena tentar, particularmente com DSLs que podem ser lidas por pessoas de negócio,pois abrem um canal de comunicação muito valioso.
O processo de escrever um livro como esse é bem especulativo, não sabemos dizer o impacto que terá.É como quando escrevi o livro sobre refactoring, não fazia idéia do impacto que teria. Seria ótimo se fosse um livro com impacto, mas o máximo que podemos fazer é esperar.Caso contrário, bem, é assim que funciona o ramo.
Eu acredito sim que esse livro mudará a maneira de como fazemos software.Eu lembro da época que saiu o livro de design patterns da Gang of Four, nós já estávamos razoavelmente acostumados com aquilo mas não sabiamos um nome claro, não estava claro para todos que valia a pena prestar atenção. A primeira vez que vi DSLs e li as idéias do Fowler, percebi que isso era o que chamávamos de DSL interna, isso é o que chamamos de DSL externa. Isto que nós estávamos usando eram DSLs. Acredito que ficará mais claro para nós o que usamos, ao que devemos prestar atenção, e aquilo que ainda existe e não utilizamos. Portanto eu acredito que o impacto será importante.
Temos uma longa história no négocio de software, criando abordagens para sistemas distribuídos através de métodos ricos em barroquismo e demasiadamente complicados que soavam ideais na teoria mas nunca se mostraram assim na prática. E a web é um exemplo de algo que na teoria parecia ter idéias teoricamente péssimas mas funcionou extremamente bem na prática. E o interessante é se veremos o mesmo fluxo com REST.
Nós trabalhamos bastante com pessoas como Jim Webber e Ian Robinson, que são grande defensores de abordagens REST e possuem grande experiência em como lidar com toda essa questão de interoperabilidade.Eu certamente penso que os argumentos deles são bem convincentes. Nós caimos facilmente na armadilha de criar algo complicado e altamente acoplado. Acho que REST oferece uma abordagem interessante, diferente e acredito que vale a pena investir nele. Nós veremos se vai dar certo, nós nunca sabemos de antemão. Com certeza nosso sentimento, meu e de meus colegas, é que estamos muito mais inclinados a investir em REST e ver o resultado.
É muito bom saber disso. Como um desenvolvedor eu diria: deixe de lado o vendor, pense sobre quando terá que alterar código existente,o que será mais fácil para você?
Para entregar valor? Sim, aquele que entrega valor mais cedo.O mesmo hype aconteceu se você pensar em CORBA e EJBs."Idéias ótimas e muito legais" mas colocando na prática, trabalhando com código já existente, passamos a pensar: Eu gostaria que nada disso existisse. Eu gostaria que as coisas fossem mais simples.REST, novamente, nos mostra que existe uma maneira mais simples de fazer as coisas. Existem alguns desafios, claro, como entender o que significa criar uma API Restful boa, as pessoas ainda estão aprendendo como descrever o que constitui isso.
Mas estou muito mais inclinado a utilizar REST do que toda a pilha de especificações e software do WS-*.
O mais cedo e o mais frequente que puder. Você quer entrar em produção o mais rápido que puder, e atualizar o sistema o mais frequentemente possível. Claro que existe a pergunta, qual é o mínimo que devemos ter para entregar o produto? Claro que isso é um tradeoff, mas você com certeza quer entregar o mais cedo possível. Mesmo que você não possa, você quer criar código com qualidade ótima que poderia entrar em produção.E é nesse ponto que essa seja uma tarefa importante, pois é onde tradicionalmente o processo waterfall falhou, deixou para mais tarde coisas complicadas e difíceis de prever como processos de teste e integração no processo de desenvolvimento do projeto, quando causa o maior dano.É a última milha?Exatamente.
Um ponto importante: a palavra "cedo" não significa "de qualquer maneira". É cedo mas não é de qualquer jeito, é trabalho de qualidade.
Entregar o mais cedo possível, não simplesmente cedo? O mais cedo possível, mas sempre o máximo de qualidade. Na realidade, o Martin comentou sobre integração contínua, e a comunidade levou para o próximo nível, de entrega contínua. Isso permite automatizar esse processo onde as coisas movem de um ambiente para outro, através de processos automatizados que garantem a qualidade,permitimos enviar o produto para produção, se possível a cada dia ou até mesmo a cada hora. E uma grande inspiração para mim é a pessoa que cunhou o termo "integração contínua", Kent Back.
Depois que trabalhamos juntos no projeto da Chrysler e ele foi fazer outro trabalho na Suíça, em uma empresa de seguros. Isso nos anos 90, mas eles colocavam código pronto em produção todas as noites.
Claro, eles usavam um sistema muito sofisticado de desenvolvimento chamado Smalltalk,mais sofisticado do que aquilo que encontramos hoje em dia. Mas o ponto é que ele conseguiu um ciclo de entrega regular que funcionava perfeitamente para ele. Acredito que cada vez mais lugares podem se beneficiar disso, não somente a "garotada webbie", organizações também serão capazes de fazê-lo se aprenderem as técnicas que permitem isso.
Existem diversas maneiras para ajudar esse trabalho. Uma maneira é fazer a evolução em ciclos, primeiro alterando o espaço, e então usar esse espaço em outro ciclo. Dessa maneira é mais fácil de voltar atrás em cada um dos passos separadamente. Outra técnica é a chamada event sourcing, em que capturamos os eventos de entrada para que eles possam ser executados em diversas instâncias do banco. São técnicas que existem para contornar o problema, não é impossível, é algo que fizemos, e o blue-green é algo retirado de um projeto que fizemos em Londres alguns anos atrás.
E outro ponto importante é não esquecer de automatizar quase tudo que você possui, inclusive o botão de pânico. Se ao colocar algo em produção e não atender sua demanda como imaginava, você deve fazer o rollback.O rollback não deve ser um processo manual, deve ser um botão, um script automatizado.
Sim, nossos clientes fazem. Se pensarmos no deploy contínuo que acredito ser algo positivo, aqui temos diversos exemplos em que o processo de deploy de nossos clientes demorava meses, e em geral termina com um fim de semana estressante onde todos tentam colocar o sistema de pé para segunda de manhã. E levou mais alguns meses para automatizar pesadamente esses processos mas com o passar dos meses, alcançamos um ponto no qual ninguém precisa ficar no fim de semana. Isso não é algo que sempre foi confortável fazer, mas é algo que durante os anos conseguimos transformar em algo plausível.
Cada vez estamos falando mais sobre entrega contínua como o livro do Paul Duvall, Matyas e Glover que fala sobre técnicas em torno de entrega contínua. Esse também foi o que guiou o Cruise Go, nossa ferramenta comercial,ele começou com integração contínua em ~2001 com o Cruise Control, que focava na integração contínua, mas precisávamos levar adiante, para o processo de deploy. E agora temos diversas ferramentas que atacam isso. Elas não facilitam o processo de deploy contínuo, você precisa de um conjunto de características diferente. Isso nos guiou para o Cruise Go, que tivemos que criar para nossos clientes e pensamos: podemos fazer um produto aqui.
Então através de idéias como as do livro, ferramentas e práticas que fazemos em nossos projetos, estamos melhorando o ciclo continuamente. Existem outros tópicos que você encontrará no Anthology mas esse em particular me chama a atenção.
Falando sobre o livro, dois pontos, primeiro ele não é sobre como pensamos que se deve criar software, mas sim sobre o que fizemos em nossos clientes e julgamos interessante para compartilhar.
Por isso existe muita informação interessante: é algo que usamos no mundo real. É um livro muito bom.
Outro ponto importante é que um novo livro sairá em breve, novamente, um grupo de Thoughtworkers escrevendo sobre práticas que acreditam ser importantes e sairá mais um livro. Ainda está no início, não sei o quão cedo, mas está no processo de criação.
Você deve saber melhor.
Sim, sim, sempre leva muito tempo.
10. Gostaria de agradecer aos dois, Paulo e Martin. Espero vê-los mais vezes aqui no Brasil.
Será um prazer voltar. Obrigado.