Dojo Ojod (ou Scrapheap Challenge)

No mês passado participamos de uma atividade promovida pela ThoghtWorks Brasil em Porto Alegre e organizada pelo Carlos Villela (CV). Eles aproveitaram a ocasião do FISL12 para organizar esse pequeno evento no confortável escritório que fica dentro do campus da PUC-RS. Foi pequeno em relação ao número de participantes (acho que éramos em uns 30), mas enorme em divertimento e aprendizado.

A brincadeira era uma espécie de Dojo, com regras um pouco exóticas. A ideia original foi do Nat Pryce e do Ivan Moore, e eles chamaram de Scrapheap Challenge, por causa do programa de TV, mas eu resolvi re-batizar para Dojo Ojod (um palíndromo de Dojo ao contrário), pois foi exatamente assim que o CV definiu (e que eu concordo muitíssimo): um Dojo ao contrário.
Continue reading

Better Science Through Art – the talk

Common wisdom says that science and art are entirely different beasts; moreover, a similar source of wisdom tells us that science is valuable to society while art is a luxury. Why else would schools drop art from their curricula over the past 20 years? But artists and scientists approach their work in similar if not identical ways.

This presentation was created by Richard P Gabriel and presented at IME-USP – São Paulo on 31/Mar/2011 sponsored by CCSL

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

Refatoração na Pintura

Uma das técnicas mais usadas no desenvolvimento de software é a refatoração. Ela consiste em executar uma série de pequenos passos que visam deixar o código mais claro, mais bonito, mais elegante. Normalmente o resultado de uma refatoração é um projeto mais simples e de fácil manutenção. Muitas vezes a refatoração leva a criação de abstrações e generalizações no código.

Um exemplo simples: vamos supor que estejamos programando a classe de dados Pessoa. Essa classe contém atributos como nome, peso, idade, idioma que fala. Num segundo momento eu percebo que preciso inserir gatos no meu sistema. Então crio a classe Gato com os atributos nome, peso, sexo e cor do pelo. Em seguida percebo que criei uma ambigüidade. Continue reading