Criar um novo Barco

Gosto muito de barcos e desde pequeno eu tenho fascinação por mar. Já que nossa área ganha bem e só perde para o salário dos políticos, eu decidi comprar um barco todo personalizado. Então fiz uma pesquisa de mercado para saber quem poderia me fornecer o barco a um custo razoável e a um prazo aceitável. Não foi muito difícil para aparecer duas pessoas interessadas no meu negócio. Um chamado Dunga e outro chamado Phelps.

O Dunga me falou que trabalha com os melhores barcos de mercado e todos tem ótima qualidade. Ele disse também que trabalha com uma fábrica de talentos na construção de barcos. Então ele me propôs as seguintes fases para a construção do barco:

1- Fazer a concepção detalhada de tudo que eu quero no meu barco. Analisar e documentar tudo que o barco precisa ter e fazer. Quantos cômodos vai ter meu barco, quantas portas e janelas. Se os bancos serão de couro, se as paredes terão detalhes com gessos. Qual altura vai ter os mastros. Qual vai ser a velocidade desejada para meu barco etc. Após essa fase de análise, iniciar a construção do barco. Em seguida testar se o barco tem estabilidade desejada em mar aberto ou se está pendendo muito. E finalmente entregar o barco para ter o meu feedback. O Dunga disse que precisaria de 11 pessoas para a construção, sendo que um ficaria responsável pela retaguarda do barco ( motor e âncora ),  quatro fariam a parte traseira, outros quatro fariam o interior do barco e dois últimos ficariam responsáveis pelo bico do Titanic. O tempo de entrega seria 2 anos de concepção, análise e documentação, mais 2 anos de construção, testes e implantação. Sem contar as manutenções necessárias depois da entrega. Total de 4 anos. O custo seria equivalente ao passe do Riquelme e Messi juntos!

O Phelps me fez a seguinte proposta:

2- Fazer todas as fases da proposta 1 muito mais vezes! O prazo seria estipulado em entregar partes do barco mensalmente e o custo seria apenas as horas que ele e outro profissional, chamado César Cielo, estiverem fazendo o barco. 

Mas como isso ser possível? Minha primeira impressão foi que o Phelps bateu a cabeça no barco e ficou louco! Com a testa inchada agora ele acha que pode fazer todas as fases da proposta 1 diversas vezes, entregar essas fazes a cada mês e ainda fala que vai sair muito mais barato?

Apesar do susto, eu tive uma leve impressão que o Phelps me entregaria o barco pronto com mais agilidade, então decidi arriscar pela proposta 2.

Na verdade, após o andamento do projeto, eu percebi que de louco o Phelps não tem nada. Ele pediu para que eu sempre estivesse presente na construção do barco. Tínhamos uma comunicação face-a-face sobre como deveria ser o resultado. Eu percebi que o dia que o Phelps não trabalhava a produtividade continuava quase a mesma, pois o Cielo sabia fazer tudo que o Phelps estava fazendo. Depois de três meses, consequentemente três entregas, toda a estrutura da base do meu barco estava montada, o que já me permitia atravessar parte do mar até uma ilhazinha paradizíaca. Lembro-me a vez que eles me entregaram todas as 50 janelas do barco. Primeiramente me mostraram apenas 10 moldes nas paredes, sem janela nem acabamentos. Esses moldes seriam onde as janelas se encaixariam. De imediato eu bati o olho e vi o formato das janelas sendo todas quadradas. Então conversamos e o meu feedback foi de mudar as janelas para que todas fossem redondas, e para não ter tanta claridade interna, seriam necessárias apenas 30 janelas e não 50. Minha surpresa foi que na entrega posterior todas as janelas estavam prontas, mesmo aqueles moldes que estavam quadrados. Eu fiquei imaginando quanto retrabalho eles teriam se tivesses feito todas as 50 janelas com formatos quadrados.

Reparei que eles nunca fazias horas extras de trabalho, eles mantinham um ritmo sustentável de trabalho e mesmo assim faziam as entregas no prazo. O que primeiramente parecia um projeto de longas datas, até anos, em apenas 9 meses eu já tinha o simples, mas que era tudo o que eu realmente necessitava.

Fiquei bastante surpreso com a agilidade do Phielps, como se ele já tivesse nascido para construir o meu barco.

 

Mas se eu não me contentasse com um barco e quisesse um navio? Será que esse método de trabalho funcionaria para mim? Hoje sei que se fosse um navio, ainda mais um navio, eu não seria louco de fechar um contrato com o Dunga.

Anúncios
Publicado em metodologia. 1 Comment »

Criando uma DSL

A um tempo atrás escrevi um post sobre Fluent Interface e surgiram algumas discussões sobre a fluência, como por exemplo:

  • Restrições de tecnologia (no caso o Java)
  • Um trabalho que pode ser chato de implementar
  • O código demonstrado no post ainda não parecia ser muito fluente.

Concordo com essas questões e realmente tem como resolver esses problemas. Caso eu precisar dessa fluência no meu projeto eu poderia utilizar de recursos como Groovy e Clousures deixando o código muito mais fluente e intuitivo. Mas antes de chegar nesse ponto é interessante entender o que é uma DSL. É interessante notar que algumas DSLs nós já usamos a muito tempo e nem percebemos!

Para quem já trabalhou com aplicações a chance de ter deparado com uma DSL é grande. Um arquivo de configuração é uma DSL, um makefile ou um build que especifica regras e dependências do projeto é uma DSL. Se você já escreveu algum desses arquivos você já teve seus primeiros passos com DSL.

DSL, portanto, é uma linguagem de domínio de fácil entendimento por quem conhece esse domínio.

Uma pessoa que é familiar à uma linguagem de domínio deve entendê-la facilmente. Por exemplo, se você está criando uma DSL para atores do seu sistema expressarem uma regra de negócio, você não vai querer que eles gastem tempo para entender a complexidade da linguagem. Você quer que eles foquem em detalhar as regras de negócio. A DSL que você criar para eles teve ter o vocabulário e os termos usados por esses atores no dia-dia, sem se preocuparem com a sintaxe de uma linguagem. Por exemplo, para alguém que entende de multiplicação de matrizes, matrixA.multiply(matrixB) é menos expressivo e conciso do que simplesmente matrixA * matrixB. O ganho do uso de uma DSL é prover uma interface gráfica ou textual que permitam usuários interagirem com sua aplicação. O resultado disso é uma maior produtividade e flexibilidade no sistema.

DSL Interna e Externa

Uma DSL pode ser classificada como interna ou externa, dependendo de como ela é desenhada e implementada.

Uma DSL externa é independente de uma linguagem de programação em particular. Por exemplo ANTLR.

Uma DSL interna, por outro lado, depende da linguagem de programação. A boa notícia é que você não precisa se preocupar com a gramática, parser ou alguma ferramenta. Porém a DSL é limitada por restrições da linguagem. Outro problema é que dependendo da gramática você terá que criar um compilador para parsear, processar a sintaxe e mapear na semântica que você espera, o que pode ser um pouco trabalhoso.

Exemplos de DSL:

 

  • Em CSS 
A:hover { color: #FF0000; text-decoration: none; }

  • Em makefile
GCC=cxx -I.
all : clean compile
compile : myprog
myprog: MyProg.cc Util.o
    $(GCC) -o myprog MyProg.cc Util.o
Util.o : Util.h Util.cc
    $(GCC) -c Util.cc
clean :
    /bin/rm -f myprog Util.o

  • Em ANT
<project name="AnExampleProject" default="jarit" basedir=".">
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="distrib" location="distrib"/>
<target name="compile" description="compile your Java code from src into build" >
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="jarit" depends="compile" description="jar it up" >
<jar jarfile="${distrib}/AnExampleProject.jar" basedir="${build}"/>
</target>
</project>

  • Em Rake (Makefile no Ruby)
ORIGINAL = 'input.dat'
BACKUP = 'input.dat.bak'
task :default => BACKUP
file BACKUP => ORIGINAL do |task|
cp task.prerequisites[0], task.name
end

  • Em Gant (Make no Groovy)
#slightly modified version of example from http://gant.codehaus.org/
includeTargets << gant.targets.Clean
cleanPattern << [ '**/*' , '**/*.bak' ]
cleanDirectory << 'build'
target (stuff : 'A target to do some stuff') {
println 'Stuff'
depends clean
echo message : 'A default message from Ant'
otherStuff()
}
target (otherStuff : 'A target to do some other stuff') {
println 'OtherStuff'
echo message : 'Another message from Ant'
clean()
}
setDefaultTarget stuff


Usando DSL para Validação.
ActiveRecord em Rails:

class Person
validates_presence_of :first_name, :last_name, :ssn
validates_uniqueness_of :ssn
end

GORM em Grails:

class State
{
String twoLetterCode
static constrains = {
twoLetterCode size: 2..2, blank: false, unique: true }
}

 

 

 

O ganho de linguagens dinâmicas como Ruby e Groovy, podendo ainda utilizar frameworks como Rails e Grails, torna a linguagem muito mais expressiva e clara do que linguagens mais burocráticas como o Java e C#.

easyb é um framework orientado ao comportamento do software (escrevi sobre isso nesse post) que permite usuários escrever histórias que expressem e validem o comportamento do software. Validação no easyb é baseado em history DSL. Exemplo:

//transferMoney.story
scenario 'transfer money', {
given 'account numbers 123456789 and 123456788'
when 'transfer $50 from 123456789 to 123456788'
then 'balance of 123456789 is $50 less'
and
then 'balance of 123456788 is $50 more'
and
then 'transaction has been logged...'
}

Esse código acima é uma documentação executável e pode ser executada com o seguinte comando:

java -classpath ... org.disco.easyb.BehaviorRunner transferMoney.story

Isso vai produzir o seguinte resultado:

Running transfer money story (transferMoney.story)
Scenarios run: 1, Failures: 0, Pending: 1, Time Elapsed: 0.431 sec
1 behavior run with no failures

Martin Fowler e Eric Evans descrevem uma Fluent Interface como uma interface bem desenhada para o uso humano.  Um exemplo de Fluent Interface é o EasyMock. Com ele podemos fluentemente expecificar o retorno de um método:

expect(alarm.raise()).andReturn(true);
expect(alarm.raise()).andThrow(new InvalidStateException());


Outro exemplo é o JSONObject:


JSONObject json = new JSONObject();
json.accumulate("key1", "value1");
json.accumulate("key2", "value2");

Ou melhor que isso, sem precisar usar o 'json.' 

JSONObject json = new JSONObject().accumulate("key1", "value1").accumulate("key2", "value2");

No Guice, um framework de Injeção de Dependência, podemos fazer :

bind(Alerter.class)

.to(VisualAlerter.class) .in(Scopes.SINGLETON);

 



Um ArrayList em Java pode ser escrito assim: 

java.util.ArrayList<String> cart = new java.util.ArrayList<String>(); 

cart.add("Milk"); 

cart.add("Juice"); 

cart.add("Apple");   

System.out.printf("My cart has %d items.", cart.size());  

 

Já esse mesmo código, em Groovy:

cart = []

cart.with {
  add "Milk"
  add "Juice"
  add "Apple"

  println "My cart has $size items."
}


Agora em Javascript:

cart = new java.util.ArrayList()

with(cart)
{
  add("Milk")
  add("Juice")
  add("Apple")

  println("My cart has " + size() + " items.")
}


Em Java podemos escrever o código abaixo:

PizzaBuilder bldr = new PizzaBuilder();
    bldr.setDough();
    bldr.setSauce(2);
    bldr.setCheese(2, "Mozzarella");
    bldr.setToppings(new String[] {"Olives", "Tomatoes", "Bell Peppers"});
    bldr.bake();
    Pizza pizza = bldr.get();

Podemos melhorar esse código para:

Pizza pizza = new PizzaBuilder()
      .prepareDough()
      .addSauce(2)
      .addCheese(2, "Mozzarella")
      .addToppings(new String[] {"Olives", "Tomatoes", "Bell Peppers"})
      .bake()
      .get();

Esse mesmo código, se utilizarmos Groovy e clousures pode ser facilmente escrito assim:

Pizza pizza = PizzaBuilder.make {
        prepareDough()
        addSauce(2)
        addCheese(2, "Mozzarella")
        addToppings("Olives", "Tomatoes", "Bell Peppers")
        bake()

Ou mesmo sem os parênteses:


Pizza pizza = PizzaBuilder.make {
        prepareDough()
        addSauce 2
        addCheese 2, Mozzarella
        addToppings Olives, Tomatoes, Bell_Peppers
        bake()


A classe PizzaBuilder ficaria assim:

 

 

public class PizzaBuilder
{
  def Mozzarella = "Mozzarella"
  def Olives = "Olives"
  def Tomatoes = "Tomatoes"
  def Bell_Peppers = "Bell Peppers"


  void prepareDough() { }
  void addSauce(int amount) {  }
  void addCheese(int amount, String type) { }
  void addToppings(String[] toppings) { }
  void bake() { }
  Pizza get() { return null; }
static Pizza make(closure)   {     

PizzaBuilder bldr = new PizzaBuilder();

bldr.with closure 

return bldr.get();   

}

}

Para quem se interessar mais sobre o assunto as fontes são:

http://www.javaworld.com/javaworld/jw-06-2008/jw-06-dsls-in-java-1.html

http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html



Publicado em DSL. 3 Comments »

Agile 2008 Conference

Está acontecendo essa semana o evento Agile 2008 Conference em Toronto/Canada. Quem quiser saber mais detalhes o Guilherme Chapiewski está comentando no blog dele.

O Maior Evento de Rails da América Latina!

Rails Summit Latin America reunirá alguns dos maiores nomes do Brasil e do mundo, nos dias 15 e 16 
de Outubro de 2008.
Estou bastante ansioso para esse evento e, é claro, vou garantir antecipadamente para aproveitar a
promoção. Como o Akita disse no blog dele, esse é um evento para todas as comunidades, portanto quem
trabalha com java ou outra linguagem, essa é a oportunidade para aumentar seus conhecimentos.
Para maiores detalhes, confiram o blog do Akita:

Largada para o Maior Evento de Rails da América Latina!
Publicado em eventos. 1 Comment »

The Developers Conference 2008

Estive no TDC 2008 no dia 23 e 24 desse mês, um ótimo evento por sinal. Foram abordados dois principais assuntos, Java e Metodologia ágil. As palestras foram muito boas, sem contar com os palestrantes internacionais como Ed Burns (Spec líder do expert group de JSF 2.0), Reza Rahman (Membro do expert group de EJB 3.1 e co-autor do livro “EJB3 in Action”.) e Burr Sutter (SOA Product Manager da JBoss e Presidente do JBoss User Group de Atlanta.). Foram organizadas várias muvuca interessantes. Meus parabéns para a Vinícius Senger e Yara Senger.

No evento conheci muitas pessoas, fui sorteado com uma bolça da Red Hat e ganhei um caderno no box da Uol por derrubar todos os pinos no boliche jogando Wii.

Conheci também o Vinicius Teles da Improve It, que fez uma palestra surpreendente sobre Extreme Programming. Ele é o autor do melhor livro sobre esse assunto escrito em Português. Esse livro é realmente uma referência! Recomendo muito a leitura. Inclusive o Vinícius me entrevistou e provavelmente vai publicar no blog da Improve It. Por enquanto podemos nos divertir com esse post (aumentem o som). Dei muita risada!

 

Autores do blog Visão Ágil: Manoel Pimentel, José Papo, Eu, Felipe Rodrigues e o Juan Esteban Bernabó da Teamware.

 

O Manoel fez uma apresentação espetacular, fazendo várias analogias e deixando as pessoas refletindo sobre o assunto. Ele até me surpreendeu pois colocou a foto abaixo na apresentação dele.

O Manoel comentou sobre o evento aqui. Conversei também com o Rodrigo Yoshima, conhecido por escrever na revista Mundo Java. O Rodrigo comentou sobre o evento nesse post. O Edgar Silva da JBoss palestrou sobre REST e comentou aqui. Outra pessoa que conversei foi o Alessandro Lazarotti, um evangelista que manda muito bem.

 

Esses são meus amigos Paulo e Claudio, que trabalham com XP.

 

 

No final do evento teve uma muvuca sobre JSF/Seam com muita gente importante na comunidade, incluindo Vinícius Senger e Ed Burns.