Como vou saber se está bom ou ruim um benchmark?! Simples, assim como muita coisa na vida, tudo depende do ponto de vista. A grande maioria dos benchmarks são sobre performance, tecnologia X é mais rápido do que Y ou framework U é mais rápido do que framework K.

Mas existem alguns benchmarks específicos como framework Y é mais fácil de fazer manutenção do que framework Z ou o tamanho dos arquivos gerados. Enfim, todos os propósitos dos benchmarks são apenas para demonstrar o lado bom e o ruim de uma tecnologia e levantar dados que facilitam na escolha dessas tecnologias.

Se você está indeciso de sobre qual tecnologia escolher, pesquise todos os benchmarks que existem sobre esta tecnologia em comparações a outras, se ainda não estiver satisfeito, faça seus próprios benchmarks e no final faça um levantamento junto com a sua equipe e discuta todos os pontos.

Infelizmente nesse final de ano foi muito corrido, muitas tarefas, muito trabalho, projetos, opensource. Depois que cheguei de São Paulo foi uma correria!

Mas em 2009 esse quadro vai mudar :)

Eu quero dizer a vocês o quanto eu estou agradecido com todos os meus leitores, as pessoas que me seguem no twitter e as pessoas que conheci neste ano de 2008. Este ano, foi um ano inesquecível e espero que 2009 seja mais ainda!

Meus planos para 2009 já estão feitos, e se for que nem os planos de 2008, todos serão realizados. Espero que os seus planos tenham dado certo e que vocês estejam felizes nesse final de ano!

Papo ta bom, mas preciso trabalhar! :P Então, feliz natal e um própero ano novo, até 2009!

Um teste chamado ValorVerdadeiro é diferente de um teste chamado ValorDaVariavelFooDeveSerVerdadeiro, a diferença não está no fato do código ser diferente, mas na percepção que temos ao ler isso. Ao ler ValorVerdadeiro o nome desse teste oculta o que ele realmente quer fazer. E nós não queremos ocultar nenhum teste, ou omitir o que os testes querem mostrar ;)

A nomeação de um teste não passa só por isso, as vezes, quando não sabemos nem o que testar, quando nomeamos um teste de maneira correta temos um gancho para sabermos o que queremos com esse teste e como vamos implementá-los.

E o nome do teste deve ser claro para que qualquer um possa saber o que você está querendo, em times mistos e com várias pessoas a integração fica bem maior. Ou para um novo desenvolvedor na empresa/projeto, você não precise de imediato explicar para ele todos detalhes do projeto, mas pode mostrar e pedir para ele ler os testes e tentar entender o que está acontecendo ali, é bem mais produtivo. (Se ele for bom, ele pega boa parte da lógica do sistema ao ver os testes).

Coloquem nomes legais e façam uma identidade unica para cada teste, isso pode salvar a pele de vocês um dia, quando um dos testes resolver não funcionar! Você de cara já vai entender o contexto do teste.

Eu já escrevi aqui sobre o PHPUnit e até uma vez eu disse que ia fazer uma série, comecei como fazer a instalação, aqui tem relatos tanto de windows como de linux, ensinei como integrar o PHPUnit ao CodeIgniter sem o uso de mocks e stubs (por falta de experiência, não é legal) e mostrei como fazer alguma coisa com o PHPUnit.

Mas o que quero mostrar nessa série é algo real, casos reais que eu enfrentei e como eu testei.

Eu vou explanar falando sobre o cake, um projeto estou trabalhando :)

O que eu realmente aprendi com o PHPUnit é que ele não é um simples framework de testes, na realidade, aprendi com todos os tipos de testes que já fiz (RSpec, Test::Unit, Cucumber, SimpleTest). Testes é apenas uma forma racional de você pensar em como desenvolver. Se você não tem a mínima idéia do que você quer saber, teste. Se tem bastante idéia do que você quer fazer, teste. Se você quer ter certeza do que está fazendo, teste! Em qualquer caso que você imaginar, teste!

Criando testes, você força a sua mente a pensar no comportamento da aplicação, na unidade de seus objetos e no que realmente você precisa. Eu já li a respeito de testes, e todos os autores afirmam, testes é uma filosofia, não é somente fazer você escrever menos e fazer mais, mas é realmente uma filosofia, existe pessoas que não conseguem criar guiado a testes, mas nem por isso são péssimos profissionais, é uma filosofia, vai de cada uma.

Você muda a sua forma de pensar, se você não está querendo ou não quer mudar, nem comece a tentar entender o que e para que serve todos esses frameworks, pois você está no caminho errado. Para começar a desenvolver orientado a testes, é necessário que você mude, que você programe menos e pense mais!

Não é brincadeira, é sério! Vocês não precisam morar lá, mas devem conhecer São Paulo e seus lugares mais obscuros!

No último final de semana eu fui a São Paulo para participar do PHP Conference 2008 (Em breve, um resumo sobre o evento), eu fiquei na casa do Klederson. O apartamento dele é dentro do coração de São Paulo, próximo a Av. Paulista e perto de tudo!

Por ser perto de tudo, sai caminhando pela cidade assim que cheguei, a impressão é muito boa. Limpa (As ruas, não o ar), cheia de gente de todos os tipos e sempre alguma coisa para fazer.

Eu fui a um #NoB, no El Malak, depois de passar na porta e caminhar até quase o final da rua e depois de ter perguntando a umas pessoas em um bar se lá estava acontecendo o #NoB.

Conheci Mirian Bottan, Marco Gomes, Sabine e mais algumas pessoas que não me lembro o nome xD depois do #NoB saímos e pronto!

Na sexta levantei cedo e conheci de perto o sistema de transporte da cidade, totalmente interligado, e cheguei a Osasco de trem.

E no sábado, após o evento, consegui dar umas voltas de carro pela cidade, eu mesmo dirigindo, com o meu tio louco!

Depois de dar um susto no papai e na mamãe, dizendo que eu estava perdido e procurando uma parada de ônibus para ir para o aeroporto, quase em cima da hora, cheguei ao aeroporto internacional de guarulhos e tomei o rumo de casa.

Deixando para trás uma bela cidade, gigante, por sinal, com muita coisa para fazer e muita coisa para aproveitar, fico agradecido as pessoas que me ajudaram por lá e para as pessoas que eu conheci fica meu grande prazer.

P.S. No final da viagem, eu pedi ao piloto do 737-800 para tirar umas fotos na cabine, coisa de Nerd. Então ele me explicou que não podia, mas pediu a camera para filmar a aterrissagem em Fortaleza, ele só filmou 2:17 por quê tinha acabado a bateria :( mas para a minha sorte, um dos pilotos desembarcou em Fortaleza, e o mesmo piloto me chamou para voltar para Teresina dentro da cabine, mas sem eu tirar foto e nem filmar. Como Nerd que sou, fiquei muito feliz em viajar como terceiro piloto de um 737-800 por alguns minutos!!

Esse post é para apenas lembrá-los que a Add4 Comunicação estará fazendo parte do PHP Conference e nós queremos vocês com a gente :)

Eu chego em São Paulo no dia 27. Tem um #NoB marcado, quero ir, alguém me leva?! :P

O PHP Conference vai acontecer nos dias 27, 28 e 29 e será recheada de PHPzeiros e Nerds. Espero conhecer muita gente boa.

Nos encontramos lá :)

Então, o audio pode ser conferido aqui.

Lars Jankowfsky é desenvolvedor PHP e participou da International PHP Conference 2008. Ele possui o Frontalaufpral onde ele fala sobre PHP, Agile Development e outros assuntos.

Deixa de papo e vamos a tradução!

Refatorando seu código legado - Parte Um: No início houve…

Como prometido, Tomas e eu iremos procurar mostrar uma visão sobre o que você precisa considerar quando você planejar refatorar suas velhas (legadas) aplicações. Não será um guia detalhado nem muito ordenado. Será mais ou menos nossas experiências e pensamentos nos últimos anos.

Se você precisa de uma introdução mais detalhada (incluindo a nível de código) você deve participar de nosso workshop na Internation PHP Conference 2008. Eu irei ministrar o workshop juntamente com dois dos melhores programadores PHP (Johann Peter Hartmann e Thorsten Rinne), você pode esperar muito mais detalhes.

Com certeza eu irei publicar a apresentação após o IPC - mas não antes ;)

Agora - Refatorando, hmm… Refatorar é, por definição, o meio de modificar (limpando) sem alterar o comportamento. Mas como você pode ter certeza que não está mudando o comportamento se você não está fazendo testes? Isto significa - você só pode refatorar um código se ele possui testes. E é aqui que começa o problema - onde está os testes?

E lá vamos nós. Vamos assumir que você possui um grande projeto - que cresceu durante anos. E agora você está na sorte que seu chefe concorda com você sobre a necessidade dos testes. Mas como iniciar? O time não possui experiência escrevendo testes. Pior ainda, nem sabem o que é Test Driven Development.

Você precisará investir um tempo no time para que eles aprendam como escrever testes. E você experimentará que conhecer e compreender são duas coisas diferentes. Na minha opinião, somente uma coisa pode ser comparada. A diferença entre programação procedural e orientada a objetos. Estranho exemplo? Não.

Deixe-me explicar. É muito fácil pegar um livro e aprender um pouco sobre classes, objetos, etc. Mas somente depois de você usar por um tempo é que você entenderá profundamente o conceito de OOP e buscar o bom senso. O mesmo é para o TDD - escrever testes é mais ou menos questão de minutos. Ou digamos horas se for o seu primeiro teste. Mas entender por quê os testes são importantes e como usá-los. Isto precisa de tempo. E você terá que investir esse tempo.

Depois de eu ter empurrado o time dentro desta direção ( e ei! - isto não foi tão fácil, como muitos desenvolvedores tendem a ser mais conservadores), eles fizeram os testes - simplesmente por quê o chefe disse isso. Mas somente poucas semanas depois, um desenvolvedor disse-me “Ei! Testes são legais! Eu encontrei um bug, eu nunca teria encontrado antes”. Este é o ponto que você precisa para o seu time.

Um pouco mais de teoria. Mas o que dizer dos testes? Por onde começar? Essa resposta é fácil. Você precisa começar com o mais sórdido, mais sujo, e maior arquivo que você pode achar no seu projeto. Eu sei, Eu sei. Eles querem começar com os arquivos mais fáceis, onde os testes são feitos rapidamente e você ver algum progresso. Os desenvolvedores realmente terão medo deste arquivo. Mas o que vai acontecer se você iniciar pelos fáceis? Simples - você verá algum progresso e terá a sensação que as coisas estão tudo bem. Seu time não entenderá os testes completamente - e eles deixam as partes mais sórdidas do código para o final. Você tem que ter forças para resolver os demônios logo no começo. Isso vai demorar um pouco. Mas então você pode ter certeza que o restante vai ser um bom e delicioso pedaço de bolo. De outro modo, você irá mover o parte do risco para o fim do período de refatoração -  e isto não é uma boa idéia.

Você poderia pensar “Esse cara é louco, onde está o problema em escrever testes…?” Ei! Nós estamos falando de velho código crescido ( == espaguete ). Este código é massivamente interconectado. Variáveis globais, classes mistas, selvagens chamadas entre módulos e objetos, etc. É muito difícil escrever testes para isto.

Na verdade, enquanto estiver escrevendo testes você notará que precisa refatorar o código. Você simplesmente tem que refatorar. Pois de outra forma você não pode escrever os testes. Ou - vamos ser honesto - você pode. Se você escrever mocks e stubs que é o triplo do tamanho do seu código. Isto é exatamente o que desenvolvedores sem experiência com TDD irão fazer. Se você ver isso - chutem eles! E em seguida novamente, por que a sensação é muito boa ;).

Cada teste leva ao refatoramento. Como o nó górdio (Vejam no wikipedia) você começará a puxar o worm, e irá puxar, puxar e puxar. E após algum tempo a refatoração estará pronta e o primeiro teste pode ser escrito. Ok, só estava brincando. Mas há alguma verdade nesta afirmação. Você precisa refatorar o código primeiro - então escrever o teste. Sem grandes stubs.

E isto será trabalhoso - especialmente no início, onde tudo está interconectado. E algumas dependencias precisam ser abordadas e resolvidas. Primeiro. Separe o modelo da visão. Na visão, deixe sem lógica - somente I/O. E então teste o modelo. Algumas pessoas até mesmo testam as visões com testes unitários. Eu não. Eu prefiro testar o modelo, com pequenas visões sem lógica e deixar o resto para os testes com selenium.

O sórdido. Leva tempo. Muito trabalho. Mas acredite em mim. Não há outra forma.

Durante a leitura, você pode ficar com a idéia de que você vai fugir com os testes de aceitação. (selenium). Você acha que isso é um bom negócio? A idéia é sensacional. Se você escrever testes do selenium para toda a aplicação - então refatorar - e você não quebrar nenhum teste, você pode ter certeza que você não alterou qualquer funcionalidade. Boa ideia? Não vai funcionar. Desculpe

Lembre-se. Eu estou falando de uma grande aplicação que cresceu. Ela terá toneladas de funcionalidades. Isto significa centenas ou milhares de testes. E estes testes podem durar muito. Eu sei disso. Eu fui até esta estrada - e ela é uma estrada de mão uníca. Nós terminamos com um teste completo rodando por 10 horas. Isso não é desenvolvimento guiado a testes. Para fazer isso que você precisa instantaneamente - instantaneamente - de feedback. Ninguém pode trabalhar assim.

Contínua na parte dois.

Essa foi a primeira parte do artigo. Mais uma vez, espero que vocês gostem. Qualquer dúvida entre em contato! Não deixe de me passar seu feedback.

Bom, eu falei um pouco sobre minha experiência com a Web 2.0 e como você pode utiliza-la para lucro (não apenas para diversão).

Eu já esperava que a maior parte do tempo nós quatro falaríamos e que em algumas partes quem estava lá, iria contribuir, mas eu não esperava que seriam umas quatro pessoas (de mais de 40). A impressão que eu tive é que essas pessoas ainda não entraram de cabeça dentro do novo mundo, ou que ainda não tiveram o interesse necessário para fazer esse tipo de coisa.

Uma coisa que eu sempre falo para todos é que vocês devem estar atentos as mudanças mundiais, acompanhar bolsa de valores, política, novas tecnologias, enfim, se manter atualizado frente ao mundo. Fazendo isso você está preparado para qualquer desafio, independente da sua área de atuação.

Bom, eu queria ter colocado algumas fotos aqui, mas ainda não achei nenhuma. Queria agradecer a todos que participaram e contribuiram para a mesa redonda, agradecer a Add4 Comunicação e a todos que fazem e fizeram parte de tudo.

Rails Database Migration - Parte I

Rails Database Migration - Parte II

Rails Database Migration - Parte III

6. Armazenando esquemas e você

6.1 Quais são os arquivos do esquema?

Migrações, poderosas como são, não são fontes autorizada para o esquema do seu banco de dados. Esse papel cabe ao schema.rb ou ao um arquivo SQL gerado pelo Active Record através da análise do banco de dados. Este arquivo não foi projetado para ser editado, ele é uma representação do estado atual do banco de dados.

Não é necessário (e isto é um erro propenso) para implantar uma nova instancia de uma aplicação repetindo o histórico inteiro da migração. É mais simples e rápido apenas carregar dentro do banco de dados a descrição do esquema atual.

Por exemplo, esta é a forma de como o banco de dados de testes é criado: o banco de dados atual de desenvolvimento é excluído (tanto para o schema.rb ou para development.sql) e então carregado dentro do banco de dados de teste.

Arquivos de esquema também são uteis se deseja olhar rapidamente quais atributos o objeto do Active Record possui. Estas informações não está no código do modelo e frequentemente está espalhado pelas várias migrações mas está resumido no arquivo de esquema. O plugin annotate_models, adiciona automaticamente cada (e atualiza) um dos comentários no início de cada modelo resumindo o esquema, que pode ser de seu interesse.

6.2 Formas de armazenar o esquema

Existe duas formas de armazenar o esquema. Uma é setar em config/environment.rb atribuindo o config.active_record.schema_format, que pode ser :sql ou :ruby.

Se :ruby é selecionada então o esquema será armazenado em db/schema.rb. Se você olhar este arquivo você verá que não encontrará um pouco mais do que uma grande migração:

ActiveRecord::Schema.define(:version => 20080906171750) do
  create_table “authors”, :force => true do |t|
    t.string   “name”
    t.datetime “created_at”
    t.datetime “updated_at”
  end

  create_table “products”, :force => true do |t|
    t.string   “name”
    t.text     “description”
    t.datetime “created_at”
    t.datetime “updated_at”
    t.string   “part_number”
  end
end

De muitas formas é exatamente isso. Este arquivo é criado pela examinação do banco de dados e expressado em estruturas usando create_table, add_index e assim por diante. Por causa da independência do banco de dados ele deve carregar dentro de qualquer banco de dados que o Active Record suporta. Isso poderia ser muito útil se você quiser distribuir a aplicação para rodar em vários banco de dados.

Existe porém uma desvantagem: schema.rb não expressa itens específicos de banco de dados como constraints de chaves estrangeiras, triggers ou stored procedures. Enquanto na migração você pode executar SQL customizadas, o esquema armazenado não pode reconstituir essas atribuições do banco de dados. Se você usar recursos como este, então você deve atribuir o esquema para :sql.

Em vez de usar o esquema de armazenamento do Active Record a estrutura será armazenada usando uma ferramenta específica do banco de dados (pela tarefa rake db:structure:dump) dentro de db/#\{RAILS_ENV\}_structure.sql. Por exemplo para o PostgreSQL a utilidade pg_dump é usada e para o MySQL este arquivo irá conter a saída de SHOW CREATE TABLE para as várias tabelas. Carregando este esquema é uma simples questão de executar as declarações SQL contida dentro.

Por definição irá fazer uma copia perfeita da estrutura do banco de dados mas isso vai impedir o carregamento do esquema dentro de outros banco de dados que não seja um dos utilizados para criá-lo.

6.3 Armazenamento de esquema e controle de código

Por causa da autoridade do código do seu esquema de banco de dados, é altamente recomendado que você verifique dentro de seu controle de código.

7. Active Record e Integridade Referencial

O Active Record é a maneira inteligente de permanecer em seus modelos, não no banco de dados. Alguns recursos como triggers ou constraints de chaves estrangeiras, que empurra alguma inteligência de volta para os banco de dados não são muito usados.

Validações como validates_uniqueness_of é uma forma de seus modelos podem valer a integridade dos dados. A opção :dependent em associações adiciona aos modelos automaticamente destruir os objetos filhos que seus pais são destruídos. Como tudo que funciona a nível de aplicação, estes não podem garantir integridade referencial e algumas pessoas aumentam com constraints de chaves estrangeiras.

Apesar de o Active Record não fornecer todas as ferramentas para trabalhar diretamente com todos os recursos, o método execute pode ser usado para executar SQL arbitrárias. Há também uma série de plugins como redhillonrails que adicionam suporte a chaves estrangeiras para o Active Record (incluindo suporte para destruir chaves estrangeiras no schema.rb)