Software Developers Retreat (dia 3)

O terceiro dia do nosso retiro de desenvolvedores acabou!

Standup Meeting

Standup Meeting

O sol estava brilhando e bateu forte na nossa janela. Como o pessoal tinha ido dormir um pouco mais tarde, também acabamos acordando um pouco mais tarde. Como de costume, fizemos nosso standup meeting as 11h. A moça que contratamos para limpar a casa e cozinhar não veio nesse dia. Acabamos tendo que dar um jeito com as tarefas da casa. Continue reading

PLoP – A conferência de padrões

PLoP Portland História

Em agosto de 1993, Kent Beck e Grady Booch patrocinaram um retiro na montanha, onde um grupo de pessoas chegou a um consenso sobre os fundamentos em padrões de software. Ward Cunningham, Ralph Johnson, Ken Auer, Hal Hildebrand, Grady Booch, Kent Beck e Jim Coplien se basearam fortemente nas ideias de Alexander e suas próprias experiências, formando um casamento entre objetos e padrões. O grupo concordou que estávamos prontos para construir, sobre as fundações do trabalho de Erich Gamma sobre padrões orientados a objetos, e usar esses padrões da mesma forma que Christopher Alexander usa seus padrões para planejamento urbano e construções arquitetônicas. O encontro do grupo se deu ao lado (side) de um monte (hill), daí o nome Hillside.

Continue reading

SPLASH (antiga OOPSLA)

OOPSLA

Em 1985, um grupo de 4 pioneiros em programação orientada a objetos decidiu organizar nos EUA uma conferência sobre programação de sistemas orientados a objetos. No grupo estavam Adele Goldberg, Tom Love, David Smith, and Allen Wirfs-Brock, e a conferência foi chamada de OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications). A primeira OOPSLA aconteceu no Hotel Marriott, em Portland, Oregon, em novembro de 1986. Cerca de 600 pessoas participaram, 50 artigos foram apresentados e os participantes ouviram sobre Smalltalk, Lisp, Flavors, CommonLoops, Emerald, Trellis/Owl, Mach, Prolog, ABCL/1, prototypes, e programação concorrente e distribuída de pessoas como Danny Bobrow, Gregor Kiczales, Rick Rashid, Andrew Black, Dave Ungar, Henry Lieberman, Ralph Johnson, Dan Ingalls, Ward Cunningham, Kent Beck, Ivar Jacobson e Bertrand Meyer.

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

Arte e Ciência da Computação – de volta aos primórdios

Muitas pessoas me perguntaram qual foi o resultado da minha defesa de mestrado e
qual avaliação que a banca fez. Nós tínhamos uma câmera filmando a defesa, mas a fita acabou (#fail) justamente um pouco depois de a banca começar a argumentar sobre a dissertação. Somente as pessoas que estavam presentes tiveram o privilégio de saber qual foi o impacto que essa defesa teve no Instituto de Matemática e Estatística da USP. Digo isso não para me gabar do meu trabalho, mas porque o fato foi realmente EMOCIONANTE e, sem brincadeira, teve gente que até chorou!

Continue reading