AgileAndArt

Acabei de voltar de uma exposição lindíssima que está acontecendo no SESC Vila Mariana em São Paulo. O nome é “Pedaços da Terra“. Vale muito a pena dar uma conferida! Parece que ela foi feita especialmente (mas não somente) para um público como nós, Geeks, que temos tecnologia correndo nas veias. Vocês vão se surpreender com o que verão lá.

Exposição com cunho lúdico-didático que proporcionará o estímulo à consciência crítica em relação às práticas de sustentabilidade com um foco específico sobre o reino mineral, com vistas à preservação do meio ambiente e dos recursos naturais. Através de informações e conceitos relativos ao impacto ambiental da extração de recursos minerais para a elaboração de equipamentos tecnológicos eletro-eletrônicos, Pedaços da Terra pretende aproximar o público do processo de manufatura desses equipamentos, que envolve um ciclo de produção desde a extração do minério até o produto final. Desse modo, este projeto pretende fornecer informações e conceitos sobre a importância do consumo consciente (+ qualidade / – quantidade), a reutilização de equipamentos tecnológicos e o encaminhamento para reciclagem, tendo como objetivo minimizar os impactos ambientais.

No módulo Retrato do Planeta, uma tabela periódica interativa destaca os elementos químicos que compõem os equipamentos eletrônicos. Nos mosaico de matérias primas, curiosidades da geologia e dos minérios. Ainda neste módulo, mapas gigantes ilustram para o público as principais fontes de riquezas minerais e a exploração delas pelo mercado tecnológico.

Fiz um vídeo convite de 6 minutos, dando uma palhinha do que vocês verão lá. Confiram!

Nesse vídeo eu mostro as principais vantagens do uso de Injeção de Dependência e Testes com Dublês (Stubs, Mocks, Fake Objects, Spy, Dummy Objects).

Vídeo

Slides

Transcrição

Injeção de Dependência e Testes com Dublês

1. Conteúdo• Exemplo• Injeção de Dependência (DI)• Testes com Dublês (Doubles)
2. Exemplo
3. Continuando o Exemplo• Criando interface
4. Dependência• PhoneLister depende da interface e da implementação• Como depender somente da interface?
5. Idéia Básica – Injeção Injeção Framework Injeção de Dependência
6. Tipos de Injeção• Injeção Por Construtor
7. XML
8. Usando na aplicação
9. Fábrica de Objetos• Singleton – Instância única compartilhada do objeto – Uso padrão, mais comum – Objetos de serviço sem estado (stateless)• Protótipos – Cada chamada cria um novo objeto• Escopos de Objetos Customizados – Objetos armazenados fora do controle do container (ex: request, session em uma aplicação Web)
10. Fábrica de Objetos
11. Vantagens de usar Injeção de Dependência• Ajuda a escrever código que é fácil de testar: é só criar objetos e atribuir as propriedades desejadas usando os setters• Facilita boas práticas de programação: uso de interfaces no lugar de classes• Não envasivo: o código do sistema depende o mínimo possível da API do Framework• Dependências são explícitas e evidentes• Como os componentes não precisam procurar colaboradores em tempo de execução, o código fica mais fácil de escrever e manter
12. Frameworks para todas as linguagens• Java – Spring, PicoContainer, HiveMind• PHP – DIContainer• .NET – Spring.NET, PicoContainer.NET• Python – PyContainer, Spring Python• Ruby – Needle• Perl – IOC Module• Flex – Flicc• mais em http://en.wikipedia.org/wiki/Dependency_injection
13. DI – Linha do Tempo
14. Construtor ou Setter?• Construtor com parâmetros deixa claro o que é preciso para criar o objeto• Usando construtor evita campos imutáveis de serem alterados• Cuidado: construtores com muitos parâmetros podem ser um indicativo de objeto com responsabilidades demais• Construtor é ruim se tiver parâmetros simples como Strings: com setter você cria um método que identifica o que a string significa• Receita geral: comece com construtor e mude para setter se a coisa ficar complicada demais
15. Testes com Dublês (Doubles) DoubleDummy Stub Spy Mock FakeObject
16. Dummy Object• Objetos que nunca são usados, só servem para preencher parâmetros
17. Stub• Provê alguns dados estáticos que serão usados nos testes• Não funciona para outras coisas além do que está no teste
18. Spy• Muito parecido com Stub, mas com a diferença de que “grava” algumas coisas
19. O que são Mock Objects? Years later, Mock objects are still quite controversial, often misused and sometimes misunderstood. “Pintside Thoughts: Mock Objects History” —Tim McKinnon
20. O que são Mock Objects?• Cada pessoa entende de um jeito diferente• Terminologia ambígua• Ficou famoso inicialmente na comunidade JAVA & TDD Comportamento Estado testa interação entre testa o resultado dessas objetos interações
21. Código Mock
22. Fake Object• Têm uma implementação completa, mas simples• Não vai para produção• Exemplo: banco de dados em memória 23
23. Mocks nas Linguagens• Java – EasyMock, JMock, Mockito• Ruby – Mocha, RSpec?• .NET – NMock, Rhino Mocks• Perl – Test::MockObjects• C++ – Google Mocks• PHP – Simple Test for PHP
24. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Preenche parâmetros
25. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Preenche dados para parâmetros os testes
26. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Preenche dados para dados eparâmetros os testes grava
27. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Preenche dados para dados e comporta-parâmetros os testes grava mentos
28. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Implemen- Preenche dados para dados e comporta- taçãoparâmetros os testes grava mentos +simples
29. QuizDublês + Injeção de Dependência = Testes
30. Referências
    http://www.springframework.org/documentation
    http://martinfowler.com/articles/injection.html
    http://martinfowler.com/articles/mocksArentStubs.html
    http://xunitpatterns.com/
    Anil Hemrajani, Agile Java Development with Spring, Hibernate and Eclipse

Software developers have long observed that certain patterns recur and endure across different applications and systems. The growing interest in Design Patterns, Architectural Patterns, Analysis Patterns, Pedagogical Patterns, and so on, represents an effort to catalog and better communicate knowledge, providing handbooks of proven solutions to common problems.

MiniPLoP brings together researchers, educators, and practitioners whose interests span a remarkably broad range of topics and who share an interest in exploring the power of the pattern form. MiniPLoP invites you to add your expertise to the growing corpus of patterns. MiniPLoP focuses on improving the expression of patterns. You will have the opportunity to refine and extend your patterns with the help from knowledgeable and sympathetic fellow pattern enthusiasts. You will also be able to discuss applications of patterns in industry and academia.

Highlights of the conference include an international tutorial, an introduction to pattern writing, an international keynote, and the writer’s workshops.

This version of MiniPLoP has the goal to encourage the beginners in the pattern world and to put together the Latin-american pattern community. The MiniPLoP program will accept submissions for the Writers’ Workshop (WW) track. The papers should document patterns and pattern languages and they will be workshopped in the traditional PLoP format.

Visit the event website

General Chairs

Eduardo Martins Guerra (ITA, Brasil)

Fabio Kon (IME/USP, Brasil)

Program Co-chairs

Claudio Sant’Anna (UFBA, Brasil)

Joseph W. Yoder (U. Illinois/The Refactory, Inc, USA)

Local Organization

Allan Machado da Silva (ITA, Brasil)

Carlos Eduardo Moreira dos Santos (IME/USP, Brasil)

Daniel Cukier (IME/USP, Brasil)

José Roberto Campos Perillo (ITA, Brasil)

Jefferson de Oliveira Silva (ITA, Brasil)

Program Committee

Ademar Aguiar (INESC Porto/University of Porto, Portugal)

Brian Foote (Industrial Logic, Inc, USA)

Eduardo Guerra (ITA, Brazil)

Filipe Correia (Porto University, Portugal)

Gustavo H. Rossi (Lifia/UNLP, Argentina)

Hugo Sereno Ferreira (INESC Porto/University of Porto, Portugal)

Jerffeson Teixeira de Souza (UECE, Brazil)

Linda Rising (Independent Consultant, USA)

Lise Hvatum (Schlumberger, USA)

Tiago Massoni (DSC/UFCG, Brazil)

Rebecca Wirfs-Brock (Wirfs-Brock Associates, USA)

Richard Gabriel (IBM Research, USA)

Roberta Coelho (DIMAp/UFRN, Brazil)

Rohit Gueyi (DSC/UFCG, Brazil)

Rosana Braga (ICMC/USP, Brazil)

Rossana Andrade (DC/UFC, Brazil)

Sergio Soares (CIn/UFPE, Brazil)

Uirá Kulesza (DIMAP/UFRN, Brazil)

Additional Shepherds

Daniel Cukier (IME/USP, Brasil)

Jefferson de Oliveira Silva (ITA, Brasil)

Tarciane Andrade (UECE, Brasil)

 
Utilizando a Linguagem Ubíqua criamos um modelo de domínio através do Projeto Dirigido pelo Modelo (Model Driven Design – MDD). A idéia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio. Tudo que existe no seu negócio deve aparecer no modelo. Só aparece no modelo aquilo que está no negócio.

Em um time que cria software temos de um lado os especialistas de negócio e de outro os desenvolvedores e arquitetos. Num processo ágil defendido pelo MDD a criação do modelo abstrato deve ser feita em grupo, com todas as pessoas juntas. Se arquitetos e analistas de negócio criarem o modelo sem a participação dos programadores, corre-se o risco de criar um modelo que não é implementável ou que usará uma tecnologia inadequada. Da mesma forma, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio. Em DDD, parte das pessoas que modelam o domínio são necessariamente pessoas que colocam a mão em código (Hands-on Modelers). Se os programadores não se sentirem responsáveis pelo modelo ou não entenderem como o modelo funciona, então o modelo não terá relação alguma com o software produzido por essas pessoas.

O processo de maturação de um sistema desenvolvido usando MDD deve ser contínuo. O modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. O contato contínuo com o código trará insights aos programadores, que irão refatorar o código. Essa refatoração deverá ser feita não só no código, mas também no próprio modelo.

Há seis meses, decidi me embrenhar no mundo acadêmico e iniciar um longo período (de no mínimo 3 anos) de doutorado. Desde então, várias pessoas me perguntam “Como está indo?”, “Está gostando?” e, principalmente, “O que é doutorado? (também conhecido como PhD)”. Eu ainda não tenho uma resposta clara para essas perguntas, mas tenho certeza que quando estiver mais maduro, farei um post sério sobre isso aqui no meu blog. Por hora, vou deixar um texto que eu recebi em uma das aulas, que me parece ser [no momento] a definição mais apropriada para doutorado. É uma brincadeira, mas que tem um certo fundo de verdade…

 

SABEDORIA POPULAR

Rapadura é doce, mas não é mole, não!!!

ENSINO FUNDAMENTAL

Açúcar mascavo em tijolinhos tem o sabor adocicado, mas não é macio ou flexível.

ENSINO MÉDIO

Açúcar não refinado, sob a forma de pequenos blocos, tem o sabor agradável do mel, porém não muda de forma quando pressionado.

GRADUAÇÃO

O açúcar, quando ainda não submetido à refinação e, apresentando-se em blocos sólidos de pequenas dimensões e forma tronco-piramidal, tem sabor deleitável da secreção alimentar das abelhas; todavia não muda suas proporções quando sujeito à compressão.

MESTRADO

A sacarose extraída da cana de açúcar, que ainda não tenha passado pelo processo de purificação e refino, apresentando-se sob a forma de pequenos sólidos tronco-piramidais de base retangular, impressiona agradavelmente o paladar, lembrando a sensação provocada pela mesma sacarose produzida pelas abelhas em um peculiar líquido espesso e nutritivo. Entretanto, não altera suas dimensões lineares ou suas proporções quando submetida a uma tensão axial em consequência da aplicação de compressões equivalentes e opostas.

DOUTORADO

O dissacarídeo de fórmula C12H22O11, obtido através da fervura e da evaporação de H2O do líquido resultante da prensagem do caule da gramínea Saccharus officinarum Linneu, 1758, isento de qualquer outro tipo de processamento suplementar que elimine suas impurezas, quando apresentado sob a forma geométrica de sólidos de reduzidas dimensões e arestas retilíneas, configurando pirâmides truncadas de base oblonga e pequena altura, uma vez submetido a um toque no órgão do paladar de quem se disponha a um teste organoléptico, impressiona favoravelmente as papilas gustativas, sugerindo impressão sensorial equivalente provocada pelo mesmo dissacarídeo em estado bruto, que ocorre no líquido nutritivo da alta viscosidade, produzindo nos órgãos especiais existentes na Apis mellifera, Linneu, 1758. No entanto, é possível comprovar experimentalmente que esse dissacarídeo, no estado físico-químico descrito e apresentado sob aquela forma geométrica, apresenta considerável resistência a modificar apreciavelmente suas dimensões quando submetido a tensões mecânicas de compressão ao longo do seu eixo em consequência da pequena capacidade de deformação que lhe é peculiar.

 

 

 

It was a great event and I’m very happy to be part of it. QCON was awesome! I hope you enjoy the pictures