MiniPlop 2013 em Brasília: Eu Fui!

Começamos o evento com uma palestra sobre Open Source. A [ideia do Antonio Terceiro](http://cbsoft2013.unb.br/miniplop/ordem-no-caos-padroes-em-projetos-de-software-livre) era padronizar uma forma de contribuição nos projetos de código aberto. Ele tratou de um modo geral em como podemos contribuir desde fazendo traduções até mesmo implementando testes que ainda não existem. Incentivou também a plateia a fazer escolhas de projetos para contribuir baseado em features que o projeto apresenta, projetos que você já utiliza ou tecnologia empregada.
A partir daí a dinâmica do evento mudou. Ela consiste em debater sobre os papers apresentados. A parte interessante da brincadeira consiste no fato de que os autores não podem interferir na discussão. A ideia é justamente mostrar a eles o que as pessoas entenderam do que ele propuseram. Muitas vezes achamos que somos claro o suficiente ao expor nossas ideias e infelizmente, na maioria dos casos, isso não é verdade. Com essa dinâmica, há um feedback instântaneo e real sobre o padrão apresentado, o autor só tem a ganhar com isso. Participei de três discussões que envolveram os seguintes padrões: [Partial View State](http://cbsoft2013.unb.br/wp-content/uploads/2013/09/partial-view-um-padr%C3%A3o-para-reutilizacao-de-views-na-arquitetura-mvc.pdf), [Objetos Dublês](http://cbsoft2013.unb.br/wp-content/uploads/2013/09/um-padrao-de-projeto-para-dublar-dependencias-internas-em-testes-de-unidade.pdf) e [Build Paralelizado](http://cbsoft2013.unb.br/wp-content/uploads/2013/09/the-unix-like-build-pattern.pdf).
A primeira foi sobre Partial View State. Você já constatou que na criação de páginas web, muitas vezes seus conteúdos se repetem? Então, como devemos resolver? Aposto que já passaram por esse problema, por isso, o que pessoal do Ceará fez, foi documentar a solução e definir o padrão em uma forma simples, muito bem explicada e em várias linguagens. O principal feedback que demos aos autores foi melhorar o exemplo principal e salientar frameworks que já implementam esse padrão.
O segundo debate foi particularmente o que mais me interessei. Há [tempos](https://blog.caelum.com.br/facilitando-seus-testes-de-unidade-no-java-um-pouco-de-mockito/) nos [preocupamos](https://blog.caelum.com.br/melhorando-a-legibilidade-dos-seus-testes-com-o-hamcrest/) em [discorrer](https://blog.caelum.com.br/o-que-a-quantidade-de-asserts-em-um-teste-nos-diz-sobre-o-codigo/) sobre [Testes Automatizados](http://www.alura.com.br/cursos-online-agile/tdd), [principalmente](https://blog.caelum.com.br/testes-unitarios-com-jmock-2/) seu [impacto](https://blog.caelum.com.br/facilitando-a-manutencao-dos-testes-ao-diminuir-o-acoplamento-com-o-codigo/) sobre o [design](https://blog.caelum.com.br/perdendo-ou-ganhando-tempo-com-testes-de-unidade/) do [código](https://blog.caelum.com.br/tdd-e-sua-influencia-no-acoplamento-e-coesao/). A ideia do artigo é como lidar com [dependências](http://www.caelum.com.br/apostila-java-testes-jsf-web-services-design-patterns/testes-automatizados/) internas que não podem ser injetadas. A solução proposta é simples para um problema muito comum para quem lida com testes. E apesar te já termos falado muito sobre testes aqui na Caelum, nunca postamos nada sobre o assunto, por isso vale a pena ler o artigo. A principal qualidade do artigo foi realçar o trade-off da solução, mostrando que o autor está desapegado da sua proposta. Saber os trade-offs de uma solução talvez seja a principal qualidade de um [Arquiteto](https://blog.caelum.com.br/entao-voce-quer-ser-um-arquiteto-java/). Como feedback falamos que a implementação poderia ser melhorada e ele deveria citar outras ferramentas como o [PowerMock](https://code.google.com/p/powermock/), que resolve o problema de maneira diferente.
A terceira foi sobre [build](http://www.alura.com.br/cursos-online-java/maven) paralelizado de aplicações. Você está perdendo muito tempo para "[buildar](https://blog.caelum.com.br/processo-de-build-com-o-maven/)" sua aplicação? Já falamos muito sobre [integração contínua](https://blog.caelum.com.br/integracao-continua/), inclusive de builds no [front-end](https://blog.caelum.com.br/automacao-de-build-de-front-end-com-grunt-js/) e para constatar a necessidade do pattern, também já passamos por um problema parecido [no nosso build por causa dos testes de aceitação com Selenium.](https://blog.caelum.com.br/integracao-continua-builds-rapidos-com-grids-e-paralelismo/) A ideia do artigo é propor um padrão para paralelizar o seu build. Como principal feedback mencionamos ao ator a necessidade de se listar um trade-off, por exemplo, quando não vale a pena paralelizar o build?
Concluindo, fiquei impressionado com a qualidade dos artigos e dos estudantes que participaram do evento, a dinâmica de apresentação é muito mais interessante do que um palestrante com power point tentando transmitir ideias. É muito revigorante ver que pessoas tão jovens estão preocupadas com qualidade de código. Afinal, a principal vantagem de se usar Pattern é justamtente facilitar a manutebilidade de código e comunicação entre programadores.
Para quem participou do evento e comentar no post estará concorrendo a dois livros da Casa do Código, realizado daqui 2 semanas. O [Arquitetura Java](http://www.casadocodigo.com.br/products/livro-arquitetura-java) e o [Design Patterns](www.casadocodigo.com.br/products/livro-design-patterns). Os livros são uma cortesia da Caelum em conjunto com a [Casa do Código](http://www.casadocodigo.com.br) e os ganhadores serão avisados por e-mail. Comentem!