1. Realmente existe diferença entre TDD e BDD?

    Recebi um comentário do Cândido Sales que me fez reler um texto meu antigo sobre a diferença entre TDD e BDD. Achei legal, interessante, mas vale a pena escrever mais um “dedinho” de palavras e incluir agora minha experiência de se usar TDD/BDD por algum tempo (Uns 2 anos, mais ou menos)!

    Depois de toda a experiência que tenho hoje com desenvolvimento orientado a testes/comportamento vejo que não existe muita diferença entre as técnicas. Acredito, como já acreditava, que BDD faz parte da evolução de quem começa a praticar TDD.

    Mas a parte mais importante, é que no final, essas duas técnicas não são apenas para testar a sua aplicação. Hoje considero que mais importante do que testar a aplicação é:

    Design consciente:

    Quando vamos desenvolver algum código, não temos ainda uma opinião forte de como deve ser esse novo código. Então praticamente não sabemos ainda nomes de classe, métodos, rotinas…

    Então TDD/BDD entra para nos ajudar a modelar no inicio do desenvolvimento de nossa API. Se você considerar o desenvolvimento em baby steps, então teremos uma API que evolua naturalmente conforme nossa aplicação vai crescendo. E a base dessa evolução são os testes que criamos antes e que nos dá segurança no desenvolvimento.

    Refactoring:

    Refactoring é rescrever nossa API de forma mais simplificada e que os testes continuem passando e devemos evoluir nossos testes para acompanhar essa simplificação. Sem os testes não temos como garantir que essas alterações que visam simplificar o código continuem funcionando, por isso refactoring sem testes não é refactoring.

    Conclusão

    Hoje considero TDD e BDD como duas formas diferentes de design da aplicação e que você realmente deve estuda-lás (Ou escolher uma :P) e melhorar o design do seu código.

    Não vejo muitas diferenças em se utilizar TDD ou BDD e que vai mais da escolha pessoal do programador ou da sua equipe. E que o mais importante, é que se você está usando alguma dessas técnicas, então isso demonstra que você já tem uma preocupação com a qualidade do código que você escreve.

  2. mastá massa! A vitrine da propaganda piauiense.: Curso on-line de NoSQL da e-Genial

    mastamassa:

    Aos programadores, haverá um curso que vai abordar os conceitos básicos até a construção de aplicações em Ruby usando os bancos NoSQL CouchDB e MongoDB. Complicado? Depende a quem é direcionado, no caso, aqueles que tiverem conhecimentos básicos da linguagem de programação Ruby e noções básicas de…

  3. Ele acredita que a formação universitária será importante para o caso de querer ingressar em uma grande empresa, que exija um diploma na área, mas admite que deve usar muito pouco do que aprendeu na faculdade em seu dia-a-dia.
  4. O discurso comum é “minha equipe não se comporta da maneira ágil”, “meu chefe é tradicional”, “nós não temos uma cultura TDD”, “ainda temos gerente de projeto”, “chamamos pessoas de recursos” e por isso, não dá para “ser ágil”.

    O que tenho experimentado na minha prática como consultor é que não adianta se focar na cultura por ela ser abstrata.

  5. Proc e lambda

    Você já deve ter ouvido que tudo em Ruby é objeto. Sim, sim, tudo é objeto. Menos blocos.

    Blocos não são objetos. Mas existe duas formas de transformar blocos em objetos. Uma é usar Proc e a outra é usa lamda.

    Para se criar um Proc existem algumas formas, a mais simples e mais utilizada é:

    proc = Proc.new do |object|
      puts object.inspect
    end
    

    Depois que você criar o seu Proc, para chamar o bloco que você acabou de criar, você deve utilizar o método call:

    proc.call Object

    O método call é chamado para executar o bloco. Em blocos, vocês podem fazer o que quiser. Um caso interessante é para processamento sequencial. No rails é bastante utilizado na definição de named scopes.

    Outra forma de fazer blocos virarem objetos é utilizar o lambda:

    lambda = lambda do |object|
      puts object.inspect
    end
    

    Basicamente, Proc e lambda funcionam da mesma forma. Mas existe uma diferença, que é no caso de se utilizar controles de fluxo, no caso return, break, redo, retry e vários outros.

    O problema nesse caso é que esses controles de fluxo quebram quando você está utilizando Proc.

  6. Leia antes de lançar um produto

    Qual a sua definição de um bom produto? Ele tem que ser funcional?! Ele tem que ser útil?! Ou ele tem que despertar em você uma necessidade?

    Todos falam sobre os produtos da Apple, sobre como o Steve Jobs consegue criar a necessidade e como todos acabam comprando (Eu sou um deles!).

    Não importa o quanto revolucionário é o seu produto. Se ele não despertar a necessidade nos seus clientes, você não irá fazer sucesso. E a melhor maneira de despertar a necessidade é criando um fucking awesome produto!

    Uau! Você chegou até aqui e com certeza nada do que você leu é novidade. Estou apenas pensando sobre um assunto que sempre é recorrente, principalmente se você é empreendedor.

    Se você está fazendo um produto agora, que lançou um produto ou que ainda vai lançar um novo produto nunca esqueça de que antes da arquitetura da sua aplicação ou o quão rápido ela deve ser, o mais importante é que ela seja espetacularmente lindo e que tenha a melhor usabilidade ever.

  7. Ruby Masters Conf

    Eis que mais uma vez a e-Genial surpreende anunciando o Ruby Masters Conf, que é uma maratona de palestras com os maiores feras de Ruby do Brasil e ainda com convidados internacionais!

    A e-Genial é conhecida no Brasil pela excelência dos seus cursos (Já ministrei um por lá \o/) e também conhecida por ter uma das melhores plataformas de ensino a distância do país, o TreinaTom.

    O evento vai ser todo através do TreinaTom, com a possibilidade de você conhecer muita gente boa e no final poder ter as palestras sempre que você quiser, tudo vai ser gravado e disponibilizado para quem se inscrever!

    O Ruby Masters Conf é um evento para espalhar conhecimento e ajudar projetos OpenSource. Foi escolhidos dois projetos, o RubyInstaller, para quem usa windows, e o Passenger, dos carinhas da Phusion.

    O RubyInstaller é um binário executável que faz todo o processo de instalação do Ruby no Windows. É bastante usado pelos alunos da e-Genial nos cursos de Rails ministrado pelo Daniel Lopes.

    Já o Passenger é usado na hora de colocar sua aplicação em produção por quase todos os grandes players do Brasil e do Mundo.

    Esses dois projetos são muito importantes, o primeiro por permitir que a simplicidade do Ruby chegue na complexidade que é o Windows e com todas aquelas telas azuis, e o segundo por fazer o deployment de aplicações Ruby (Só precisa ser Rack!) ser mais simples como é muito coisa no Ruby!

    Eu já estou divulgando por aqui e nos vemos no Ruby Masters Conf!

    :D

  8. Meu ambiente de desenvolvimento em 7 itens

    Fui convidado pelo @danillos para descrever mais sobre o meu ambiente de trabalho :)

    1. Sistema operacional

    Mac OS X e Ubuntu. E já estou indo para o meu terceiro ano com Mac OS, simplesmente fantástico, não só pelo software, mas pelo casamento com o hardware. E o Ubuntu ainda tenho em um desktop que as vezes eu utilizo no Jusplex, sinceramente não muito, mas uso.

    2. Terminal

    Indispensável. Abre junto com a inicialização do sistema operacional e continua até ser desligado.

    3. Git

    Se você ainda não usa nenhum tipo de controle de versão, você merece ser marcado com brasa quente! Não passe pelo mesmo problema que o Jonny Ken teve nesse ano de 2010.

    4. TDD/BDD

    "Test all the f*cking time" é um "vício" que surgiu na comunidade Ruby e quando você vai pra outra linguagem percebe o quanto isso é importante no dia a dia em desenvolvimento.

    5. Editor de texto

    Vim/TextMate. Atualmente entrei na modinha do vim, então resolvi dar o braço a torcer por ele e ele é realmente legal (E funciona da mesma forma no Linux e no Mac OS X). O TextMate consegue ser a killer app de editores no Mac OS X, fantástico!

    Se você precisar mais do que isso, você é um Javeiro que só consegue fazer as coisas usando o Eclipse! (Troll!)

    6. Google Chrome

    Preciso de memória, eu sempre estou com um monte de coisa aberto, e sempre tem uma aba no Gmail, que pesa muito depois de muito tempo aberto.

    Testei todos os browsers suportados no Mac OS X, e o que me deu a melhor resposta foi o Google Chrome.

    Funciona sobre o WebKit, existe uma boa ferramenta para desenvolvimento e recentemente abriu a app store.

    7. Água

    Combustível diário para desenvolvimento. Sem água nada funciona.

    Para continuar a série eu convido o Daniel Lopes, o Vedovelli e o Cássio Marques!

  9. Extraindo informações usando Ruby

    Hoje lancei uma aplicação que faz a análise dos palpites de um bolão (O bolão da Marko Informática) e mostra um gráfico com a quantidade de palpites por placa em um determinado jogo.

    Para extrair essas informações eu não precisei acessar o banco de dados. Apenas consumi o que todos já podem ver, como por exemplo este link.

    Essa brincadeira de extrair essas informações do bolão da Marko Informática começou com uma dúvida da minha esposa, Tatyana Emérito, se tinha condição de ver no site os palpites dos outros participantes. Em menos de cinco minutos depois eu vi que tinha a possibilidade de ver essa informação como vocês podem ver neste link, mas que infelizmente para mim é irrelevante.

    Essa informação é desorganizada e não vai me ajudar a tomar uma decisão quanto aos meus palpites. Para mim é mais importante ter esses dados sumarizados de forma que eu não perca tempo analisando todos os palpites, um por um. Então, organizar a informação para que eu saiba quantos apostaram em 2x1 é mais interessante do que ter que contabilizar isso manualmente.

    Para fazer isso em ruby eu utilizo a gem nokogiri, que faz justamente a análise e busca em html/xml. Com ela eu posso facilmente consumir o conteúdo de uma página e extrair os dados que realmente importa.

    Nada muito complexo de se aprender, como você pode ver aqui.

    Eu pensei em fazer usando o Rails 3, mas depois de fazer o primeiro protótipo, vi que não seria necessária algo tão grande, então tirei o Rails e coloquei o Sinatra.

    Para montar o gráfico eu perguntei no Twitter quem indicaria bibliotecas js que fizessem Chart. Depois de olhar todas, a do Google Charts foi a que eu achei mais simples e sem burocracia para colocar no site.

    E por fim, para fazer deploy da aplicação eu usei o Heroku, que é um serviço Cloud para aplicações em Ruby.

  10. Trabalhando com datas naturalmente com Chronic

    Esta semana passei gastando um tempão implementando um Parser que me retornaria um dia em que um evento ocorre em uma determinada data.

    Mas a data seria algo “Quero trazer todos os usuários que se cadastraram na terceira terça feira do mês de janeiro”. A forma que eu estava implementando não era assim tão segura, apesar de todos os testes estarem passando.

    Então hoje eu encontro o Chronic. É uma gem ruby que faz justamente o que eu precisava:

    
    irb(main):005:0> Chronic.parse("3rd tuesday in january", :context => :past)
    => Tue Jan 19 12:00:00 -0300 2010
    

    Simples e rápido.

  11. Sincronizando bancos MySQL com Maatkit

    Maatkit é uma ferramenta criada para DBAs, programadores e usuários que lidam com bancos de dados opensource em replicação master-master e master-slave.

    A maioria das ferramentas foi feita para o MySQL, mas você pode utilizar em seu banco de dados preferido (Não sei quais seriam esses outros bancos :P).

    Uma das ferramentas do Maatkit é a sincronização entre bancos de dados. Ela é extremamente útil quando você tem bancos de dados MySQL replicados, sendo ele na configuração master-master ou master-slave.

    Após instalado (debian like é apt-get install maatkit) você pode fazer o seguinte comando:

    mk-table-sync —execute —synctomaster —verbose

    mk-table-sync é um dos executáveis que ele instala junto com vários outros.

    Para sincronizar dois bancos sem ser master-slave você pode fazer da seguinte forma:

    mk-table-sync —execute u=user,p=pass,h=host1,D=db,t=tbl host2

    Se você que mais detalhes e ver os outros executáveis, visite o site do projeto.

  12. Atualmente eu trabalho em basicamente duas aplicações: a do Jus Navigandi e o TrendTime. São duas aplicações Ruby On Rails, bem distintas, nessas duas aplicações eu faço testes.

    Mas são níveis de testes diferentes, infelizmente. Enquanto que na aplicação do Jus Navigandi eu não escrevo código sem testes, na do TrendTime eu ignoro alguns lugares.

    Eu faço isso por um único motivo: No Jus Navigandi o código não é meu, não é uma aplicação minha. Justamente por isso eu não posso arriscar em escrever códigos sem testes, sem ter um mínimo de qualidade aceitável. No TrendTime parte da aplicação foi feita sem testes, só no "olhômetro". Claro que temos uma suíte de testes, mas ela não cobre a aplicação 100%.

    Eu faço isso por quê no TrendTime eu posso errar e voltar atrás, enquanto que na aplicação do Jus Navigandi eu não posso cometer esse mesmo deslize. O código não é meu, o código é do Jus Navigandi, e como o código faz parte da empresa, o código tem que refletir a qualidade que é o Jus Navigandi.

    O Jus Navigandi é uma empresa em excelência nos artigos publicados, é uma revista jurídica, como tal não é qualquer texto que entra lá. Existe uma bancada de pessoas que analisa todos os textos no dia a dia e apenas os melhores textos é que são selecionados.

    Nós programadores temos que levar essa qualidade para dentro do coração do Jus Navigandi, o código tem que refletir a mesma qualidade com que os textos do Jus Navigandi são aceitos. O código tem que ser bom, o código tem que ser limpo e o código tem que ter testes (ciclo vicioso de qualidade).

    Quando eu navego pelo github, por vários projetos, a primeira coisa que eu faço é descer a barra de rolagem e procuro por test ou spec. Faço isso pra saber se o criador daquela biblioteca teve pelo menos o trabalho de fazer alguns testes naquele código. Faço isso porquê eu, como um desenvolvedor que vai usar aquele código, fico mais tranquilo em saber que a biblioteca possui testes. Por conta disso, posso codificar com mais tranquilidade e se alguma coisa acontecer, vou primeiro verificar meus testes/códigos.

    Assim como as bibliotecas que eu vou escrever, se eu não fizer os testes, vou passar menos confiança para quem possivelmente vai utiliza-la. Aprendi que na comunidade Ruby On Rails, os testes expressam mais do que os códigos. Se eu quiser saber como uma biblioteca realmente funciona, eu não preciso necessariamente criar algo com aquele código, eu posso ver a suíte de testes e me situar sobre aquela biblioteca.

    Em uma empresa que você faz parte do time, é essencial que você passe tranquilidade para os outros programadores, sejam eles pessoas que já trabalhe com você ou um novo programador que vai ajudar o seu time.

    Com uma suíte de testes, você tem a oportunidade de mudar tudo, arrumar e deixar como era antes. Por exemplo, mudar de SQL para NoSQL e sua aplicação continuar a mesma.

    A melhor forma de você passar confiança para outros programadores é fazendo testes e cobrindo sua aplicação de testes. São eles que vão te salvar no dia que você vai ter que mudar a regra de negócio. São os testes que vão te guiar para uma solução simples.

  13. overmind:

    The surprising truth about what motivates us.

    Estudos (repetidos diversas vezes) mostram que dinheiro não é o principal motivador quando o trabalho envolve esforço mental. O vídeo explica o porquê.

  14. Dúvidas com Git? Olha o blog do Alberto Leal

  15. MongoID

    MongoID é um ORM Ruby para MongoDB

Powered by Tumblr; designed by Adam Lloyd.

Rank Monitor