AgileAndArt

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.

Vamos lembrar que o objetivo principal do Coding Dojo é aprender, num ambiente amistoso e divertido. Nesse quesito o Dojo Ojod é bem semelhante ao Dojo Randori (a mais tradicional modalidade de Dojo). O que muda é que no Dojo Randori temos que fazer TDD, seguir passos de bebê e escrever o melhor código possível, refatorando, deixando ele elegante. No Dojo Randori não temos o objetivo de resolver o problema proposto. Já no Dojo Ojod o objetivo principal é resolver o problema, só que de uma maneira não convencional. Na verdade, a regra é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código que pudermos. Vale usar qualquer coisa, desde scripts nojentos até ferramentas prontas na Web, planilha de Excel, tudo que tem de mais abominável em matéria de desenvolvimento de software. O importante é favorecer a reutilização.

Aqui vão as instruções de como organizar um Dojo Ojod você mesmo:

1. Exponha a lista de problemas (veja os exemplos de problemas abaixo). Normalmente é bem ter umas 5 opções.
2. Cada pessoa escolhe que problema quere fazer. Dessa forma todos se dividirão em alguns grupos.
3. O ideal são grupos de 4 a 6 pessoas. Tente fazer com que isso aconteça, re-arranjando as pessoas caso seja necessário.
4. Cada grupo irá trabalhar isoladamente por 2 horas (cada grupo pode se sub-dividir como preferir se achar melhor).
5. Durante o trabalho, lembrem-se de que o objetivo principal é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código.
6. Passadas 2 horas, cada grupo irá apresentar para os outros a solução encontrada (acreditem, isso será muito engraçado!).

Um dos requisitos mais difíceis para esse tipo de Dojo é justamente criar problemas interessantes de serem resolvidos nesse tempo (2 horas). Vou passar aqui a lista dos problemas que tivemos na ThoughWorks:

O grupo que eu participei resolveu o problema número 3 (a música mais sortuda da cidade). Para quem está curioso, veja a solução no meu github e ouça um trecho dessa música maravilhosa.

Essa dinâmica de Dojo nos faz perceber como existem infinitas maneiras de se resolver um problema e como podemos re-utilizar soluções prontas, agrupando-as da maneira adequada, sem a necessidade de escrevermos muito código.

Organize você um Dojo desses na sua comunidade e deixe o seu comentário aqui de como foi o resultado. Se conseguirem inventar novos problemas, por favor, me conte também

Não deixe de ler uma descrição mais detalhada do Scrapheap Challenge no site do Nat Pryce.

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

Richard’s Bio

Richard P. Gabriel (Ph.D., Stanford University, 1981; MFA Creative Writing (Poetry), Warren Wilson College, 1998; ACM Fellow) performs programming language, creativity, and software engineering research at IBM Research. He is the author of five books. He played lead guitar in a rock ‘n’ roll band for 20 years.

Conceptual integrity arises not (simply) from one mind or from a small number of agreeing resonant minds, but from sometimes hidden co-authors and the things designed themselves.

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

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:

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…

It took a long time, but I finally migrated my old blogspot blog to WordPress. Please, give me your feedback about the new blog’s layout. I hope I can create much more content for you, with this incredible tool.

Just for fun, I’ve entered Web Archive to get the Apple’s website version for the last 10 years.

1997 – this is the first version I could get. It was ugly, red, and left aligned!

1998 – Still left aligned, but cleaner. Apple logo was colored that time.

continue reading…

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. Ambas as classes Gato e Pessoa possuem atributos em comum. Através de uma refatoração, crio a classe Animal com os atributos em comum (nome, peso, sexo) e faço com que as classes Gato e Pessoa “herdem” as propriedades de animais.

A idéia de extrair abstrações é a de identificar a essência do sistema e descrever com elementos simples suas características mais internas. Para chegar na essência é preciso muita experiência e suor. É preciso programar muito bem e saber usar de forma maestral a linguagem e as ferramentas a disposição. É uma arte.

Observe como são feitas refatorações na pintura de Pablo Picasso na figura. Inicialmente o pintor desenha um touro completo e normal, que pode ser reconhecido por qualquer criança de 5 anos. A cada novo estágio do desenho (são 11 gravuras no total), as partes irrelevantes vão sendo retiradas, porém a idéia central do touro permanece. O processo de desconstrução do gênio dura 6 semanas. Mesmo com com pouquíssimos traços, o último desenho consegue representar claramente o touro. São os traços essenciais do animal.

Todo bom programador, criador de software, deve saber reconhecer os aspectos essenciais de um sistema. As técnicas ajudam na execução, mas a genialidade está no pensamento intuitivo e na capacidade artística de identificar e extrair da a essência.

A Mariana Vivian Bravo da Agilcoop criou uma linda imagem, relacionando os valores, os princípios e as práticas de XP. Parabéns, Mari, pelo trabalho