O evento começou com a apresentação “Como Agile tem transformado a área de TI” de Paulo Caroli e Rodrigo Toledo e em seguida, Mr. Fowler fez o que ele chamou de Suite of Talks e falou sobre três assuntos, separados em três mini-palestras. A seguir falo um pouco de cada um dos três assuntos.

1) Domain Specific Languages (DSLs)

O auditório em silêncio ouviu Martin Fowler falar que DSLs são basicamente linguagens de expressividade limitada ao domínio do problema em que se propõe a resolver.

E que o fator importante que torna as DSLs diferentes de linguagens “normais” é que elas são feitas com foco na leitura e não na escrita. Escrever DSLs tem a ver com tornar o código em uma linguagem limpa e clara que explique facilmente o domínio ao desenvolvedor.

Linguagens de programação normais, ainda que codificadas de forma simples e clara, falham em ensinar ao desenvolvedor sobre o domínio. Além disto, linguagens como o Java, não permitem alterações de comportamento em runtime, o que facilita muito na hora de entender o comportamento do domínio.

Mr. Fowler deu um exemplo de DSL em XML que permite alteração em runtime, sem precisar recompilar o código, mas o exemplo era muito verboso e este é o problema do XML.

Ele também mostrou um exemplo em uma linguagem que foi logo reconhecida por alguns do auditório que gritaram: Ruby! Com certeza este exemplo foi o mais expressivo de todos. (Alguém tem fotos dos exemplos?)

Ainda falando sobre expressividade de códigos, Mr. Fowler  mostrou um exemplo com Expressões Regulares e soltou a bomba:

“Toda vez que você tenta resolver um problema com expressões regulares, você acaba arrumando dois problemas.”

Martin Fowler terminou a palestra falando do seu livro “Domain Specific Languages” que será lançado em Setembro deste ano.

2) Richardson Maturity Model

Mr. Fowler falou sobre o modelo criado por Leonard Richardson que mostra os três passos necessários para se alcançar a excelência em implementações de web services REST.

Esta palestra teve o mesmo conteúdo que o artigo “Richardson Maturity Model: steps toward the glory of REST” escrito por Martin Fowler. Por este motivo, não vejo a necessidade de falar mais sobre o assunto.

3) Continuous Integration e Continuous Delivery

Já esta mini-palestra foi dividida em duas:

3.1 Continuous Integration

Martin Fowler falou rapidamente sobre o assunto dando o exemplo de dois desenvolvedores criando duas funcionalidades distintas, cada um trabalhando em uma linha separada e adicionando as funcionalidades a linha principal assim que terminavam.

O exemplo foi sendo incrementado com situações que iam sempre complicando a vida dos dois desenvolvedores até que eles precisaram usar Continuous Integration.

E os detalhes sobre o assunto, estão no livro Continuous Integration: Improving Software Quality and Reducing Risk de Paul M. Duvall. Um livro da série de assinaturas de Martin Fowler.

Ele ainda ressaltou que se o time desenvolve em linhas de desenvolvimento separadas, é imprescindível que cada desenvolvedor integre seu código a linha principal pelo menos uma vez por dia.

3.2 Continuous Delivery

Ele falou sobre como era demorado para os desenvolvedores verem seus códigos subindo para produção e como era trabalhoso dar suporte a estas subidas.

Madrugadas em claro, semanas estressantes. Toda essa dificuldade foi simplificada com o Continuous Delivery, que é um passo adiante do Continuous Integration.

Ele falou de como colegas dele na ThoughtWorks estão utilizando o processo automático que roda testes desde unitários até de performance e caso todos os testes passem, o código sobe para produção.

Os detalhes sobre Continuous Delivery estão no livro Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation de Jez Humble. Sim, mais um livro da série de assinaturas de Martin Fowler.

4) Perguntas

Um fato interessante: não houve perguntas sobre Continuous Integration, nem sobre Continuous Delivery e nem sobre Richardson Maturity Model. As pessoas estavam mesmo interessadas em DSLs e – acredite – em Domain-driven Design.

Martin Fowler fechou a sessão de perguntas com uma piada depois que um professor da PUC o perguntou se ele voaria num avião construído com metodologia ágil:

“Uma vez, numa conferência de desenvolvimento de software com vários professores, alguém os perguntou se eles voariam em aviões criados pelos seus alunos. Todos riram e afirmaram que com certeza voariam em aviões criados por seus alunos. Mas um professor foi bem firme em sua resposta:

- Eu não voaria de jeito algum! Sabem por que!? Porque com certeza nenhum código dos meus alunos faria um avião decolar!”

Há um tempo atrás, eu até conseguia resolver o problema criando um campo de upload escondido e invocando seu click – o que fazia janela de seleção de arquivos aparecer – via Javascript, mas esta solução foi logo vetada pelos browsers por questões de segurança – até mesmo no IE – e aí ficamos sem uploads elegantes novamente por alguns anos.

Foi então que eu vi pela primeira vez um botão de upload simples e elegante no Flickr e, depois de um tempo, no Orkut e comecei uma caçada por algo similar. Nesta procura, eu encontrei o SWFUpload, um componente Javascript que usa Flash para fazer campos de upload simples, elegantes e customizáveis.

SWFUpload é simples de usar, a documentação é bem explicativa e existe uma página de exemplos que com certeza terá uma implementação parecida com a que você está procurando.

O experimento é mais ou menos o seguinte: imagine um gato dentro de uma caixa fechada com alguma substancia radioativa, onde há 50% de chances desta substancia infectar o gato. Se isso acontecer o gato morrerá, se não ele ficará bem. Então, neste momento o gato está vivo ou morto? Segundo Schrödinger, a resposta correta é ambos. As duas possibilidades acontecem em universos paralelos, em um universo o gato morre e no outro ele vive. Apenas precisamos abrir a caixa para descobrirmos em qual universo nós estamos.

No seriado, o personagem mencionou o experimento para persuadir uma garota que estava na duvida ser deveria sair com ele ou não. Bom, ela só saberá se vale a pena se ela abrir a caixa.

No PragProg, os autores mencionam o experimento fazendo um comparativo com evolução do código em desenvolvimento de softwares:

Think of code evolution along the same lines as a box full of Schrödinger’s cats: every decision results in a different version of the future. How many possible futures can your code support? Which ones are more likely? How hard will it be to support them when the time comes?

O livro questiona o quão flexível à mudanças é o seu software e ressalta a importância de ser ter arquiteturas que suportem mudanças sem grandes custos.

Certa vez, eu vi um projeto ter que ser praticamente todo reescrito quando chegou a hora de criar o módulo que seria usado no Palm. Muitas decisões que foram tomadas no início do projeto não levaram em conta este futuro. Em conseqüência disso, houve um re-trabalho enorme, gerou um estresse gigantesco e exigiu bastante esforço da equipe que virou noites e finais de semana para que tudo fosse entregue no prazo.

O quão flexivel à mudanças é o seu software?

Um automóvel foi deixado em um bairro de classe alta na Califórnia. Na primeira semana, o carro não foi danificado. Os pesquisadores então quebraram uma das janelas. Poucas horas depois, o carro foi completamente destroçado e roubado por grupos vândalos.

Eu já pude acompanhar este fenômeno duas vezes. Na primeira vez foi um ciclo bem parecido com o experimento original, mas não foi proposital: Eu era criança e morava num prédio onde o irmão de um morador deixou seu carro estacionado. O carro estava bem sujo e meio amassado em algumas partes. Em pouco tempo, este carro virou o assento padrão de todas as crianças do prédio, depois já estava sem as janelas e então mais tarde, dois indivíduos – que não eram crianças – roubaram a bateria do carro. O caso foi sério, no final deu uma grande confusão e os caras que roubaram a bateria acabaram levando a culpa de tudo. Posso apostar que se o carro estivesse em, não vou nem dizer perfeitas, mas em condições normais, assim como todos os carros que estavam na garagem do prédio, isso não teria acontecido.

Na segunda vez que eu vi este fenômeno, ele não chegou a causar muitos estragos. E o que nos poupou de estragos maiores foi o fato das pessoas terem enxergado que tínhamos uma “Janela Quebrada”. Eu falei aqui no blog sobre o Mau Copiador, o cara que senta pra desenvolver o sistema sem saber o que está fazendo e vai copiando o código dos sites, dos outros sistemas da empresa, de todo mundo e de qualquer maneira. Pois é, ele era uma janela quebrada e estava lá na empresa para fazer com que todo um sistema, ou até a empresa inteira fosse por água abaixo, ou melhor, por janela abaixo (com trocadilho).

Acontece que esse cara não era mau em se auto promover para as pessoas que não viam o código que ele gerava e com isso ele acabou ganhando a tarefa de treinar os estagiários que entraram no projeto. E aí não foram só janelas quebradas, foram portas, mesas, cadeiras e tudo mais que viam pela frente até que os gerentes foram alertados e medidas foram tomadas.

Não posso dizer que não houve estragos, eu perdi algumas boas horas corrigindo “cópias mal feitas em larga escala” no sistema, mas nada que um bom Refactoring – e eu gosto de refactoring – não resolvesse.

O Guilherme Silveira apontou o cuidado para não deixar janelas quebradas no sistema como um dos hábitos que os arquitetos de softwares altamente eficazes devem ter.

Na empresa onde trabalho, uma empresa de três letrinhas, tentamos implantar DDD em um projeto, mas é difícil fazer isso já que quem tem contato com o cliente não somos nós, os desenvolvedores. O que chega para nós já é a “solução de todos os problemas” que o analista de sistemas criou enquanto conversava com o cliente. Na verdade, a nossa linguagem ubíqua não é feita entre o cliente e nós, mas sim entre nós e o analista.

Eu não acho certo dizer que o sistema está usando DDD também, e achei muito interessante o artigo do Phillip, porque eu estava pensando exatemte nisso outro dia deste. Inclusive, na apresentação de DDD que o Sérgio Lopes fez no Falando em Java 2008, foi a primeira coisa que ele demonstrou: a criação de uma línguagem que fosse clara para o cliente e para o desenvolvedor.

Se você for copiar um código, pelo menos, veja se o que você está copiando se aplica ao problema que você quer resolver e, é claro, adéqüe tudo que está copiando ao seu contexto. Caso contrário você estará sendo um… eh… mau copiador, não podendo nem se dar ao luxo de ser chamado de desenvolvedor.

É claro que erros todo nós cometemos, mas também tem aquela velha história:

Errar é humano, persistir no erro é burrice.

Concluindo, prestar muita atenção antes de copiar um padrão, um trecho de código ou qualquer outra coisa. Porque você poderá passar por situações delicadas e até ser considerado uma piada dentro da empresa, se copiar coisas sem saber o que está fazendo.

Isso é uma coisa que eu penso há muito tempo e como eu havia lido o artigo roadmap: html e css doThiago Senna há um tempinho atrás, decidi postar aqui para tentar disseminar a idéia.

O que eu tenho visto é muita gente preocupada em aprender inúmeras frameworks, mas ninguém dá a devida atenção que HTML, CSS e Javascript merecem. E com isso acaba acontecendo o que eu vejo muito nos projetos que eu participo: tabelas dentro de tabelas, deixando as páginas muito mais pesadas e difícil de entender e dar manutenção.

Então, para quem deseja ingressar na carreira de desenvolvedor web, aprender HTML, CSS e Javascript é obrigatório.

Um bom site com tutoriais e referências completas é o W3 Schools, que fica como dica.

Abraço!

A dica que mais chamou minha atenção na época que conheci o site e que realmente impressionou meus amigos e clientes foi a “Edit-in-Place with AJAX”. Esta dica foi muito útil para editar pequenos dados diretamente numa listagem, agilizando o trabalho dos clientes.