MiniPlop 2013 em Brasília: Eu Fui!
No último final de semana de Setembro aconteceu na Capital Federal o MiniPlop. O evento ocorreu na Universidade de Brasília - Campus Gama, com a coordenação do editor chefe da revista MundoJ Eduardo Guerra e teve como principal tema a discussão sobre novos Design Patterns. A reunião contou com a presença de Joseph Yoder, um ativo participante na comunidade de padrões. Teve também a participação de um grande número de Universitários/Professores muito bem preparados, elevando o nível da discussão sobre tópicos nada triviais. Os artigos apresentados na mini conferência estão disponíveis para download.
Para entender o post, temos que definir: o que é o Design Pattern? Basicamente, é a documentação de uma solução para um problema comum. Ninguém inventa um novo padrão de projeto, ele emerge de discussões como essas, surgem de problemas que todos nós passamos no dia a dia. O padrão provavelmente está maduro quando olhamos para ele e pensamos: "Nossa, eu já passei por esse problema! Agora ele tem um nome!". A Caelum dedica atenção aos patterns no curso de laboratório Java, no curso online de Padrões de Projeto, e no livro do Eduardo Guerra. Também alertamos bastantepara os perigos de usar Design Patterns sem uma forte motivação.
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!