Software Developers Retreat (dia 2)

O segundo dia do nosso retiro de desenvolvedores acabou!

Trabalhando Juntos

Trabalhando Juntos

Acordamos lá pelas 8 e meia, 9 horas. Também teve gente que acordou mais cedo para fazer um cooper. Como de costume, fizemos nosso Standup Meeting as 11h da manhã. Recebemos a visita do nosso diretor de produtos. Ele veio de São Paulo para cá, passar o dia com a gente. Foi muito importante sua vinda, pois pudemos conversar em mais detalhes sobre algumas histórias que estávamos implementando.
Continue reading

Software Developers Retreat (dia 0)

Já faz alguns meses que eu estou planejando esse evento, que finalmente tomou forma e terá início a partir de amanhã, dia 26/nov/2012.

A ideia não é nova, embora eu tenha visto poucas organizações, empresas ou pessoas executando ela de fato. Tudo surgiu de uma conversa com meu grande amigo Alexandre Freire, que já tinha vivido a experiência de levar programadores para a sua casa no bonete na Ilhabela em São Paulo. A aventura dele está documentada no blog do estúdio livre.
Continue reading

MiniPLoP Brasil 2011

MiniPLoP

MiniPLoP 2011

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.
Continue reading

Technology Glossary

Here’s a small table of many terms I’ll have to be used to in my PhD program, which starts on the next month. It’s just a small part of hundreds of abbreviations we software developers have to deal with on our daily work. Please comment down if you have suggestions to add to this table. I’m sure every person can add at least 30 itens to this table:

a.k.a. Also known as
API Application Programming Interface

Continue reading

DDD – Introdução a Domain Driven Design

Domain Driven Design significa Projeto Orientado a Domínio. Ele veio do título do livro escrito por Eric Evans, dono da DomainLanguage,  uma empresa especializada em treinamento e consultoria para desenvolvimento de software. O livro de Evans é um grande catálogo de Padrões, baseados em experiências do autor ao longo de mais de 20 anos desenvolvendo software utilizando técnicas de Orientação a Objetos. O que seria um Padrão?

Um padrão é uma regra de três partes que expressa a relação entre um contexto (1), um problema (2) e uma solução (3).

DDD pode ser visto por alguns como a volta da orientação a objetos. É verdade que o livro é um chamado às boas práticas de programação que já existem desde a época remota do SmallTalk. Quando se fala em Orientação a Objetos pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas a essência da Orientação a Objetos também tem coisas como:

  • Alinhamento do código com o negócio: o contato dos desenvolvedores com os especialistas do domínio é algo essencial quando se faz DDD (o pessoal de métodos ágeis já sabe disso faz tempo);
  • Favorecer reutilização: os blocos de construção, que veremos adiante, facilitam aproveitar um mesmo conceito de domínio ou um mesmo código em vários lugares;
  • Mínimo de acoplamento: Com um modelo bem feito, organizado, as várias partes de um sistema interagem sem que haja muita dependência entre módulos ou classes de objetos de conceitos distintos;
  • Independência da Tecnologia: DDD não foca em tecnologia, mas sim em entender as regras de negócio e como elas devem estar refletidas no código e no modelo de domínio. Não que a tecnologia usada não seja importante, mas essa não é uma preocupação de DDD.

Todas essas coisas são bem exemplificadas e mostradas na forma de vários padrões em DDD. Mas o livro também mostra muitos padrões que não dizem respeito a código ou modelagem. Aparecem coisas que estão mais ligadas a processos (como Integração Contínua) ou a formas de relacionamento entre times que fazem parte do desenvolvimento de um sistema complexo. Eric Evans dividiu o livro em quatro partes, que apresentaremos a seguir.

Continue reading