Dica rápida para não caírem feito um pato como eu caí.  Hoje fui pesquisar um link do meu próprio blog pelo google e descobri que meu site “/tech” inteiro havia sido removido. Pior, o cache do google apontava para um lance estranho.

Conferi na ferramenta para webmaster do google e verifiquei que o Googlebot era redirecionado para um endereço “bablo .me .uk” e as vezes esse endereço se camuflava em outros.

Usando  ”curl -v -A Googlebot http://www.milfont.org/tech” eu recebia a mensagem:

...
* HTTP 1.0, assume close after body
< HTTP/1.0 301 Moved Permanently
< Date: Thu, 19 Aug 2010 23:55:13 GMT
< Server: Apache
< Location: http://bablo .me .uk/#....
...


Só depois de muita surra procurando nos .htaccess e .php da vida que encontrei nesse link o comentário que me salvou.

Procurando com find -name “*.php” | xargs grep -E “eval” eu encontrei escondido no wp-config.php, pior, estava com muitos espaços para a direita dificultando a visualização:


./wp-config.php:                                                eval(base64_decode('ZXJ....


Sei lá quanto tempo procurando essa desgraça, fica a dica se passarem pelo menos tormento. Revisei todas as permissões e atualizei o wordpress, coisa que deveria ter feito há tempos, mas o preguiçoso trabalha mais do que o esperto.

Especificamente no dia 22 de Junho de 2010 eu li uma mensagem, não lembro aonde, afirmando que as 10 primeiras perguntas enviadas a determinado email seriam selecionados para uma entrevista com Don Tapscott para a revista Época Negócios, a qual eu sou assinante.

Não formulei bem minha pergunta, na verdade foi um desastre, leiam “ipsi litteris” meu email:

Don, quais os conselhos que você daria para as empresas se precaverem contra “comportamentos de rebanho”?
Comportamente de rebanho eu considero aqueles movimentos causados por especuladores que tem o dominio sobre uma determinada multidão e pode influenciá-los negativamente afim de prejudicar e sabotar concorrentes.

Christiano MIlfont, Fortaleza-CE

Observe que minha pergunta estava relacionada a comportamento das multidões, uma pergunta mais consistente seria:  Como lidar com “comportamento das massas” negativa para seus negócios quando você perde o controle ou não sabe lidar com isso?

O que saiu na revista:

8 Que conselhos daria para as empresas se precaverem contra movimentos de especuladores que podem prejudicar e sabotar concorrentes? Christiano Milfont | Fortaleza – CE

Se seus concorrentes estão espalhando informações falsas sobre a sua empresa e violando a lei, acredito que você deve levar o caso às autoridades competentes.

Note que o sentido da pergunta virou especulação contra concorrentes o que é diferente de influência indireta por movimentos das massas.

A pergunta foi mal feita, o jornalista responsável não é especialista em todos os assuntos, diante da pergunta ele vai tentar condensar de forma a se enquadrar na matéria. Portanto a culpa maior é minha e não da mídia.

#fikdik

Ontem eu palestrei na faculdade IDEZ em João Pessoa – PB a convite do Dr. Rodrigo Rebouças – Coordenador e professor de pós graduação em dev de software -  sobre o tema “Agilidade no Mundo Real”, que consistiu basicamente em falar sobre minha experiência em implantação, mentoring e treinamento de agilidade em meus clientes nos últimos 2 anos.

Maurício Linhares também é professor da IDEZ, o que me deixa particularmente feliz em saber que tem gente capaz dentro da academia que pode fazer diferença. Esse contato entre mercado e academia é importante para todos e creio que os alunos ontem tiveram muito dever de casa para fazer.

Ontem anotei muitas dúvidas discutidas na mesa redonda que fizemos após as palestras e nos próximos dias eu postarei sobre as principais dificuldades em entender o que é agilidade, que TDD não evita equipe de Testes ou QA e nem sequer tem a ver com cobertura de código, que agilidade não é velocidade, inclusive pode ser mais lento em determinados períodos, confusão entre práticas, valores e princípios, entre outras coisas.

Sobre minha palestra eu falei sobre as dificuldades que encontro, como melhorar a adoção dos valores e princípios trabalhando a base. Vocês podem acompanhar nos slides e video abaixo:

Vídeo do Evento

Referências sobre os slides de minha palestra

O que é agilidade?
http://manifestoagil.com.br/
http://www.milfont.org/tech/extreme-programming-books/

Scripts do workflow GIT sobre os slides do “Merge From Hell”
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
http://reinh.com/blog/2008/08/27/hack-and-and-ship.html
http://gist.github.com/8511

Trabalho energizado
Pair Programming
http://www.milfont.org/tech/2010/06/17/trabalho-energizado-e-a-teoria-das-2-horas-produtivas/
http://www.milfont.org/tech/2009/02/03/pair-programming-vs-code-review/

Automação Total
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html
http://blog.caelum.com.br/2010/03/01/o-processo-de-deploy-continuo/
http://agilenomundoreal.com.br/2010/07/06/deploy-continuo-entrega-continua-de-valor/

http://railscasts.com/episodes/179-seed-data

Testes
http://www.milfont.org/tech/2009/06/01/recomendacao-sobre-tdd/
http://www.milfont.org/tech/2009/06/07/quanto-testar/

Sem tempo suficiente
http://www.milfont.org/tech/2010/06/29/sem-tempo-suficiente/

Dar caos a ordem

Destruir arquiteturas de referências

http://www.milfont.org/tech/2010/01/21/voce-esta-nivelando-por-baixo-eou-nao-conhece-seus-desenvolvedores/

http://www.milfont.org/tech/2008/01/20/frameworkstools-caseiros-ou-fechados/
http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/
http://www.milfont.org/tech/2008/01/21/nao-use-notacao-estranha/

Separar gerenciamento de projetos do processo de desenvolvimento
Pmbok de Jeans
http://www.milfont.org/tech/2009/03/14/pmbok-de-jeans/

Software Funcionando
http://www.milfont.org/tech/2009/09/17/qualidade-interna-vs-qualidade-externa/

Retrabalho e Prejuízo
http://www.milfont.org/tech/2009/01/08/retrabalho-e-prejuizo/

Workflow ágil e simples
http://www.pivotaltracker.com
http://github.com/tpope/pickler
http://github.com/trydionel/git-pivotal
http://www.pivotaltracker.com/help/api?version=v3#scm_post_commit

Jesus recomendando o trabalho em par
“E depois disto designou o Senhor ainda outros setenta, e mandou-os adiante da sua face, de dois em dois, a todas as cidades e lugares aonde ele havia de ir.”
Lucas 10:1

Recentemente, em um determinado projeto, tínhamos uma semana para disponibilizar uma versão e uma timeline definida por motivos externos que não poderíamos furar. O problema era que toda modificação gerava ainda mais medo por conta da baixa cobertura de testes, praticamente estavam codificando e corrigindo nessa altura do campeonato.

Eu radicalmente sugeri um grande refactoring para corrigir nossa bateria de testes, uma parada faltando apenas uma semana para entrega, mas só assim voltaríamos a trabalhar na entrega das features.

Nesse momento, o clássico “Não temos tempo para isso” surgiu das profundezas do inferno.

Fiquei sozinho nessa decisão, o time inteiro foi contra. Na defesa da solução apresentada eu falei: “Vocês podem se enganar imaginando que podem entregar essa release em uma semana com a qualidade do código existente que vocês sabem que vai de mal a pior ou podem trabalhar para corrigir esses problemas e entregar o possível, mas funcionando”.

Sabemos da importância de testes, todas as metodologias os cobra obrigatoriamente, então se você não testa, você está errado em todas as metodologias. O problema sempre é a desculpa da timeline e quanto mais vai se aproximando mais desculpas procuramos encontrar para esconder as deficiências. Como nesse caso não tínhamos Test First, os problemas vão se empilhando no final e se tornam mais difíceis de serem detectados.

Por sorte, minha sugestão acabou sendo acatada, apesar de ser apenas um consultor no projeto, portanto uma galinha e não porco.

De onde nascem essas desculpas?

Coragem é um dos valores do XP, é importante enfrentarmos esse tipo de situação que descrevi, na vida real isso quase nunca é possível porque essas arquiteturas flácidas ou códigos mal cheirosos não nascem do dia para o outro e vão se acumulando.

O projeto que descrevi era um projeto novo, tecnologias fresquinhas e um time modernoso. Imagina agora se você está em uma corporação que usa um processo cascata, todo amarrado, criando documentos UML desnecessários no EA, struts 1 como framework, CVS como controle de versão do código [quando há! Sim, em pleno 2010 ainda há quem não use nenhum], o código de banco de dados cheio de procedures e tantas modernidades da década de 80.

Então, acha que só coragem basta?

Em muitas oportunidades o custo de mudanças ou simplesmente “fazer o que se tem que fazer” não se pagará nem a médio prazo, nessas horas convencer já não basta. É muito difícil você convencer a alta direção que deve jogar fora um determinado projeto e começar do zero, ou modificar toda a infraestrutura existente.

A degradação de um software nasce de pequenos problemas que se acumulam, no final há tanto para se fazer que ninguém mais tem coragem para isso.

Socorro, Milfont!

Recebo constantemente pedido de socorro de pessoas que me conhecem das comunidades que participo como XPCE, GURU-CE, JAVA-CE, entre outras. Geralmente são funcionários que se encontram nessa situação que citei anteriormente, com projetos muito defasados e problemáticos.  O pedido é sempre o mesmo, querem que eu vá lá dizer para a alta direção o que eles [funcionários] já sabem. Só que isso não basta, o movimento tem que começar por lá.

Em reunião com a turma da TriadWorks, temos discutido isso já há muito tempo e acabamos preparando um serviço de resgate aos clientes para contornar esse problema. A proposta é envolver as pessoas desses clientes, dar coragem e ânimo nelas para começarem a resolver o problema.

Resolvemos começar com nossos próprios clientes, sim, dá preferência a quem tem contrato conosco e depois verificar como abrir para a comunidade.

Então, esse envolvimento nós demos o codinome de “AvoidNotEnoughTime” e consiste basicamente em um conjunto de ações/eventos  com os funcionários dessas empresas para dar essa força necessária para anular o NotEnoughTime na base. É um movimento de baixo pra cima, roots, serão desde Coding Dojos, Code Retreat, Code Jam, Hack Days, Lightning Talks, Open Space ou um formato adequado a um determinado problema que identificarmos.

Nós não vamos cobrar a mais dos clientes por isso, aliás, eles nem foram avisados e não terão controle sobre o projeto, nós que decidimos quando, como e com quem faremos justamente para evitar sabotagem ou direcionamento.

Sem planejamento nem nada, resolvemos iniciar mesmo assim, domingo passado [27/06/2010] realizamos um Git Session onde eu [@cmilfont], @triadworks representada por @handersonbf, @rponte e @carlosatilabreu, recebemos funcionários de clientes nossos. @jeffersongirao da TubForm, @rodrigogalba da Casa Magalhães e @rodrigodealer da Fortes Informática.

O que vocês ganham com isso?

Resolvemos fazer um Git Hack Session devido alguns de nossos clientes usarem CVS e SVN. O tempo perdido resolvendo problemas de repositório como merges e bobagens simples causam um prejuízo enorme, as desculpas para mudarem cai sempre no “não temos suficiente” ou “depois fazemos quando terminar esse projeto”.

Então cada ponto de dificuldade que um time enfrenta e observarmos que se repete nos demais clientes, vamos organizar ações para envolver essa turma afim de anular essas desculpas. Treinar multiplicadores em todos os princípios.

No caso do Jefferson Girão, que trabalha também para a Hoodiny, veio mais para nos auxiliar, já que está mestre no uso do git no meu cliente Tubform [uma das maiores indústrias do Nordeste].

Dessa forma nosso trabalho de consultoria será facilitado e no mínimo já faríamos esses eventos internamente, então unimos o útil ao agradável.

Se você gostaria de participar de algum desses eventos mesmo não sendo funcionário de cliente nosso, mande um email para mim [cmilfont@gmail.com] e tentaremos incluir sempre quando puder. Domingo agora surgiu um desfalque, até twittei convocando alguém que estivesse disponível, mas foi em cima da hora.

Creio que todo mundo já conheça a função noConflict do JQuery para evitar conflitos com outros frameworks que utilizam a variável dóllar ($). JQuery é sem dúvidas o melhor framework javascript para manipulação DOM e não há motivos e nem desculpas para não o usar, principalmente com essa resolução de conflitos.

Tenho refatorado alguns códigos javascript e o pessoal tem resolvido o conflito de forma confusa e misturando código de dois framework, inclusive código DOM nativo. A documentação recomenda, como uma opção, atribuir o resultado da função noConflict a uma variável e ela será o seu objeto JQuery.

Imagina que você tem Prototype e Jquery na mesma aplicação como no codigo abaixo:

$J = jQuery.noConflict();

//codigo prototype
$("id_de_algum_elemento").hide();
//codigo jquery em seguida
$J("#id_do_elemento").load("caminho.html");

A legibilidade vai ser horrível para manutenção desse código porque você vai ficar com códigos misturados com sintaxes e estilos diferentes, a medida que isso vai crescendo a manutenção vai ficando impossível.

Minha sugestão é utilizarem Closure e Currying para resolver o conflito, isolar o código e deixar bem mais claro. Se ler a documentação lá do noConflict tem exemplo como o código abaixo.

/* essa chamada evita o conflito com outros
   frameworks que usam dollar ($) */
jQuery.noConflict();

(function($) {
   // Seu código jquery vai aqui
  $("#id_do_elemento").load("caminho.html");
})(jQuery);

//codigo prototype
$("id_de_algum_elemento").hide();
//...

Se você preferir deixar claro a diferença entre os frameworks pode continuar a usar outra variável no lugar do $, mas a idéia é isolar o código de cada framework.

Tínhamos um problema nos testes unitários por débito técnico [na verdade desleixo mesmo] com o setup do Rspec e Sunspot-rails em determinado projeto. O problema era que mesmo para executar um simples teste unitário, levantávamos o Sunspot no spec_helper.rb.

Resolvi refatorar isso, acabei descobrindo no before/after do Spec::Runner.configure algo que eu não usava e que já existia desde o rspec “1.1.12 / 2009-01-11″, pelo que percebi no changelog.

O que fiz e parece bobo é separar pelo tipo (type) integration a subida de uma instancia real do Sunspot e agora dá para usar a estrutura de Rspec que o Sunspot disponibiliza para meus testes unitários.

#arquivo spec_helper.rb

ENV["RAILS_ENV"] ||= 'test'

require File.expand_path(File.join(File.dirname(__FILE__),'..','config','environment'))

require 'spec/autorun'
require 'spec/rails'
require 'rake'
require 'ruby-debug' unless RUBY_VERSION > '1.9'
require 'sunspot/rails/tasks'
require 'authlogic/test_case'
require 'sunspot/rails/spec_helper'

require 'database_cleaner'

#observe aqui que eu criei uma pasta support porque guardo algumas confs em arquivos contidos nela
Dir["#{File.dirname(__FILE__)}/support/**/*.rb"].each {|f| require f}

Spec::Runner.configure do |config|
  config.use_transactional_fixtures = true
  config.use_instantiated_fixtures  = false
  config.fixture_path = RAILS_ROOT + '/spec/fixtures/'

  config.before(:suite) do
    DatabaseCleaner.strategy = :truncation
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end

  [:model, :helper, :controller].each {|type|
    config.before(:each, :type => type) do
      ::Sunspot.session = ::Sunspot::Rails::StubSessionProxy.new(::Sunspot.session)
    end
    config.after(:each, :type => type) do
      ::Sunspot.session = ::Sunspot.session.original_session
    end
  }

  config.before(:all, :type => :integration) do
    JojobaSunspot.new.start
  end
  config.after(:suite) do
    JojobaSunspot.new.stop
  end

end

Inspirado nesse post, eu adaptei para o código que uso ao subir o sunspot com linha de comando para os testes de integração. Observe no código anterior que importo configurações da pasta support, inclusive a classe JojobaSunspot, usada no after e before de integration.

require "net/http"

class JojobaSunspot

  def start
    @started = Time.now
    up_sunspot if starting
    up
  end

  def stop
    system("sunspot-solr stop --pid-dir=/tmp/pids") unless starting
  end

  private
  def port
    Sunspot::Rails::Server.new.port
  end

  def up_sunspot
    system("sunspot-solr start -p 8981 -d /tmp/solr_data_test --pid-dir=/tmp/pids --log-file=/tmp/solr_log_test.log --log-level=INFO")
  end

  def up
    while starting
      puts "Sunspot server is starting..."
    end
    puts "Sunspot server took #{'%.2f' % (Time.now - @started)} sec. to get up and running. Let's Jojoba!"
  end

  def starting
    begin
      sleep(1)
      request = Net::HTTP.get_response(URI.parse("http://localhost:#{port}/solr/"))
      false
    rescue Errno::ECONNREFUSED
      true
    end
  end

end

Desde que colocamos testes de integração o tempo de execução da bateria subiu muito, provocamos um setup ineficiente e desnecessário para os testes unitários. Fica a dica para quem passar pelo mesmo problema.

Quando eu trabalhava como funcionário, formulei uma teoria exótica e controversa que se uma empresa tiver em média duas horas produtivas por cada “recurso”, essa empresa teria um lucro exorbitante e seria sustentável.

Duas horas produtivas para mim é uma licença poética para “códigos testáveis de forma automatizada, bem escritos, entregues por dia independente de tempo e que não trarão retrabalho”. Um par evita muito retrabalho, lembrando que retrabalho não é refactoring, é prejuízo.

Claro que não há método científico algum, apenas inferência por observação simples. Dia desses um funcionário de um cliente me disse:

“- Milfont, essa sua teoria é mais um dos seus exageros”.  Respondi:

“- Olha do lado, observe o que todos estão fazendo”.

Para espanto desse funcionário, ao olhar para o time mais caxias da empresa, aquele time considerado certinho, que ninguém conversa com ninguém, ele tomou um susto e detectou que todos, eu disse T-O-D-O-S, estavam com o cliente de email aberto. Ninguem estava com sua IDE em primeiro plano.

Coincidência?

Trabalho Energizado

Como consultor eu enfrento problemas de coaching e mentoring [adoro buzzwords] em relação a dificuldade da alta gestão não compreender os benefícios de programação em par para o trabalho energizado. Não que programação em par seja o único responsável por um trabalho focado, mas sem essa prática não dá nem para começar a mudar o cenário.

Todos meus clientes dizem em uníssono: “Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”. Investigaremos essa frase ao final.

Meu trabalho como consultor é transformar galinhas mortas em galos de briga, então não tenho pretensões nem esperança que em um mês meus clientes terão integração contínua, todos seguirão Test First como prática e serão felizes para sempre, no mundo real a coisa é só um pouquinho mais complicada. Enfrento muitos clientes saindo da década de 80 direto para o novo milenio, é uma leva de CVS, Delphi, até clipper, além de vícios provocados por essas plataformas/arquiteturas/whatever.

Agile Bibas

Hoje é muito comum meus clientes pedirem planilhas e técnicas para medir velocidade e desempenho de seus “recursos” porque leram sobre isso nas revistas da moda. Isso é perda de tempo, vou cair no clichê mas não posso deixar de falar, enquanto voce não tratar seu time como pessoas e que elas não são máquinas controladas, não espere retorno deles.

Leonardo Eloy cunhou o termo #Agilebibas para representar todos os defensores do PMBoK de Jeans que irão vender métricas e dirão que o time não produz conforme o esperado porque não se comprometem com as planilhas. Apenas comando-controle disfarçado de ágil.

Esqueça métrica de time, concentre-se na métrica do software. Não importa se o membro do time está nu, pulando corda, de cabeça para baixo, lendo emails ou enchendo a cara numa terça de manhã. O que importa é se as features foram entregues e com qualidade.

Parece simples mas não é, a soma “8 + 8 = 16″ é difícil de ser anulada [imaginar que 8 horas de dois funcionários representam 16 horas de trabalho produzido com qualidade]. Medir tempo por funcionário é um dos maiores erros para tentar aumentar a produtividade do time.

Vou dizer mais uma vez: “Não meça pessoas, meça e entregue software”. Então não importa se seu funcionário não trabalha as 6 ou 8 horas que você espera que ele trabalhe, o que importa é se as duas features planejadas para hoje foram entregues com a qualidade esperada.

Evitar o trabalho chato

Algumas empresas ainda sonham com a esperança que basta impedir o acesso a redes sociais ou serviços na web, então o funcionário vai parar o “Goofing Off“. Existem inúmeros motivos para uma pessoa não estar energizada em seu trabalho, considero o principal como sendo “fazer trabalho chato”.

Vamos agora analisar aquela frase do início:

“Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”

Observe que essa frase revela duas nuances onde o cliente acredita que trabalho em par não é importante, uma consequência da outra. Trabalho simples que provoca a necessidade de não trabalhar em par o tempo todo.

A primeira coisa como consultor quando sou contratado para mudar a cultura do time é tentar incluir programação em par como algo natural e prática necessária, para tanto preciso anular esse trabalho chato que considero ser basicamente trabalho repetitivo. Observe na frase anterior que meus clientes chamam esse trabalho de “simples”.

Não é simples, é chato.

Exemplo que me veio a cabeça agora mesmo, todos os cliente que não tem Test First como prática, então ficam testanto as coisas durante o desenvolvimento na mão, para tanto precisam gerar dados.  Para um desenvolvedor é frustrante ficar fazendo dump e passando para seus colegas de trabalho, porque não automatizar isso?

Todos meus clientes que não fazem Test First passam por isso. Ora, se mesmo os que tem essa prática nós enfrentamos desafios de um bom Setup para garantir a independência no INVEST, imagina os que não fazem.

Outro erro comum é achar que número de commits é sinal de proficiência ou estar trabalhando mais, em regra, para mim é sinal de muito trabalho repetitivo.

Não vou me prolongar, quero só concluir que evitar trabalho chato ajuda a demonstrar que Pair Programming é sim necessário o tempo todo e que se isso for alcançado a “morcegação” tende a diminuir e o reflexo na entrega de funcionalidades se torna positivo. Junte a isso o foco no software ao invés de medir pessoas e esqueça as toneladas de planilhas, na maioria das vezes nem um Burndown seja necessário, apenas trabalho energizado.

Mesmo com uma arrecadação record na história, o governo cearense, não satisfeito, resolveu cobrar diferença de icms para qualquer mercadoria comprada pela internet de forma inconstitucional.

Então a lógica é a seguinte: se eu comprar um mercadoria mais barata para fomentar meu negócio, sou obrigado a pagar para o estado, que bate record de arrecadação, a diferença de icms entre o estado que comprei e o Ceará. Fora isso ainda tem as regras da SEFAZ-CE que só liberam a mercadoria após alguns dias úteis a partir da confirmação do pagamento do imposto.

Não basta ter que lidar com a burocracia, agentes desonestos atrás de subornos, lentidão nos serviços e alta carga tributária. Agora nossos políticos metem a mão no nosso bolso diretamente e sem medo de retaliação.

Depois nos perguntam porque é tão difícil as pessoas empreenderem em coronelândia.

Perguntem ao governador @cidfgomes o que ele acha disso.

Ontem [27/05/2010] palestrei no evento da JavaCE na Unifor, abaixo estão os slides. Para quem não participou do evento, provavelmente os slides não farão muito sentido por si, mas creio que dá para entender o contexto.

O objetivo dessa palestra foi desmistificar um pouco o entendimento sobre Domain Driven Design. O foco foi demonstrar que essa abordagem não é sobre padrões, como bem me aconselhou o Rodrigo Yoshima. Enfatizei a comunicação como fator importante e comparei arquiteturas existentes por má compreensão não só da “Orientação a Objetos”, mas por dogmatismo e ignorância.

Como eu conheço bem o mercado local, enfatizei algumas más práticas que considero o empecilho aos projetos, principalmente as “arquiteturas de referências” que se proliferam aqui e impactam na modelagem.

Fizemos um “Hands On” rapidinho e não tem como não falar sobre TDD, afinal, modelagem ágil passa invariavelmente pelo Test First. “Fizemos”, porque tive a ajuda do @rponte.

Descobri só ontem que existe tradução do livro Domain Driven Design do Eric Evans, eu recomendo comprarem o original na Amazon, mas se forem comprar em português que seja pelo meu link.

A InfoQ publicou um minibook sobre o tema.

Vou subir a aplicação que codificamos ontem para o github e atualizo essa página quando estiver disponível. Algumas fotos que foram tirados voces conferem aqui.

Algumas referências importantes sobre o que falei ontem:

http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/

http://fragmental.tw/2010/02/24/everyday-tales-anatomy-of-a-refactoring/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%E2%80%93-part-2/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%e2%80%93-part-3/

http://fragmental.tw/2010/03/22/nevermind-domain-driven-design/

Uma coisa já antiga é a eterna reclamação sobre o preço de eventos, ano passado o pessoal reclamou ser caro os 30 reais que cobramos nas palestras do Maré de Agilidade Fortaleza 2009. O valor era irrisório, praticamente simbólico porque não cobriria quase nada do custo que teríamos.

Não adianta, se cobrar 300 ou 30 vão achar caro do mesmo jeito.

O brasileiro é muito mal acostumado de investir em sua própria carreira, aqui é algo estranho até ser pego lendo, geralmente te perguntam se é para concurso.

Quase todo mundo que pergunto se vai para o Qcon em São Paulo faz cara de azedo e solta: “Tá caro”. Caro?

A InfoQ Brasil está trazendo alguns dos maiores nomes de desenvolvimento de software no mundo para compartilhar seus conhecimentos conosco e você acha caro? Já imaginou o custo que a organização terá só de passagens, hotel e alimentação?

Se você trabalha com TI, você faz parte de uma elite [no mínimo é classe média] e não tem motivos para reclamar de preço de eventos, ainda mais se você gasta com som, rodão de carro e baladas que não te agregam capital intelectual.

Se você vai no JunkieFood conosco toda sexta, gasta uns 30 reais só no BurgerKing, em um mês voce gasta com sanduíche quase a metade da inscrição do Qcon e acha caro um evento que vai agregar valor a sua carreira?

#rasgaessagrana e invista em você.