Blog do Pedro

Jquery + Math + Flot (e html 5)

Ola pessoal, fiz um pequeno projeto usando as cancalharias citadas no titulo. A idéia é simples: montei alguns gráficos usando as principais funções trigonométricas e recursos nativos do web browser. A tarefa em si já não é muito dificil, mas com as bibliotecas citadas ser torna coisa de criança :-). E você não precisa de softwares matemáticos complexos para renderizar.

A Biblioteca Math

A biblioteca Math já provê algumas (poucas) constantes e funções que da a base para várias coisa legais. Não tem nada de muito avançado, mas já tem o básico para começar a brincadeira. Achei a seguinte tabela de referência da biblioteca no site w3schools : Math Object Properties

Property	Description
E	Returns Euler's number (approx. 2.718)
LN2	Returns the natural logarithm of 2 (approx. 0.693)
LN10	Returns the natural logarithm of 10 (approx. 2.302)
LOG2E	Returns the base-2 logarithm of E (approx. 1.442)
LOG10E	Returns the base-10 logarithm of E (approx. 0.434)
PI	Returns PI (approx. 3.14159)
SQRT1_2	Returns the square root of 1/2 (approx. 0.707)
SQRT2	Returns the square root of 2 (approx. 1.414)

Math Object Methods

Method	Description
abs(x)	Returns the absolute value of x
acos(x)	Returns the arccosine of x, in radians
asin(x)	Returns the arcsine of x, in radians
atan(x)	Returns the arctangent of x as a numeric value between -PI/2 and PI/2 radians
atan2(y,x)	Returns the arctangent of the quotient of its arguments
ceil(x)	Returns x, rounded upwards to the nearest integer
cos(x)	Returns the cosine of x (x is in radians)
exp(x)	Returns the value of E^x
floor(x)	Returns x, rounded downwards to the nearest integer
log(x)	Returns the natural logarithm (base E) of x
max(x,y,z,...,n)	Returns the number with the highest value
min(x,y,z,...,n)	Returns the number with the lowest value
pow(x,y)	Returns the value of x to the power of y
random()	Returns a random number between 0 and 1
round(x)	Rounds x to the nearest integer
sin(x)	Returns the sine of x (x is in radians)
sqrt(x)	Returns the square root of x
tan(x)	Returns the tangent of an angle

Fonte: http://www.w3schools.com/jsref/jsref_obj_math.asp

Jquery e Flot

A biblioteca Flot é uma biblioteca para plotagem de gráficos que promete funcionar em vários browsers (inclusive IE6), usando o tão falado HTML Canvas do HTML 5. Em browsers mais antigos (como o IE6) eles usam uma simulação canvas também via JS. Para maiores informações, visite a página oficial do projeto http://code.google.com/p/flot/ .

Alguns gráficos de funções

Cos, sin, tan, cotan, sec, cossec:

Parabola, Parabola (inv), Cubic, Log, Abs:

cos * (1/x) :

cos(1/sin(x)) , sin(1/cos(x)):

Para quem se interessou, coloquei todos os arquivos com os gráficos acima no meu github - http://github.com/pedrolopesme/Flot-Samples. Coloquei lá um livedemo que você passa a função e ele constrói o gráfico. Se alguém se habilitar em fazer uma coisa mais legal para plotagem de gráficos de funções rodando direto via browser, entre em contato :-)

Off - Ajuda a desabrigados no Rio após temporal

Pessoal, desculpem o off, mas é que a situação esta critica: após as chuvas torrenciais que atingiram o Rio de Janeiro, muitos lugares da nossa "cidade maravilhosa" (???) ficaram alagados, houveram deslizamentos, mortes e muita gente desabrigada. E um lugar que houve a grande parte dessas tragédias foi o Jardim Maravilha - Guaratiba. Vou anexar algumas fotos no fim do post, mas a idéia é pedir ajuda a quem puder dar uma mão pra galera de lá. Umas das formas de ajudar esse lugar é através do Instituto Beritz, que tem um trabalho de ação social já nesta região e esta trabalhando no suporte as pessoas que sofreram nesses dias de chuva. O problema é que a demanda de necessidade das pessoas nesse local aumentou muito - excedendo as capacidades do instituto. Segue um email que acabei de receber de um amigo que apoia o instituto:

Acabamos de entrar em contado com uma Agente de Saúde que está ajudando aos desabrigados do Jardim Maravilha e ela nos informou que as pessoas ainda estão chegando faltam muitas coisas. Está começando a fazer frio e existem muitas crianças em meio a famílias que perderam tudo. As maiores necessidades são: -Materiais para Dormir -Materiais para Higiene Pessoal -Materiais para as muitas crianças. Exemplos: -Colchonete -Cobertor -Roupa de Cama -Leite para Crianças -Frauda Descartável -Roupas (infantil e Adulta) -Calçados (infantil e Adulto) -Sabonete -Escova de Dente -Absorvente -Desodorante -Toalha de Banho -ETC..... Atenciosamente, Seguem algumas fotos em ANEXO. Para mais informações sobre como contribuir: alt Instituto Beritz www.institutoberitz.com secretaria@institutoberitz.com (21) 2412-9072 Rua Palmácia, 95 - 23087-420 Pedra Angula - Campo Grande Rio de Janeiro - RJ - Brasil

Fotos em melhor resolução no meu flickr

Instalando o CouchDB no Archlinux

Falando mais uma vez no CouchDB, decidi fazer um passo-a-passo para instalação do mesmo no Archlinux. Como no Wiki do projeto não existe um guia de instalação nesta distro (no donuts for you), resolvi eu mesmo fazer um. Ao longo da instalação do CouchDB no meu PC, foi fazendo log de tudo e montei o tutorial abaixo:

Resolvendo as dependências:

O Couch precisa dos pacotes abaixo. Felizmente, todas as dependências estão no repositório oficial do Arch. Como root instale:

Curl pacman -S curl
Spidermonkey pacman -S spidermonkey
Erlang pacman -S erlang
ICU pacman -S icu
Automake pacman -S automake
Autoconf pacman -S autoconf

Instalando o Couch

Uma vez instalado todas as dependências, vamos ao Couch propriamente dito. Primeiro, temos que baixar o source :

wget http://ftp.unicamp.br/pub/apache/couchdb/0.11.0/apache-couchdb-0.11.0.tar.gz
tar xf apache-couchdb-0.11.0.tar.gz
cd apache-couchdb-0.11.0

Caso o link acima do Couch não esteja funcionando ou você queira outra versão, acesse a página de downloads do Couch e repita os passos acima com a versão desejada. Agora é configurar e instalar:

configure -prefix=/
make

e finalmente como root: sudo make install Fazendo isso o couchdb já estara instalado. Agora, precisamos criar um usuário e dar as permissões necessárias:

sudo useradd couchdb
sudo chown -R couchdb:root /var/log/couchdb
sudo chown -R couchdb:root /var/lib/couchdb

Para facilitar sua vida adicione o Couch na bandeja de inicialização do sistema. Como root, abra o arquivo /etc/rc.conf e adicione o couchdb nos DAEMONS DAEMONS=( ... couchdb ... ) Pronto. Seu CouchDB esta instalando e na bandeja de inicialização. Parr ver não ter que reiniciar o computador para ver o Couch rodando, inicie-o manualmente com o comando: /etc/rc.d/couchdb start Agora vá no browser e acesse o Futon através do endereço http://localhost:5984/_utils/ . Desse ponto em diante será tema para outros posts!

Tradução do artigo sobre Integração Contínua

O texto abaixo é a uma tradução autorizada do artigo escrito pelo Martin Fowler. Para acessar a versão original em inglês, clique aqui . Caso você tenha sujestões para tornar a tradução melhor, compartilhe através da seção de comentários no final da página. The text bellow is an authorized translation of the article written by Martin Fowler. To access the original english version, click here . If you have any sujestion to make the translation better, share it via comments section at the end of the page.

Construindo um componente usando Integração Continua

Para mim, a forma mais fácil de explicar o que Integração Contínua (IC) é e como trabalha é mostrando um pequeno exemplo de como isso funciona com o desenvolvimento de uma pequena parte do sistema. Vamos assumir que eu tenho que fazer alguma coisa para uma parte do sistema, não importa realmente que tarefa é - por enquanto vou supor que isso é pequeno e que pode ser feito um poucas horas ( vamos explorar tarefas maiores e outros problemas mais tarde ). Começo pegando uma cópia atual do código fonte e colocando na minha máquina de desenvolvimento. Faço isso utilizando um sistema de controle de código para ter uma cópia de trabalho a partir do código principal. O parágrafo acima irá fazer sentido para pessoas que usam sistema de controle de código, mas não será para aqueles que não usam. Então deixe-me explicar rapidamente: um sistema de controle de código mantém todo o código fonte de um projeto em um repositório. O estado atual do sistema geralmente é chamado de mainline( ou linha principal). Em qualquer momento um desenvolvedor pode fazer uma cópia da versão principal em sua máquina, e isso é chamado de check out. A cópia em uma máquina de um desenvolvedor é chamada de cópia de trabalho (na maior parte de tempo você estará atualizando sua cópia de trabalho junto a principal). Agora eu pego minha cópia de trabalho e faço o que preciso para completar minha tarefa. Isso irá consistir em alterar o código de produção e também adicionar ou alterar os testes automatizados. Integração Contínua assume um alto nível de testes que são automatizados no software: uma facilidade que eu chamo de self-testing code ( ou código auto-testável). Frequentemente estes usam uma versão da popular framework de teste xUnit. Um vez que eu terminei (e isso geralmente acontece em vários lugares quando eu estou trabalhando), eu faço uma build (ou desenvolvimento de uma versão) automatizada na minha máquina de desenvolvimento. Assim, o código fonte em minha cópia de trabalho é pego, compilado e transformado em um executável - e então é executado os testes automáticos. Somente se todas as builds e testes não tiverem erros que tudo será considerado bom. Com uma boa build, eu posso então pensar em colocar minhas alterações no repositório. A questão é, claro, que outras pessoas podem fazer (e geralmente fazem) mudanças na versão principal antes de eu ter a chance de fazer um commit ( ou atualizar o repositório principal com a minha versão do código). Sendo assim, primeiro eu atualizo minha cópia de trabalho com as mudanças feitas pelos outros e crio uma nova build. Se as mudanças deles chocarem com as minhas mudanças, será exibido erros tanto na compilação quanto nos testes. Neste caso é minha a responsabilidade de corrigir estes erros e repetir o processo até que minha cópia local esteja sincronizada com a versão principal. Uma vez que tenho as alterações na minha própria build de uma cópia devidamente sincronizada eu posso finalmente fazer o commit na versão principal, que atualiza o repositório. Entretanto meu commit não termina meu trabalho. Nós fazemos uma build novamente, mas agora em uma maquina de integração baseada na versão principal do código. Somente com o sucesso desta build poderemos dizer que as minhas alterações foram feitas. Sempre existe uma chance de eu ter esquecido alguma coisa na minha máquina e o repositório não ser atualizado corretamente. Somente quando minha build de alterações for lançada com sucesso na máquina de integração é que o meu trabalho terminou. A build de integração pode ser executada manualmente por mim ou ser feita automaticamente usando o Cruise. Se um choque ocorrer entre as versões de dois desenvolvedores, isso geralmente é pego quando o segundo desenvolvedor atualizar sua cópia local com as builds feitas pelos outros. Caso não, a build de integração deve falhar. De qualquer modo o erro é detectado rapidamente. Nesse momento a tarefa mais importante é consertar os problemas, e fazer sua build voltar a funcionar corretamente. Em um ambiente de Integração Contínua você nunca deve ter uma build de integração com falhas por muito tempo. Um bom time deve ter muitas builds corretas por dia. Más builds podem ocorrer de tempos em tempos, mas devem ser consertadas rapidamente.

Práticas da Integração Contínua

A história anterior é uma apresentação da Integração Contínua e de como ela funciona diariamente. Colocar isso tudo pra funcionar sem problemas envolve obviamente mais coisas do que foi dito. Eu vou focar agora em práticas chaves que efetivarão a IC .

Manter um único repositório de código.

Projetos de softwares envolvem vários arquivos que precisam serem "orquestrados" juntos para se construir um produto. Manter todos esse arquivos exige um grande esforço, particularmente quando existem várias pessoas envolvidas. Logo não é surpresa que através de anos equipes de desenvolvimento tem construído ferramentas para gerenciar tudo isso. Estas ferramentas - chamadas de ferramentas de gerenciamento de código fonte, gerenciamento de configuração, sistema de controle de versão, repositórios ou outros nomes - são uma parte integrante na maioria dos projetos de desenvolvimento. A triste e surpreendente questão é que essas ferramentas não fazem parte de todos os projetos. Isto é raro, mas eu participo de projetos que não usam algo como um sistema mas usam um combinação confusa de drivers locais e compartilhados. Portanto, como um passo fundamental, tenha certeza de usar um sistema decente de controle de código fonte. Custo não é um problema por causa da boa qualidade das ferramentas open-source disponíveis. O repositório open-source atual que escolho é o Subversion ( o antigo CVS continua sendo usado largamente, e ainda é bem melhor que nada, mas o Subversion é uma escolha moderna). É interessante como eu converso com desenvolvedores e descubro que a maioria dos gerenciadores de código fonte comerciais são menos aceitos que o Subversion. A única ferramenta que eu tenho ouvido pessoas falarem que é digna de ser paga é o Perforce. Uma vez que você tenha um sistema de gerenciamento de código fonte, tenha certeza de que isso esteja em um lugar conhecido por todos, para pagarem o código fonte. Ninguém deve sequer perguntar "Onde estão os arquivos?". Tudo deve estar no repositório. Embora muitos times usem repositórios, um erro comum que vejo é que eles não colocam tudo no repositório. Se as pessoas usam um repositório, eles vão por o código lá, mas tudo que você precisa para fazer uma build deve estar incluído la: scripts de teste, arquivos de configuração, esquema de banco de dados, scripts de instalação e bibliotecas de terceiros. Eu conheci projetos que colocavam seus compiladores no repositório (importante nos dias antigos de vários compiladores de C++). O regra básica é que você consiga por o projeto em uma máquina virgem, fazer um checkout (ou pegar uma cópia de todo o código) e conseguir rodar o sistema completamente. Somente poucas coisas devem ser feitas na máquina virgem - geralmente coisas que são estáveis, grandes e complicadas de instalar . Um sistema operacional, ambiente de desenvolvimento Java ou sistema básico de banco de dados são exemplos típicos. Você precisa por tudo que a build precisa no sistema de controle de código, entretanto você pode por também outros materiais com que as pessoas geralmente trabalham. Configurações de IDE são boas para colocar lá porque este é um modo fácil para as pessoas compartilharem as mesmas configurações. Outra característica dos sistemas de controle de versão é que eles permitem você criar múltiplos branches (ou linhas de desenvolvimento) , para manipular diferentes fluxos de desenvolvimento. Isso é uma característica útil, quer dizer essencial - mas frequentemente é usada de maneira abusiva o que coloca as pessoas em problemas. Reserve-se a usar os branches ao mínimo. Tenha uma versão principal: um único branch do projeto atualmente em desenvolvimento. Basicamente todos devem trabalhar fora desta linha principal a maior parte do tempo ( um número considerável de branches são correção de bugs de uma versão futura e experimentos temporários). Geralmente você deve guardar no controle de código tudo que você precisa para executar tudo, mas nada do que você já executou. Algumas pessoas guardam os produtos das builds no controle de código, mas eu considero que isso é um sinal, uma indicação de um problema mais profundo, geralmente uma incapacidade para recriar as builds confiantemente.

Automatize a Build

Frequentemente pegar os fontes e transformá-los em um sistema rodando é um processo complicado envolvendo compilação, movimentação de arquivos, carregar schemas nas bases de dados e por ai vai. Entretanto, boa parte das tarefas nesta parte do desenvolvimento de software pode ser automatizada - e portanto deve ser automatizada. Pedir pessoas para digitarem comandos estranhos ou clicar em caixas de dialogo é uma perda de tempo e uma forma suscetível a reprodução de erros. Ambientes automatizados de builds são características comuns de sistemas. O mundo Unix tem feito isso há décadas, a comunidade Java desenvolveu o Ant, a comunidade .NET desenvolveu o Nant e agora tem o MSBuild. Esteja certo de que você pode gerar e lançar o seu sistema rodando os scripts em um único comando. Um erro comum é não colocar tudo na build automatizada. A build deve incluir pegar o schema do banco de dados do repositório e colocá-lo no ambiente de execução. Eu vou elaborar minha regra anterior: qualquer um deve ser capaz de ir para uma máquina virgem, pegar as fontes do repositório, emitir um único comando e ter um sistema rodando na sua máquina. Scripts de build podem ter varias formas e frequentemente são particulares a uma plataforma ou comunidade, mas eles não necessariamente ter que ser assim. Embora a maioria dos nossos projetos são em Java e usam o Ant, alguns tem usando Ruby ( o sistema Ruby Rake é um script build muito bom). Nós tivemos bons resultados automatizando um projeto anterior usando Microsoft COM com o Ant. Dependendo do que você precisa, você pode querer que diferentes tipos de coisas estejam na build. Você lançar um sistema com ou sem código de teste, ou com diferentes conjuntos de testes. Alguns componentes podem ser construídos isoladamente. Um script de build deve permitir você usar métodos alternativos em casos diferentes. Muitos de nós usamos IDEs, e a maioria das IDEs tem algum tipo de processo de gerenciamento de build dentro delas. Entretanto esses arquivos são sempre proprietários a IDE e frequentemente frágeis. Além disso eles necessitam da IDE para funcionar. Não existe problema se os usuários da IDE configurarem seus próprios arquivos de projetos e usarem para o desenvolvimento individual. Entretanto é essencial ter uma build principal que é usável em um servidor e executável a partir de outros scripts. Logo, em um projeto Java nós estamos livres para ter desenvolvedores fazendo a build em seus IDEs, mas a build principal deve usar o Ant para assegurar que isso possa rodar um servidor de desenvolvimento.

Faça sua Build ser auto-testável

Tradicionalmente uma build significa compilação, linkagem e todo o material adicional necessário para ter um programa executando. Um programa pode rodar, mas isso não significa que foi feito da maneira certa. Linguagens modernas estaticamente tipadas podem achar muitos bugs, mas alguma coisa pode acabar passando desapercebida. Um bom modo para pegar erros mais rápida e eficientemente é incluir testes automáticos no processo de build. Testes não são perfeitos (claro), mas eles podem pegar muitos bugs - o suficiente para ser útil. Leitores regulares do meu trabalho irão notar que sou um grande fã de TDD e XP, entretanto eu quero ressaltar que nenhuma dessas abordagens são necessárias para ganhar os benefícios de um código auto-testável. Ambas as abordagens acertam que se escreva testes antes que você escreva o código, para então fazer os testes passarem - desta forma os testes exploram muito mais o design do sistema do que capturam erros. Isto é uma coisa boa, mas não é necessariamente do propósito da IC, onde nós temos requisitos mais fracos de código auto-testável (embora TDD é minha maneira preferida de produzir código auto-testável). Para ter o código auto-testável você necessitará de uma suite de testes automatizados que possa checar uma grande parte da base do código para achar problemas. Os testes necessitam estar aptos para rodarem com um simples comando e serem checados automaticamente. O resultado da suite dos testes em execução deve indicar se estes falharam. Para uma build ser auto-testável a falha de um teste deve fazer com que a build falhe. Através dos últimos anos em que o TDD tem crescido, ele popularizou a família de ferramentas open-source xUnit que são ideais para esse tipo de teste. As ferramentas xUnit tem sido muito valorosa para nós na ThoughtWorks e eu sempre sugiro as pessoas que as usem. Estas ferramentas, que teve Kent Beck como pioneiro, tornam fácil para você configurar um ambiente completo para testes automatizados. Ferramentas xUnit são certamente o ponto inicial para tornar seu código auto-testável. Você deve também procurar por outras ferramentas que focam em testes mais voltados ao software em funcionamento. Atualmente, existem um grande número delas, incluindo FIT, Selenium, Sahi, Watir, FITnesse e muitas outras que eu não vou listar aqui.

Cada um lança suas modificações todos os dias.

Integração antes de tudo trata sobre comunicação. Integração permite os desenvolvedores dizerem uns aos outros sobre as alterações que eles fizeram. Frequentemente comunicação permite pessoas descobrirem rapidamente como as alterações aconteceram. O único pré-requisito para um desenvolvedor lançar suas alterações na versão principal é que ele ele consiga executar perfeitamente o código. Isso claro, inclui passar pelos testes da build. Como com qualquer ciclo de lançamento de código, o desenvolvedor primeiro atualiza sua cópia de trabalho para coincidir com a versão principal, resolve qualquer conflito e então gera a build em sua máquina local. Se a build passar, então ele estará liberado para lançar suas alterações na versão principal. Fazendo isso frequentemente, os desenvolvedores irão encontrar rapidamente se existe algum conflito entre as versões. O segredo para solucionar problemas rapidamente é encontrá-los rapidamente. Com desenvolvedores lançando suas alterações a cada hora, um conflito pode ser detectado dentro de poucas horas desde seu acontecimento, e em um ponto não muito avançado - o que o torna fácil de ser solucionado. Conflitos que não são detectados por semanas podem ser difíceis de serem resolvidos. O fato de que você gerou uma build quando você atualizou sua cópia de trabalho significa que você detectou os problemas de compilação como também conflitos textuais. Desde que a build seja auto-testável, você também detecta conflitos no código em execução. Os últimos conflitos são conflitos particularmente incômodos de se encontrar se eles persistirem não detectados por um longo tempo em seu código. Desde que existam apenas algumas horas de diferença entre os commits, existem apenas alguns locais onde o problema pode estar se escondendo. Além disso, desde que muita coisa não tenha sido mudada, você pode usar um diff-debugging para lhe ajudar a encontrar o problema. Minha regra geral é que cada desenvolvedor deve atualizar o repositório todo dia. Na prática, geralmente é útil os desenvolvedores lançarem suas atualizações com mais frequência que uma vez ao dia. Quanto mais frequentemente você fizer um commit, menos lugares você terá que procurar por erros de conflito, e mais rapidamente você os consertará. Commits frequentes encorajam os desenvolvedores a quebrar seus trabalhos em pequenos pedaços de poucas horas cada. Isso ajuda a dividir o progresso e causa um senso de progresso. Frequentemente as pessoas começam sentir que não conseguem fazer alguma coisa significativa em poucas horas, mas nós temos encontrado que esta teoria e prática ajudam os desenvolvedores a aprender.

Cada commit deve atualizar o repositório principal em uma máquina de integração

Usando commits diariamente, um time tem builds frequentemente testadas. Isso deveria significar que o repositório principal esta em um estado saudável. Na prática, entretanto, coisas continuam dando errado. Um razão é a disciplina: pessoas não estão atualizando suas versões e fazendo uma build antes de fazerem seus commits. Outra é que existem diferenças de ambiente entre as máquina dos desenvolvedores. Como uma possível solução você deve assegurar que as builds ocorram em uma máquina de integração e somente se a build de integração passar com sucesso é que o commit deve ser considerado feito. Levando em consideração que o desenvolvedor que realiza o commit deve ser responsável pelo mesmo, ele precisa monitorar o repositório principal para que possa corrigir qualquer problema que possa ocorrer. A consequência desta responsabilidade é que ele não deve ir para casa até que a build do repositório principal tenha passado por qualquer commit ele tenha realizado durante o dia. Existem duas formas principais que eu vejo para assegurarmos que isso ocorra: usando um processo manual de build ou um servidor de integração contínua. Descrever a abordagem da build manual é simples. Essencialmente ela é similar a build local que um desenvolvedor faz antes de lançar suas alterações no repositório. O desenvolvedor vai para a máquina de integração, checa a versão do repositório principal ( que é o último commit feito da casa) e faz a build de integração. Ele verifica todo este processo, e se a build for feita com sucesso ele finaliza seu commit (veja também a descrição de Jim Shore's). Um servidor de integração contínua age como um monitor para o repositório. Toda vez que um commit é feito no repositório o servidor automaticamente checa as fontes na máquina de integração, inicia a build, e notifica para quem fez o commit o resultado da build. Quem fez a build não a considera terminada enquanto ele não recebe uma notificação - geralmente por e-mail. Na ThoughWorks, nós somos grandes fãs de servidores de integração contínua - na verdade nós gerenciamos o desenvolvimento original do CruiseControl e do CruiseControl.NET, um servidor open-source de IC largamente usado. Desde então nós também construímos o servidor de IC comercial chamado Cruise. Nós usamos um servidor de IC quase que com todos os projetos que nós fazemos, e temos sido muito felizes com os resultados. Nem todos preferem usar um servidor de IC. Jim Shore deu uma boa descrição do porquê ele prefere uma abordagem manual. Eu concordo com ele que IC é muito mais que somente a instalação de qualquer software. Todas as práticas citadas aqui são feitas efetivamente na IC. Mas igualmente muitos times que fazem IC acharão bom um servidor de IC para ser uma ferramenta útil.Muitas organizações fazem builds regulares em um tempo marcado, tipo toda noite. Isso não é a mesma coisa como uma build contínua e não é o suficiente para a IC. O ponto principal da IC é ajudar a encontrar os problemas o mais rápido possível. Builds noturnas significam que os erros ficam desapercebidos durante um dia inteiro antes que qualquer um os descubram. Uma vez que eles ficam muito tempo no sistema, eles demoram um longo tempo para serem encontrados e removidos. O ponto chave de se ficar fazendo a build de integração é que se a build do repositório principal falhar, ela será corrigida no jeito certo. A idéia central de se estar trabalhando com a IC é que você sempre desenvolve em uma base conhecida e estável. Não é uma coisa ruim a build do repositório principal falhar, embora se isso acontecer o tempo todo é sinal que as pessoas não estão sendo cuidadosas o suficiente em atualizar e realizar a build localmente antes de realizarem o commit. Quando a build do repositório principal quebrar, entretanto, é importante que seja corrigida rapidamente. Para ajudar a evitar o quebramento do repositório principal, você pode considerar usar uma pending head. Quanto as equipes que são iniciantes na IC, frequentemente esta é uma das coisas mais difíceis para se resolver. Uma equipe deve lutar para o quanto antes conseguir ter o hábito de trabalhar em builds da versão principal, particularmente se ela estiver trabalhando sobre uma base existente de código. Paciência e constância geralmente são boas dicas, portanto não desista.

Mantenha a Build rápida

O foco da IC é prover um feedback rápido. Nada é mais prejudicial as atividades da IC que uma build que toma muito tempo. Neste ponto eu tenho que admitir que existia um pouco de velho cara que considerava que uma build tinha que ser longa. A maior parte dos meus colegas consideram que uma build de uma hora é totalmente sem sentido. Eu me lembro de equipes sonhando que poderiam fazer isso tudo muito rápido e que ocasionalmente eles continuam rodando certos casos onde é muito difícil ter builds nesta velocidade. Para a maior parte dos projetos, entretanto, a linha de build do XP de 10 minutos é, com razão, perfeita. A maioria dos nossos projetos modernos conseguem atingir isso. Isto é digno de se concentrar esforços para fazer com que aconteça, porque a cada minuto que você reduz o tempo da build é um minuto salvo para cada desenvolvedor a cada momento que ele realiza um commit. Uma vez que a IC demanda commits frequentes, ela economiza muito tempo. Se você estiver começando com uma build de uma hora, começar a fazer a build cada vez mais rápido pode parecer intimidante. Isso pode até mesmo ser assustador começar a trabalhar em um projeto novo e pensar em manter as coisas rápidas. Para aplicações empresariais, ao menos, nos temos visto que o principal gargalo é testar - particularmente testes que envolvam serviços externos como uma base de dados. Provavelmente o ponto mais importante é começar trabalhando na configuração de uma staged build (ou build por estágios, ou também build encadeada). A idéia por trás de uma staged build é que existe de fato multiplos builds feitas em sequência. O commit no repositório principal aciona a primeira build, que eu chamo de commit build. A commit build é a build que necessitou ser executada quando alguém atualizou o repositório principal. A commit build é a que tem que ser feita rapidamente, como consequência esta tomará alguns atalhos que diminuirão a capacidade de se achar bugs. O truque é balancear a necessidade de procurar bugs e a velocidade para que haja uma commit build estável o suficiente para que outras pessoas possam trabalhar. Uma vez que a commit build é boa, então outras pessoas podem trabalhar no código com confiança. Entretanto existem testes novos e lentos que você pode começar a fazer. Máquinas adicionais podem rodar novas rotinas de testes na build que precisa de mais tempo. Um exemplo simples disto é uma build de dois estágios. O primeiro estágio deve realizar a compilação e rodar os testes que são mais focados nos testes unitários com a base de dados vazia. Tais testes podem rodar muito rápido, dentro da linha de 10 minutos. Entretanto qualquer problema que envolva uma escala maior de interações, particularmente aqueles envolvendo a base de dados real, não serão encontrados. O segundo estágio roda em uma suite diferente de testes que acessam a base de dados real e envolve um comportamento de ponta-a-ponta. Essa suite pode tomar algumas horas para rodar. Neste cenário as pessoas usam o primeiro estágio com a commit build e a usam para os seus ciclos principais da IC. O segundo estágio é formado por uma build secundária que roda quando possível, pegando os executáveis da ultima build válida para novos testes. Se a build secundária falhar, então isto não terá o mesmo "pare tudo", mas o time precisa ter o objetivo de corrigir os problemas tão rápido quando possível, enquanto mantem funcionando a build de commit. Na verdade a build secundária não tem que ser sempre boa, tão logo os problemas sejam identificados e tratados em poucos dias. Como neste exemplo, as builds secundárias são frequentemente testes puros, desde que estes testes causem lentidão. Se a build secundária detectar um problema, isso é um sinal que a commit build poderia fazer outro teste. Assegure-se o tanto quanto possível que qualquer falha na build secundária te leve a novos testes na commit build onde você deve pegar o problema, para que os problemas fiquem corrigidos na commit build. Desta forma os testes de commit são reforçados sempre que alguma coisa passar por eles. Existem casos onde não existem como construir um teste que rode rápido e que exponha o erro, então você pode decidir somente testar aquela condição na build secundária. Felizmente, na maior parte do tempo, você pode adicionar testes apropriados para a commit build. Este exemplo é de uma build de dois estágios, mas o principio básico pode ser extendido para qualquer número de builds posteriores a principal. As builds posteriores a commit build pode também serem feitas em paralelo, então se você tem duas horas de testes secundários você pode melhorar o tempo e resposta do processo tendo duas máquinas que rodam metade dos testes cada. Usando builds secundárias paralelas desta forma você pode introduzir todos tipo de novos testes automáticos, incluindo teste de performance, dentro do processo regular de build (eu tenho rodado muitas técnicas interessantes como essa assim que visitei muitos projetos da ThoughtWorks nos últimos anos - e estou esperançoso para incentivar alguns dos desenvolvedores a escreve-las).

Teste em uma cópia do ambiente de produção

O ponto central dos testes é trazer a tona, dentro de condições controladas, qualquer problema que o sistema vai ter em produção. Um parte significante disto é que o ambiente onde eles irão rodar deve ser como o de produção. Se você testar em um ambiente diferente, toda diferença resultará no risco das situações sob teste não acontecerem em produção. Uma solução para isso é que você configure seu ambiente de teste, dentro possível, para ser uma cópia exata do seu ambiente de produção. Use o mesmo software de banco de dados, com as mesmas versões, use a mesma versão do sistema operacional. Bote todas as bibliotecas que estão no ambiente de produção para o ambiente de teste, mesmo que o sistema atualmente não as use. Use o mesmo endereço IP e portas, rodando no mesmo hardware. Bom, na verdade existem limites. Se você esta escrevendo um software desktop não é prático testar em uma cópia em todos os desktops possíveis com todas as partes terceirizadas do software que as diferentes pessoas estão rodando. Da mesma forma, alguns ambientes de produção podem ser caras demais para serem duplicadas (embora eu tenho encontrado frequentemente falsas economias não duplicando ambientes nem tão caros assim). Apesar destes limites, seu objetivo deve continuar sendo duplicar o ambiente de produção tanto quanto possível e entender que os riscos que você estará aceitando por cada diferença entre os ambientes de teste e produção. Se você tem uma configuração boa e simples, sem ter que fazer muitas comunicações incomodas, você pode rodar sua commit build em um ambiente copiado. Frequentemente, entretanto, você necessitará fazer testes duplos, porque os sistemas responderão lenta ou intermitentemente. Como um resultado, é comum ter um ambiente muito artificial para os tests de commit, e usar uma cópia da produção para os testes secundários. Eu tive notícias em um crescente interesse em usar virtualização para tornar fácil juntar ambientes de testes. Máquinas virtuais podem ser salvas com todos os elementos necessários juntos na virtualização. É relativamente simples instalar a última build e rodar os testes. Além disso, isto permite a você rodar multiplos testes em uma máquina, ou simular várias máquinas em uma rede com uma única máquina. Como o ônus da performance tem diminuido, esta opção faz cada vez mais sentido.

Torne fácil para qualquer um ter o último executável.

Uma das partes mais difíceis de desenvolvimento de software é ter certeza de que você esta construindo o software certo. Nós temos visto que é muito difícil especificar adiantadamente o que você quer e estar correto. Pessoas acham mais fácil ver algo que não é bom o bastante e dizer como isto precisa ser alterado. Os processos de desenvolvimento ágeis incentiva explicitamente e tomam vantagem desta parte do comportamento humano. Para ajudar a fazer este trabalho, qualquer um envolvido com um projeto de software deve ser hábil para ter a última versão executável e ser capaz de roda-la: para demonstrações, testes exploratórios ou simplesmente ver o que mudou esta semana. Faça isto ser bem simples: tenha certeza que existe um bom lugar conhecido onde as pessoas possam pegar o último executável. Pode ser útil pôr muitos executáveis em um lugar comum. Para a versão mais recente você deve por o último executável que passou nos testes de commit - como um executável, ele deve ser estável. Se você estiver seguindo um processo com iterações bem definidas, geralmente é sábio por também junto o resultado final das builds da iteração. Demostrações, em particular, precisam do software cuja as características são familiares, então geralmente vale a pena por a última versão para alguma coisa necessária para quem estiver mostrando o software

Todos pode ver o que esta acontecendo.

Tudo sobre Integração Contínua esta relacionado a comunicação, então você precisa ter certeza que todos possam facilmente ver o estado do sistema e as mudanças que tem sido feitas nele. Uma das coisas mais importantes para se comunicar é o estado da build da versão principal. Se você estiver usando o Cruise existe uma ferramenta embutida no site dele que irá mostrar a você se existe uma build em progresso e o qual foi o estado da última build da versão principal. Muitos times gostam de fazer esta informação chamar mais a atenção colocando um display mostrando o sistema de build - com as populares luzes verde (quando a build funciona) e vermelha (quando ela falha). Um jeito particular é por algo como as lampadas de lava verde e vermelha - não somente para indicar o estado da build mas também para indicar por quanto tempo tem permanecido cada estado. Bolhas em uma lâmpada vermelha indica que a build tem quebrado por muito tempo. Cada time faz suas próprias escolhas sobre esses sensores da build - é bom ser informal com sua escolha (recentemente eu vi alguém experimentando por um coelho dançando). Se você estiver usando um processo de IC manual, a visibilidade deste continua sendo essencial. O monitor da máquina de build pode mostrar o status da build da versão principal. Frequentemente você tem algo para ser posto na mesa de qualquer um que esteja fazendo atualmente a build (novamente alguma coisa boba como uma galinha de borracha é uma boa opção). Geralmente as pessoas gostam de fazer um som simples avisando boas builds, como um som de um sino. As páginas dos servidores de IC pode trazer mais informações que estas, claro. Cruise oferece um indicador não somente de quem esta fazendo a build, mas quais mudanças ele fez. Cruise também provê um histórico de mudanças, permitindo membros da equipe ter uma boa informação das recentes atividades no projeto. Eu conheço equipes que gostam de usar isto para ter um senso do que as pessoas tem feito e manter uma idéia das mudanças feitas no sistema. Outra vantagem de usar um site é para aqueles que não estão próximos fisicamente poderem ter uma idéia do status do projeto. Normalmente eu prefiro ter todos que estão trabalhando ativamente no projeto juntos, mas geralmente existem pessoas longes onde seja bom que tenham idéia de como as coisas estão. O site também é útil para as equipes para manter junto informações de builds de vários projetos - gerando um status simples e automático dos diferentes projetos. Um bom painel de informações não são somente aqueles em uma tela de computador. Um dos meus painéis favoritos foi de um projeto que estava começando na IC. Ele tinha uma história longa de problemas em fazer builds estáveis. Nós colocamos um calendário na parede que mostrava um ano inteiro com um pequeno quadrado para cada dia. Todo dia o grupo de controle de qualidade (QA) colocaria um adesivo verde quando recebia uma build estável que passou nos testes, ou, colocaria um adesivo vermelho. Com o passar do tempo o calendário revelou que o estado do processo de build mostrava um crescimento estável até que os quadrados verdes eram tão comuns que o calendário desapareceu - com seu propósito cumprido.

Automatize a Implantação do Sistema

Para fazer a Integração Contínua você precisará de multiplos ambientes, um para rodar os testes de commit (ou commit build), um ou mais para rodar os testes secundários. Uma vez que você esteja movendo os executáveis entre estes ambientes várias vezes por dia, você vai querer fazer isso automaticamente. Então é importante ter scripts que permitam você implantar a aplicação dentro de qualquer ambiente facilmente. Uma consequência natural disto é que você deve ter scripts que permitam você implantar o software dentro do ambiente de produção tão facilmente quanto nos outros ambientes. Você pode não implantar o software no ambiente de produção todos os dias (embora em tenho rodado projetos em que isso aconteça), mas implantações automáticas ajudam tanto a tornar o processo mais rápido quanto a reduzir erros. E isto é também uma opção barata desde que você use somente as mesmas configurações que você usa nos deploys dos ambientes de teste . Se você implantar alguma função extra no ambiente de produção você deve checar se isto terá um rollback (ou reverter) automático. Coisas ruins podem acontecer de tempos em tempos, e se algo não der certo é bom ser capaz de desfazer rapidamente tudo para a última versão boa conhecida. Ser capaz de reverter automaticamente também reduz muita tensão durante a implantação, encorajando as pessoas a realizarem deploy ( entrega e implantação de uma versão) com mais frequência e assim ter novas funcionalidades para entregarem para os usuários rapidamente. ( A comunidade Ruby on Rails desenvolveu uma ferramenta chamada Capistrano que é um bom exemplo de uma ferramenta que faz esse tipo de coisa). Em ambientes em cluster nós temos visto processos de implantação acontecerem onde um novo software é implantando em um nó por vez, substituindo gradualmente a aplicação durante o curso de poucas horas. Veja o artigo relacionado Evolutionary Database Design. Um empecilho para muitas pessoas que fazem releases frequentes é a migração de banco de dados. Mudanças na base de dados são dolorosas porque você não pode simplesmente mudar os schemas do banco de dados, você tem também que assegurar que os dados migraram corretamente. Este artigo descreve técnicas usadas por meu colega Pramod Sadalage para fazer a refatoração automática e a migração dos bancos de dados. O artigo é uma tentativa rápida de captar a informação descrita em maiores detalhes pelo livro do Pramod e Scott Amblers sobre refatoração de banco de dados. Uma variação particular e interessante disto que eu tenho visto surgir com a aplicação web pública é a idéia de implantar uma versão limitada para um grupo menor de usuários. O time então vê como essa versão limitada é usada antes de decidir se implantada o sistema para todos os usuários. Isto permite você testar novas funcionalidades de interfaces com o usuário antes de prosseguir para uma versão final. Implantação automatizada aliada a uma boa disciplina de IC é essencial para fazer isso funcionar.

Benefícios da Integração Contínua

Olhando isso tudo eu penso que o maior e mais abrangente benefício da Integração Contínua é a redução de riscos. Minha mente continua flutuando de volta para aquele projeto de software anterior que eu mencionei no meu primeiro paragrafo. La as pessoas estavam no final (ao menos acreditavam) de um longo projeto, sem ainda uma idéia real de quão longo isto deveria ser antes de terem terminado. O problema com aquela forma de integração narrada é que é muito difícil saber o quão longa ela será, e o pior é que é muito difícil saber o quão longe você terá que ir neste processo. O resultado é que você esta pondo completamente a si mesmo em um ponto cego justamente em uma das partes mais tensas do projeto - mesmo que você esteja em um dos raros casos de ainda não estar atrasado. Integração Contínua reduz completamente este problema. Não existe uma integração longa, você elimina completamente o ponto cego. Em todo tempo você sabe onde você esta, o que funciona, o que não funciona e os bugs pendentes que você tem em seu sistema. Bugs - estes são as coisas sórdidas que destroem a confiança, bagunçam os cronogramas e as reputações. Bugs no software implantando fazem os usuários ficarem com raiva de você. Bugs no trabalho em progresso entram em seu caminho, tornando difícil ter o resto do software funcionando corretamente. Integração Contínua não nos livra dos bugs, mas os tornam dramaticamente mais fáceis de encontrar e remover. O grande responsável por este aspecto é o código auto-testável. Se você introduzir um problema e detecta-lo rapidamente, é mais fácil remover os problemas. Desde que você modificou somente uma parte pequena do sistema, você não tem que olhar muita coisa. Desde que aquele pedaço do sistema é o pedaço com que você trabalhou, ele ainda esta fresco em sua memória, novamente tornando fácil de encontrar o problema. Você também pode usar um diff debugging (ou um avaliador de diferenças) - comparando a versão corrente do sistema com uma versão anterior que não tinha o bug. O bugs também são cumulativos. Quanto mais bugs você tiver, mais difíceis são se serem removidos. Em parte isto acontece porque você tem interações entre os bugs, onde as falhas são apresentadas como o resultado de múltiplos erros - tornando cada erro cada vez mais difícil de ser encontrado. E isto também é psicológico - pessoas tem menos energia para encontrar e eliminar os bugs quando existem vários deles - um fenômeno que os programadores pragmaticos chamam de síndrome da Janela Quebrada. Para uma resposta a isso, projetos com IC tendem a ter dramaticamente menos bugs, tanto em produção quanto em desenvolvimento. Entretanto eu devo ressaltar que o grau deste benefício esta diretamente amarrado a quão boa sua suite de testes é. Você deve entender que não tão difícil construir uma suite de teste que faça uma diferença notável. Geralmente, entretanto, leva um tempo antes que o time consiga chegar ao mesmo nível dos bugs que eles tem que procurar. Avançar este nível envolve trabalhar constantemente e melhorar seus testes. Se você trabalha com IC, este remove uma das maiores barreiras na implantação frequente. As frequentes implatações são valorosas porque elas permitem seus usuários terem as novas funcionalidades mais rapidamente, para darem feedback mais rapidamente sobre estas funcionalidades e geralmente se tornarem mais colaborativos no ciclo de desenvolvimento. Isto ajuda a quebrar as barreiras entre os desenvolvedores e os clientes - barreiras que eu acredito serem as maiores barreiras para desenvolvimento de software com sucesso.

Introduzindo a Integração Contínua

Então você imagina tentar a Integração Contínua - por onde você começa? Eu mostrei acima todo o conjunto de práticas para te mostrar todos os benefícios - mas você não precisa começar com tudo isso. Não existe uma aqui receita fixa - muita coisa depende da natureza do seu ambiente e do seu time. Mas aqui estão algumas coisas que nós temos aprendido pra ter as coisas funcionando. Um dos primeiros passos é ter uma build automatizada. Ter todo que você precisa dentro do seu controle de código para que você possa então ter todo o sistema com um único comando. Para muitos projetos isto não é uma coisa pequena - isso é na verdade essencial para qualquer uma das outras coisas funcionarem. Inicialmente você pode fazer a build sob demanda, ou simplesmente fazer uma build noturna automatizada. Enquanto ainda não tem um Integração Contínua, ter uma build noturna automatizada é um bom passo. Introduza alguns testes automatizados na sua build. Tente identificar as áreas onde geralmente as coisas dão erradas e faça testes automáticos que exponham estas falhas. Particularmente, em um projeto existente é difícil ter realmente uma boa suite de testes funcionando rapidamente - leva tempo para construir os testes. Você deve começar com o pensamento em algum lugar especifico. Tente agilizar a commit build. Integração Contínua com uma build de poucas horas é melhor do que nada, mas diminuir para o número mágico de 10 minutos é bem melhor. Isto geralmente requer algumas cirurgias sérias em sua base de código, como quebrar as dependências das partes lentas do sistema. Se você estiver começando em um projeto novo, comece com a Integração Contínua desde o início. Mantenha os olhos nos tempos da build e tome alguma ação logo quando quando começar a ficar mais lento que a regra dos 10 minutos. Agindo rapidamente você irá fazer as reestruturações necessárias antes que a base de código fique tão grande que isso se transforme em um problema maior. Acima de tudo tenha alguma ajuda. Encontre alguém que tenha feito integração contínua antes que possa ajudar você. Como qualquer técnica nova, é difícil introduzi-la quando você não sabe como o resultado final deve parecer. Pode custar algum dinheiro ter um mentor, mas você pode também pagar por tempo e produtividade perdidos se você não sabe fazer isso. ( Aviso: sim, nós da ThoughtWorks fazemos algumas consultorias nesta área. Afinal de contas nós cometemos a maior parte dos erros que podem ser feitos).

Pensamentos Finais

Desde que Matt e eu escrevemos a versão original desde artigo, a Integração Contínua tem se tornado a principal técnica para o desenvolvimento de software. Dificilmente qualquer projeto da ThoughWorks acontece sem isso - e nós temos visto outros usando IC ao redor do mundo. Dificilmente eu ouço coisas negativas sobre esta abordagem - ao contrário de algumas das mais controversas práticas do Extreme Programming. Se você não estiver usando Integração Contínua eu recomento fortemente você a tentar. Se você você estiver usando, talvez algumas idéias pode ajudar a você fazer isso mais efetivamente. Nós temos aprendido muito sobre Integração Contínua nos últimos anos, e eu espero que possamos continuar aprendendo e melhorando isso ainda mais.

Leitura Indicada

Um ensaio como este pode somente cobrir por alto algumas coisas. Para explorar a Integração Contínua em maiores detalhes, eu sugiro dar uma olhada no livro do Paul Duvall sobre este tema (que ganhou um prêmio Jolt - mais do que eu já tenha alcançado). Não existem muitas coisas sendo escritas sobre builds por estágios mas existe um ensaio escrito por Dave Farley na The ThoughtWorks Anthology que é útil (também disponível aqui).

Você já ouviu falar em CouchDB ?

Esta semana fui apresentado a idéia de usar o Apache CouchDB pelo dx7lab em um projeto experimental. Já tinha visto algumas pessoas falarem dele, mas confesso que o máximo que conhecia era a descrição do wikipedia. Existe pouco material na net sobre ele, até porque o projeto é bem recente, mas a idéia principal é bem inovadora: unir a idéia de um db distribuído, orientado a documentos, usando JSON como base pra sua organização e toda camada para seu acesso baseada em REST. Uau! Ainda estamos lendo muito [muito mesmo] sobre o assunto e aprendendo muitas coisas legais. Se você quiser dar uma lida, além do site oficial existem alguns recursos legais:

Livro da O'Reilly

A O'Reilly Media esta publicando o rascunho do seu livro sobre CouchDB (com o humilde adendo ao titulo de "Definitive Guide"). Ainda tem muita coisa a ser escrita, mas aos poucos os conteúdos vão sendo postos online. O link? Esse aqui.

Screencast do peepcode sobre Rails+CouchDB

O peepcode publicou há algum tempo um screencast sobre como usar uma app Rails com CouchBD. O valor do screencast é de U$ 9, se você tiver paypal, fica a dica.

Tradução do Madrugão sobre o CouchDB on Rails by Aimee

O pessoal do madrugao esta traduzindo e postando um material muito legal sobre o tema. Vale dar uma olhada. O link é esse.

Enfim, acho que o recado esta dado. Ainda não sei se o CouchDB se comporta bem em produção, por isso cuidado, todo passo dado agora é um investimento alto. Mas por tudo que o projeto pretende ser, quando estiver 100% vai ser muito, muito legal.

Factory Pattern e PHP

Voltando a visitar alguns bookmarks de blogs sobre PHP, encontrei um material simples mas interessante do Brian DeShong. Ele publicou no seu site o slide de sua palestra sobre o padrão Factory e sua implementação em PHP. O link é esse aqui.

Dica de leitura

Aproveitando as férias da faculdade prometi pra mim mesmo que vou botar em dia algumas metas de leitura e o primeiro foi o livro do Vinicius Teles da Improve It, cujo tema e titulo são os mesmos: Extreme Programming.

O livro da uma pincelada em muita coisa que tem se dito sobre desenvolvimento ágil de uma maneira descontraída e sem muita enrolação. Muito exemplos, experiências pessoais do autor e boas referências literárias. O único ponto negativo é que as vezes ele se torna um pouco repetitivo, mas isso não chega a ser um motivo que faça alguém parar de lê-lo.

Aproveitando o jabá, no site da Livraria Cultura dá pra ler o primeiro capítulo. Fica a dica ao interessados pelo livro/tema.

Programming Ruby

Pra qualquer mortal que inicia em Ruby on Rails, ter uma base de Ruby é fundamental. Além do próprio user guide, o dx7labs colocou no seu site pessoal uma cópia do livro Programming Ruby - The Pragmatic Programmer's Guide, que esta sob licença Open Publication License. Vamos estudar!

Assertions no Ruby on Rails

Cheat sheet resumindo a lista de assertions mais conhecidos no RoR. ruby and rails assertions

Canivete Suíço do Shell

Dica enviada pelo Rafael "Peixe": O Aurélio Jargas, que possui um ótimo site com várias dicas (em especial do mundo Unix e derivados), publicou há algum tempo uma lista de comandos úteis para se usar no Shell - tem até uma versão PDF no final da página. Essas coisas sempre são boas para se manter no bookmark do navegador...

GitHub

O Fábio Akita lançou um vídeo muito interessante há algum tempo falando sobre como colaborar em um projeto no GitHub, e de quebra acaba dando uma palinha sobre o git.

Github colaborativo from Fabio Akita on Vimeo.

Vlw pela dica Rafael.

Que tal bater um papo com a Eliza ?

Procurando um projeto interessante para fazer durante as férias, tenho lido um pouco sobre Processamento de Linguagem Natural (ou NLP) e esbarrei no Eliza, um programa antigo usando NLP que simula um psiquiatra capaz de conversar sobre problemas humanos. Se alguém estiver interessado no assunto, eis aí um exemplo online.

PHP.JS - port de funções PHP para o Javascript

Procurando algumas funções Javascript que fossem equivalentes a funções em PHP acabei esbarrando no projeto PHP.JS, que é uma biblioteca Javascript com várias funções "portadas" do PHP. O contador do site deles informa que até a data deste post, 196 funções já foram recriadas e parece que o projeto esta ativo.

Como a biblioteca esta ficando cada vez mais extensa, consequentemente esta ficando cada vez mais pesada (52.kb comprimida e 219kb não comprimida). Acho que o ideal é ir adicionando ao projeto somente as funções que forem sendo usadas, o que poupará bastante a conexão dos usuários do seu site.

Helper button_to no Code Igniter

O Rails tem um helper interessante que é o button_to - ele cria um formulário e botão pra postagem com a opção de se passar um array para criação de hiddens. Bem prático, se por exemplo você tem uma listagem que tenha opções como excluir ou editar e você não ache elegante passar parâmetros por get. Trazendo para o mundo do CodeIgniter, para quem estiver escrevendo a view, tem a sensação de que esta usando um <php echo anchor('')> que posta dados.

Copiando essa idéia do RoR para o CI, criei o helper button_to (prêmio para mim pela criatividade do nome) que tem o mesmo conceito. Cadastrei o helper no wiki do framework. Para acessar, clique aqui.

E ai, regulariza nossa profissão ou não ?

Essa discussão ainda esta gerando muito bafafá entre as listas de emails. Na lista java-br mesmo surgiu (novamente) o tema. Confesso que fico preocupado mais em ver as esperanças de um mundo melhor na área tecnológica brasileira do que com a lei em si.

Minha idéia sobre esse assunto é a mesma que alguns sobre certificação: será mais um papel que funciona como uma linha imaginária para ficar prendendo a atenção de pessoas que ainda lutam por algum reconhecimento no mercado. Não que todos que tenham ou almejam ter uma certificação (seja na área que for) são profissionais ruins, mas os realmente bons sabem que possuem experiência o suficiente para mostrar suas capacidades sem depender dos canudos.

Acho utopia a idéia de que com a regulamentação teremos melhores profissionais pelos simples fato deles ter uma faculdade concluída e pertencerem a algum sindicato. Não só pela fraca qualidade da "maioria das faculdades da maioria das pessoas", mas pela mentalidade de que um rolo de papel vai ser o Messias para essa bagunça.

É óbvio que com a regulamentação, os profissionais terão mais burocracia e taxas pra pagar. Mesmo que seja montado um sindicato que faça alguma coisa, ainda sim a mentalidade em muitos será "preciso conseguir a matrícula no sindicato X" com a idéia de que isso os tornou grandes profissionais.

Com a deficiência que a empresas tem de mão de obra qualificada, o mercado ainda continuará incluindo péssimos profissionais em detrimento dos bons profissionais. E essa idéia de que o governo irá fiscalizar as contratações feitas pelas empresas permitindo somente a entrada de profissionais regularizados pode até funcionar nas grandes empresas, mas nas pequenas e médias ainda sim os geeks "desregularizados" estarão lá, mesmo com a carteira de trabalho assinada como "ajudante-geral-de-serviços-de-informática" (enquanto na verdade ele estará resolvendo problemas de escalabidade no principal sistema da empresa). Infelizmente a realidade é assim

Os bons profissionais sempre terão boas oportunidades, com regularização ou não. Sei que é chato pensarmos em pagar alguma coisa a algum órgão para ele simplesmente dizer que você sabe o que sabe, mas o mercado brasileiro gosta disso. Para reafirmar isso me aproprio de um pequeno trecho escrito pelo Vinícius Teles da Improve It:

Do ponto de vista comercial, aqui no Brasil, a certificação é uma jogada de mestre. As pessoas buscam, cada vez mais, todo tipo de selinho que puderem encontrar no mercado para colocar em seus currículos. É uma cultura insana, mas absolutamente pervasiva. Vai de pessoas a empresas.

Fonte: http://blog.improveit.com.br/articles/2007/12/19/novos-rumos-em-2008

O Vinícius resumiu tudo: certificação é uma jogada de mestre. E assim como certificação o é, será também a carteirinha do sindicato. E você possivelmente verá bons profissionais ignorando completamente a regulamentação, bons profissionais se regularizando pra continuarem empregados e profissionais com qualidades questionáveis colocando a carteirinha em uma moldura na parede do quarto.

Web 2.0 no Slideshare

O slideshare fez uma coleção com os slides publicados no Web 2.0 Summit 2008, evento promovido pela O'Reilly no inicio deste mês.

Confesso que fiquei ansioso para ver o material publicado, mas achei a maioria dos slides bem básicos - acredito que as apresentações em si tenham sido melhores. Procurando algum material no slideshare achei outros slides legais sobre o assunto. Posto alguns abaixo:

Web 2.0

View more presentations from Satyajeet Singh.

Creative Web 2.0 Learning

View more presentations from Judy O’Connell.

Vale lembrar também que estão surgindo aos poucos os vídeos das palestras no canal da O'Reilly no youtube .

Liderando equipes ágeis

O Guilherme Chapiewski publicou no slideshare os slides de sua apresentação no Falando em Agile 2008, onde ele falou sobre Liderança de Equipes Ágeis.

Liderando Equipes Ágeis

View more presentations from Guilherme Chapiewski.

Aumentando a produtividade com os snippets

Uma ótima dica para quem usa uma IDE ou editor decente é usar os snippets, blocos de códigos reutilizáveis que "brotam" no seu código após o uso de uma keyword e um tab.

É impressionante como a maioria sabe disso mais deixam essa ferramenta de lado. Utilizando o Gedit hoje resolvi checar como criar novos snippets com coisas mais úteis que for, if e foreach. Como tenho trabalhado em um projeto com CodeIgniter, fiz em poucos minutos snippets completos para criação de controllers, models, helpers, libraries, etc. Além do código em si, embuti os esqueletos dos comentários no formado do phpDocumentator.

Tive uma sensível diferença de produtividade, mesmo tendo parado para criar os snippets. Agora entendo porque o Pragmatic Programmer bate na tecla dos script generators. Realmente ajuda.

Para habilitar os snippets no GEdit, basta ir em Edit -> Preferences -> Plugins e selecionar o plugin snippets.

Clicando no botão Configure Plugin na mesma janela, você pode ver todos os Snippets criados e criar os seus. Para criar um snippet novo não tem mistério algum, basta olhar os outros que você pega o jeito da coisa fácil fácil.

A única coisa que achei estranho no GEdit é que você só pode configurar o plugin do snippet se tiver com um arquivo de extensão reconhecida aberto no Editor. Se estiver só com um Unsaved Document aberto por exemplo, ele não deixa.

Para quem ainda não conseguiu "visualizar" a coisa toda, veja as duas imagens abaixo:

Criei o snippet cicontroller para construir controllers do CodeIgniter. Agora, depois de digitar essa keyword dar um tab, tenho isso:

Usando Google como ferramenta Wiki

Não sei se todos sabem, mas o Google Sites é também um eficiente Wiki empresarial. Basta criar o site, não defini-lo como público, convidar os envolvidos no projeto e pronto. O Google Sites tem todas as ferramentas de um Wiki decente.

Sei que para algumas empresas colocar suas documentações em uma ferramenta externa (e de terceiros) pode ser um pesadelo, mas para outras poder terceirizar a manutenção de um sistema de apoio ao desenvolvimento é um alívio.

Outras ferramentas para Wiki interessantes são: o MediaWiki (gratuito) em php, o TWiki (gratuito) em perl ou o Confluence (comercial) em Java.

Update 1: O Rafael Dx7 achou o projeto Instiki no RubyForge, que também é free. Como o site estava fora e eu não sabia que ele estava hospedado em outro lugar, acabei deixando de fora. Vlw pela dica!

Update 2: Ótima réplica do Rafael, para ler clique aqui.

The Lego Hypothesis

Concorrendo ao prêmio de Palestra que Mais Usou Analogias do ano, o professor James Noble conseguiu criar bons paralelos entre o desenvolvimento de softwares e lego. A máxima da palestra é desenvolvermos software menos acoplados e mais reaproveitáveis - "Programs can be built out of many small independent components".

Para assistir o vídeo, clique aqui.

Layout e Elements no CodeIgniter

Primeiramente quero pedir desculpas a galera que acessa o blog diariamente, já que notaram que o blog tem uma semana sem atualizações! Mas não fiquem com raiva : como recompensa consegui autorização de um grande autor gringo para publicar seus artigos traduzidos. Em breve falo mais sobre isso.

Estamos na correria aqui na 3Jane passando um projeto do CakePHP para o Code Igniter. Uma das primeiras coisas que precisamos criar no Code Igniter foi o esquema de Layouts e Elements (como no Cake). Não dá pra acreditar que o Code Igniter não venha com algo built-in, mas, felizmente o CI tem algumas formas de você construir adds.

Eu sei que quem trabalha com o Code Igniter mais tempo vai reclamar feito uma velha ranzinza "mas já existem uns 10 sites falando sobre como plugar algum esquema de layout no CI". Eu realmente achei algumas soluções na web mas nem sempre se propunham a resolver meu problema de uma maneira simples e "desacoplada". Um simples exemplo é a Layout Library do próprio site do CodeIgniter, que é bem completa mas, para funcionar você tem que substituir a chamada da view das actions dos seus controllers por um método próprio. Além do problema da refatoração do código, isso acaba fugindo do padrão do CodeIgniter ( que é o que eu tenho mais medo). E nem me venha falar daquelas soluções que usam hooks...

Para chegar a algo que me atendesse, eu peguei a Library acima e dei uma adaptada para funcionar sobreescrevendo o Loader padrão para trabalhar com o esquema de Layouts - e acrescentei um método para trabalhar com Elements também. Vamos lah:

Crie uma library parecida com a seguinte:

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');

/**
 * Customized Loader Class
 *
 * Overwrite default Loader which loads views and files
 *
 */
class MY_Loader extends CI_Loader {

 var $layout = "default";

 function MY_Loader() {
  parent::CI_Loader();
 }

 /**
  * Load View
  *
  * This function is used to load a "view" file, including layout.  It has three parameters:
  *
  * 1. The name of the "view" file to be included.
  * 2. An associative array of data to be extracted for use in the view.
  * 3. TRUE/FALSE - whether to return the data or load it.  In
  * some cases it's advantageous to be able to return data so that
  * a developer can process it in some way.
  *
  * @access public
  * @param string
  * @param array
  * @param bool
  * @return void
  */
 function view($view, $data = null, $return = FALSE) {

  $loadedData = array();
  $loadedData['content_for_layout'] = parent::view($view,$data,true);

  if($return) {
   $output = parent::view('layouts/' . $this->layout, $loadedData, true);
   return $output;
  } else {
   parent::view('layouts/' . $this->layout, $loadedData, false);
  }
 }

 /**
  * Load View Element
  *
  * This function is used to load a "view" element file, simulating CakePHP's elements.
  *
  * 1. The name of the "element" file to be included.
  * 2. An associative array of data to be extracted for use in the element.
  *
  * @access public
  * @param string
  * @param array
  * @return string
  */
 function element($element, $data = null) {
  return parent::view('elements/' . $element, $data, TRUE);
 }

 /**
  * Set Layout
  *
  * This function is used to set layout name
  *
  * 1. The name of the "layout" file to be renderized in view function.
  *
  * @access public
  * @param string
  * @return void
  */
 function set_layout($value) {
  $this->layout = $value ;
 }

}

Teoricamente é só isso, copiar a library acima para o diretório de bibliotecas, criar os diretórios layouts e elements dentro do diretório views e criar um layout padrão. Com isso seu site já estará funcionando com layouts, sem precisar mudar suas actions ou criar hooks.

Explicando melhor, a library primeiro renderiza a view solicitada e depois coloca o resultado dentro do layout e o renderiza. Como já disse, fixei que todos os layouts estarão dentro da pasta layouts dentro das views, mas você pode mudar isso. Criei também o set_layout, que me recurso a explicar pra que funciona. E por fim os elements são "views" disfarçadas, que sempre retornam a view renderizada como string. Acho que os elements nem são tão necessários pra todos, mas os fiz só pra forçar o pessoal a concentrar o elementos no mesmo lugar.

Um layout (já usando um elemento) poderia ser o seguinte:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

 <head>

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title> Titulo </title>

 </head>

 <body>
  
   <h1> Esta carregando o layout </h1>
   
   <?= $this->load->element('banner.php'); ?>
    
   
   <!-- Conteudo -->
   <?=$content_for_layout?>

 </body>

</html>

O elemento banner acima é uma view normal, por isso nem vou postar o exemplo. Quem quiser uma cópia do framework seco só com o esquema de layouts funcionando, eu coloquei no rapidshare. A versão da framework é 1.6.3 então cheque no site do CodeIgniter qual é a versão atual antes de começar a desenvolver em cima da cópia que estou disponibilizando.

Projetos PHP e Integração Contínua

Estamos lutando aqui na 3Jane para alcançarmos um formato indolor de Continuous Integration ( aqui e aqui ) em nossos projetos - que são (até então) em PHP.

Existe um número relevante de ferramentas disponíveis, o problema esta sendo fazer com que elas sigam um fluxo natural no projeto. Ou as ferramentas precisam de uma adaptação para PHP (como o CruiseControl com o PHPUnderControl), ou as ferramentas não se encaixam, ou são muito limitadas.

Embora um pouco complexo, estamos achando algumas coisas boas. Para começar, tinhamos decidido apostar no CakePHP, um framework sólido e com grande similaridade com o Rails. Ficamos realmente satisfeitos com a organização da "criança" e de como ele é bem feito. E também tem o fato de que o CakePHP já vem com uma integração com o SimpleTest, que até onde pude ver, a ponte entre eles é sólida e sem "adaptações" incomodas - até porque o SimpleTest também é em PHP.

Acontece que pelo CakePHP ser bem completo, ele também é mais lento que outros frameworks e por motivos de força maior decidimos trocar para o Code Igniter, que também é um bom framework, mas não possui tantas camadas quanto o CakePHP e teremos que "digitar mais". Outro ponto fraco do Code Igniter com relação ao CakePHP é o bake, que é um script generator do CakePHP que agiliza muito a vida.

Quanto aos testes no Code Igniter ele já vem com uma library bem simples para teste unitário, mas é tão simples que estou propondo aqui que troquemos para o SimpleTest ou PHPUnit. Como este último parece ter uma integração com o PHPUndercontrol, estou lendo como plugá-lo ao CodeIgniter.

Já construímos o Tracer Bullet para os testes do ambiente e estamos implantando-o. Estou vendo o Phing para automatizar o processo de deploy, mas ainda não parei para estuda-lo de verdade. Essa é uma das minhas metas nos próximos dias.

Para controle de código, migramos do SourceSafe para o SubVersion e apesar de alguns problemas com o Tortoise, valeu a pena. Pra ser bem sincero, o engraçado é como sempre os problemas envolvem o Windows. Para controle de bug/issues estamos usando o Jira e como Wiki o Confluence. Ah, e para a documentação do nosso código estamos usando o phpDocumentator.

Ufa! Acho que é isso... O problema é conseguir tempo pra ver tudo isso e dar continuidade no projeto. Mas posso dizer que demos um "salto quântico" no processo de desenvolvimento aqui na 3Jane. Se você quiser uma lista organizada e decente das ferramentas que podem te ajudar no desenvolvimento em projetos PHP, o Dave Marshall publicou um top 10 no blog dele.

Por fim, deixo com vocês um slide falando sobre PHP + Continuous Integration :

Continuous Integration and PHP

View more presentations from Arno Schneider.

E-books de graça no InfoQ BookShelf

Para quem não conhece, o InfoQ possui um pequeno acervo de bons ebooks disponibilizados gratuitamente. Você se registra e pode baixar qualquer ebook de graça. Existe também a opção de compra impressa, mas com as taxas de importação mais esse dólar que não para de subir, aconselho a imprimir na xérox do seu João na esquina mais próxima da sua casa.

No site existem alguns ebooks como Composite Software Construction, Scrum and XP from the Trenches, Starting Struts 2, Agile Patterns: The Technical Cluster, Mr. Neighborly's Humble Little Ruby Book, Getting Started with Grails, Domain Driven Design Quickly, Scrum Checklists, Enterprise SOA Adoption Strategies e outros.

Max Gehringer e sua opinão sobre o profissional de TI no futuro

A ComputerWorld publicou uma entrevista com Max Gehringer sobre sua visão do profissional de TI do futuro. Embora meio óbvia, destaca como as empresas devem se posicionar para conseguir manter algum empregado de TI nos próximos anos.

Infelizmente a ComputerWorld não permite o sharing total/parcial de seus textos (no donuts for u), portanto, o máximo que posso fazer é deixar o link.

Gerenciador de pacotes para Slackware

Ótima notícia para os usuários do Slackware: o Slackbuilds.org, site conhecido como uma das principais fontes de pacotes para Slackware, disponibilizou uma ferramenta chamada Sbopkg, que é uma uma ferramenta que cria uma ponte entre o pkgtool e repositório do próprio Slackbuilds, permitindo atualizar ou instalar seus pacotes.

Ainda não tive tempo pra testar mas prometo dar um feedback quando usar a ferramenta. Confesso que de uns tempos pra cá estava usando mais o linuxpackages para baixar os pacotes do Slack, mas se a ferramenta funcionar será o improvement que faltava para a nossa estimada distro linux.

Pra quem esta por fora, existe também o slapt-get que tenta ser uma cópia do apt-get dos Debians da vida para o Slack. Eu não sei se é preconceito meu mas eu não gosto muito. A única coisa que pode vir a me fazer gostar da Sbopkg, além da integração com o pkgtool é o próprio Slackbuilds, que cujos pacotes sempre rodaram redondo na minha máquina... Vamos ver no dá.

Fearless Change Pattern

Mais um vídeo interessante do InfoQ, uma entrevista com Linda Rising ( autora do Livro Patterns Almanac ). Ela fala sobre algo muito importante presente em qualquer mudança de paradigmas: o medo de mudança.

Qualquer padrão novo envolve o medo do erro. Quanto maior o risco de erro, maior o medo. E por isso muitas empresas param no tempo. Com essa introdução ela segue a entrevista identificando fatores para uma mudança sem medo. Para ver a entrevista, clique aqui.

Ubuntu Kung Fu

Boa notícias para os fãs do Ubuntu: o grupo The Pragmatic Programmers acaba de lançar o livro Ubuntu Kung Fu, ressaltando os poderes da distro ( e como as pessoas os desconhecem). Embora não concorde com a frase It’s the best Linux distribution ever, o livro promete trazer mais de 300 dicas sobre o famoso filho do Debian, com foco em usuários que vieram do Windows e do MacOS (sério? E como ficam os milhares de usuários do FreeBSD e do BeOS ?).

Quem quiser um trecho do livro, eles disponibilizaram um PDF aqui.

Materiais online de Stanford e MIT

A universidade de Stanford disponibiliza alguns materiais de suas aulas do curso de Ciências da Computação online, através do programa Stanford Engineering Everywhere. Confesso que peguei o video de introdução ao curso de CC e o carinha fala rápido hein... Mas nada impossível de pegar, principalmente com o tempo.

Abaixo a aula de introdução ao curso de CC:

Procurando por algum similar do MIT achei um tal de MIT Open Courseware, que tem uma sessão de "Ciência, Tecnologia e Sociedade". Não é tão bom quanto o curso online de Stanford, mas já é alguma coisa também.

Vale lembrar que as duas universidades tem canais no Youtube: Stanford e MIT.

Test Driven Development

Estamos aqui na 3Jane nos policiando para seguirmos as regras pregadas pelos processos ágeis. Uma delas é o desenvolvimento orientado a testes. Na verdade todos nós aqui já tinhamos lido sobre o assunto, mas agora vai ser lei.

Falando de mundo PHP, temos basicamente dois frameworks para testes : o PHPUnit e o SimpleTest. Até onde tenho lido, ambos fornecem diversos recursos para escrita de testes, entretando como o CakePHP já possui um caso de amor com o SimpleTest, estou lendo mais sobre ele.

Deixo abaixo um slide que encontrei no slideshare falando sobre TDD:

Software Testing Basics

View more presentations from Belal Raslan.

Poster sobre desenvolvimento ágil

A VersionOne possui um poster bastante claro sobre os subprocessos dentro do processo ágil. Para fazer o download, você tem que preencher um pequeno cadastro (nome e email). A página é essa.

História de falha de um projeto

Recebi por email a newsletter do InfoQ e tinha o anuncio de um vídeo interessante de um projeto que parecia ser bem-sucedido mas foi considerado um fracasso pelo cliente.
Palestra foi gravada na Agile 2008 Conference, pelo Mitch Lacey um CST e PMP.

Para ver o vídeo, clique aqui.

PHP + YAML via SPYC

O Rails usa um formato muito simples de documentos para a substituição do XML, o YAML. Esse formato além de extremamente ágil é mais "human friendly" que o XML.

Procurando algum loader em PHP para esse formato, achei o SPYC. A implementação é simples, basta dar um Spyc::YAMLLoad('arquivo.yml') que ele carrega e gera um array - e você também pode fazer dump com ele.

Dica : Desenvolvimento Web Ágil com Rails

Pois é, o ultimo livro que comprei acabou rápido ( terminei de ler até mesmo antes da fatura do cartão de crédito ser emitida. Será que posso devolver o livro ? ). Logo no inicio do The Pragmatic Programmers os autores falam sobre expandir continuamente seu conhecimento, lendo bons livros a todo momento e aprendendo pelo menos uma linguagem de programação nova por ano. Tentando cumprir isso, tomei vergonha pra começar a estudar Ruby on Rails de verdade.

Como gostei muito do estilo usado pelo grupo The Pragmatic Programmers, comprei o livro deles sobre Rails. Já li umas 60 páginas e estou sentindo que vai dar namoro. Provavelmente os posts sobre Rails no blog vão começar aparecer ;-)

Dinheiro não é tudo

Em pleno século XXI, eu, cidadão das Américas (ainda que do Sul), venho com esse papo mole de que dinheiro não é tudo. Sei que a proposta do post não é nova, mas sei também que tem muita gente que vai concordar comigo que dinheiro não é tudo.

Nós como meros desenvolvedores que somos por vezes somos a menor parte do processo de desenvolvimento de um software ( que paradoxo não ?). Constantemente trabalhamos sobre pressão, com prazos apertados, especificações falhas e com legados de softwares que sofremos pra manter. Mas se é tão ruim assim, por que continuamos ? Simples: porque amamos desenvolver software. Achamos mágico construir soluções que acelerem o processo de comunicação entre os seres humanos, sejam eles quem forem. Gostamos de bits, patterns, miracle driven developments, aprender coisas novas pra agilizar os processos e por ai vai.

Por isso nos envolvemos muito com o nosso trabalho. Saimos da empresa onde trabalhamos e vamos pra casa fazer o que ? Programar ou estudar programação ainda mais - e isso normalmente invade nossos finais de semana. Por essa razão não é difícil imaginar que nos envolvemos e muito com o que fazemos, já que fazemos por que somos apaixonados por isso.

E o que acontece quando percebemos que no ambiente onde trabalhamos existem processos ruins, que podiam ser otimizados mas que por "força maior" não os são ? Perdemos nosso humor. Parece que a "inspiração" para programar acabou, perdemos o ânimo para digitar um ponto-e-vígula sequer. Programador que ama o que faz não consegue digerir muito bem essa coisa de "isso é problema da empresa, as 18h vou pra casa tranquilo".

E é ai que entra o titulo do post "Dinheiro não é tudo". Ok, gostamos de dinheiro por que precisamos e por que nos trás conforto, mas dinheiro não compra entusiasmo - muito menos patrimônio intelectual.

Por exemplo, sempre tem aquele papo de que todo programador deve virar gerente de projetos. Por quê ? Simples, porque gerente ganha mais. Mas, e se eu não gostar de ficar "o dia todo de frente pro Project?" (hei isso foi uma piada, por favor ria) E se eu achar graça em outra coisa? E se o que me deixa feliz é digitar um bando de palavras em inglês e apertar o F5 ? (preciso dizer que foi outra piada?). Quem disse que eu estou programando só por dinheiro?

Por isso saiba discernir se você esta construindo o seu futuro simplesmente pelo que vai ganhar ou pelo que vai viver. Não deixe seu prazer em desenvolver softwares da maneira correta enferrujar junto com os processos administrativos da sua empresa. Dinheiro é bom, mas quando a gente morre fica tudo pra um bando de filhos ingratos que não vão saber quantas linhas de código você teve que escrever para consegui-lo. E se você morrer sem filhos, alguma mulher vai acabar gastando sua grana mesmo. (Suellen isso foi só força de expressão tah amor...) Não substitua talento por desculpas. Se quando você esta no trabalho, só fica pensando em ir embora e quando esta em casa fica com aquela sensação de frustação de voltar pra empresa, é melhor você dar uma olhada nesse vídeo aqui.

Ps.: A propósito, a foto do post é do filme A procura da felicidade. Acho que fui o único que achou o filme sensacional do inicio ao fim, mas mesmo assim se você não viu aconselho a fazê-lo.

LHC usa Linux

Legal não ? Pelo menos agora eu já sei que o mundo não vai acabar com uma tela azul. O texto a seguir foi tirado da Internet News :

"The most powerful physics project in the history of the known universe - The $10 Billion Large Hadron Collider (LHC)- shot its first light speed beam this morning around its 27 km circuit. Beyond the 20 years it took to build and half of all the world's astrophysicists, it also takes another key ingredient to make LHC work -- Linux.

CERN which is the organization that runs the LHC project is using something called CernVM which is is custom Linux distribution. According to VMware, CernVM runs inside of VMware virtual machines that include PC and Macs across a grid that encompases the power of approximately 40,000 CPUs and some 15 petabytes of data a year.

CERN itself is no stranger to Linux and is one of the lead backers of the Scientific Linux distribution, which is a recompiled version of Red Hat Enterprise Linux.

**UPDATED** Got a comment (listed below) from a commenter with an IP within CERN that writes,".. the primary configuration for machines in the LHC computing grid (http://lcg.web.cern.ch/LCG/) is based on Scientific Linux distribution running directly on the hardware. This grid is used to receive and distribute the 15PB of data across the 100,000s of CPUs across the world" **

Considering that the LHC, according to some, could be powerful enough to destroy the Earth, create a blackhole or rip a hole in the fabric of space itself, it is somewhat re-assuring that at least some of the key software behind it is not at risk from the blue screen of death."

Usando o Authenticate do CakePHP

Estou trabalhando ultimamente com o CakePHP (1.2) e achei um componente muito útil: o AuthComponent. Ele centraliza todo o fluxo de autenticação no sistema e se você seguir algumas regras básicas dele, poderá fazer toda parte de login do seu site com praticamente esforço zero.

Primeiro passo é definir se a maior parte do seu site será publica ou privada por que isso dirá onde você deve acionar o Auth. Se você notar que quase todas as áreas do seu site será de acesso publico, é melhor chamar o Auth direto nos controllers que terá actions privadas. Caso não, você pode colocar direto no app_controller da sua aplicação.

Não que você não possa colocar direto na configuração de chamada do auth a lista de controllers e/ou actions e suas respectivas visibilidades, mas é só por uma questão de economia de esforço

A idéia é simples, e vou assumir que o controller com o auth será o app_controller


class AppController extends Controller {

 var $components = array('Auth');

 function beforeFilter() {

  // Auth config
  $this->Auth->allow(array('action_publica'));
  $this->Auth->loginError = __("Usuario nao encontrado", true);
         $this->Auth->loginAction = array('controller' => 'users', 'action' => 'login');
    $this->Auth->loginRedirect = array('controller' => 'users', 'action' => 'profile');
 }

}

No exemplo acima, coloquei a chamada do componente no var $components = array('Auth');, logo depois no beforeFilter ( que sempre é executado antes do controller) configurei o Auth da seguinte forma: o allow() serve para você dizer quais actions são de acesso publico, o loginError() é a mensagem de erro, o loginAction() define onde esta o action de login e o loginRedirect() serve pra apontar pra onde o usuário será redirecionado após o login. Agora basta no meu controller login colocar as actions login() e logout() que ficaria parecido com o seguinte:


class UsersController extends AppController {

   function login() { }

  function logout() {
     $this->redirect($this->Auth->logout());
   } 

}

Assim ficar o login e o logout. Simples não ? O action login() pode ficar completamente em branco e o logout() faz um redirect pro logout do Auth. E a view do login também é bem simples:


<div class="users">

<?php if ($session->check('Message.auth')):?>
        <?php $session->flash('auth'); ?>
<?php endif;?>

<?php echo $form->create('User', array('action' => 'login'));?>
 <fieldset>
   <legend><? __('Login') ?></legend>
  <?= $form->input('username'); ?>
  <?= $form->input('password'); ?>
 </fieldset> 
<?php echo $form->end('Logar');?>
</div>

Na view eu coloquei o $session->flash('auth'); principalmente para mostrar a mensagens do tipo "usuário não encontrado", que você configura previamente no Auth.

Algumas considerações finais

O Auth tem várias configurações que podem ser alteradas, mas por default ele assume que você tem um modelo chamado User, que tem dois campos: username e password. Ele também assume que o campo password foi criptografado com um hash dele. A questão da criptografia do password é a única coisa que não pode ser alterada - ele sempre assume que o password esta criptografado.

Para saber mais sobre o Auth, vá na página da API dele e da documentação no CookBook. Agora vou continuar estudando sobre o ACL para definir as permissões de usuário automaticamente pelo grupo que ele pertence. Quando estiver com melhores conhecimentos tento escrever algo sobre isso.

Alterando configurações do php.ini via apache

Pra quem trabalha com vários projetos PHP em um mesmo servidor, sabe que ficar alterando o PHP.INI para cada besteira que algum projeto queria fazer não é uma coisa muito legal. Para falar a verdade não é nada legal... Por exemplo, não é legal trocar a pasta temporária de upload para um diretório que não possui permissão de escrita ou que esta em uma partição com pouco espaço disponível.

Entretanto ficar confiando no ini_set() do PHP realmente não é legal, pois ao meu ver caímos em dois problemas: as configurações do php.ini ficam extremamente espalhadas ( não queremos violar o DRY correto ?), e segundo é que não podemos fazer tudo com as funções ini_set() like.

Para quem não sabe, algumas configurações do php.ini não pode ser alteradas "on the fly". A Zend criou um nível de segurança chamado PHP_INI_SYSTEM, que não podem ser alteradas em runtime ( clique aqui para ver a lista de funções e privilégios necessários).

A solução que encontrei foi simples mas eficaz ( além de seguir as orientações da própria Zend) : usar uma diretiva de diretório do Apache, lançando um PHP Admin Value. Fazendo isso você pode redefinir algum parâmetro do php.ini para um diretório específico no servidor. A idéia é mais ou menos a seguinte: No httpd.conf do apache, dentro da sessão Ifmodule , crie um diretório para sua aplicação e coloque o seguinte parâmetro:


    <Directory "/caminho/para/o/projeto/">
        php_admin_value parametro_do_php_ini "novo_valor"
    </Directory>

Com isso você pode sobrescrever o comportamento do php.ini inclusive em configurações mais avançadas. Sei que é redundante, mas como se pode perceber tive que usar o php como módulo para poder proveitar essa diretiva.

Gerenciamento de campanhas via OpenX

Vejo pouca gente comentando sobre uma ferramenta de gerenciamento de publicidade online muito interessante feita na dupla PHP & MySQL: OpenX.

O OpenX é uma ferramenta já estável usada para o gerenciamento de banners e texto publicitários de N anunciantes (advertisers) para N publicadores (publishers) no esquema de campaigns. No início é meio complexo entender como funciona as campaigns, zones, filters e os esquemas de clicks, mas não é nenhum ciplope. Eu estive futucando o design do software e os caras que desenvolveram focaram muito (muito mesmo) em desempenho - o que às vezes não os deixam seguir algumas regras da cartilha do "bom desenvolvedor", mas nada alarmante.

Outra coisa muito legal é os diversos relatórios que ele gera, além de um instalador que torna a vida mais fácil para o primeiro deployment.

Para saber mais sobre a ferramenta, clique aqui.

Slide sobre Usabilidade

Recebi pelo twitter o link do slide abaixo e achei interessante a forma como ele fala sobre usabilidade, usando o Wordpress e algumas outras ferramentas que conhecemos como referência. Expressa bem a idéia do Getting Real sobre fazer somente o necessário e deixar claro como ele funciona.

How Not To Get Noticed

View more presentations from Liz Danzico.

Tracer Bullet

Uma dica simples, mas que é capaz de nos livrar de muitas dores-de-cabeça é o uso de códigos testadores de ambiente, ou como o livro Pragmatic Programmer chama, Tracer Bullet. Se preocupar com o ambiente em que sua aplicação irá rodar é tão importante quanto escolher a framework certa para desenvolvê-la. Precisamos ter certeza sobre quais sãos os módulos suportados pelos servidores envolvidos, diretórios com permissão de escrita, configurações diversas do web server e outros itens que sempre nos preocupamos por último.

Deixar para testar o ambiente de produção com o software que irá ser entregue (ainda que seja a versão alpha) é tão insensato quanto fazer o checkup do seu carro 30 min antes de viajar do Rio para Bahia com toda a família. Se tiver que alterar qualquer coisa, já era.

Tendo esse problema nas mãos, entende-se então a técnica de Tracer Bullet, onde criamos um pequeno código, com o mínimo de linhas necessárias para fazer um teste geral no ambiente. Por exemplo, em uma aplicação qualquer pode-se testar a conexão em um CRUD simples com as bases de dados que serão usadas, o uso de componentes terceirizados, envio de emails, permissões de diretórios e usuários, extensões do web server ou qualquer outro recurso que sua aplicação final poderá usar. Não gaste tempo tentando fazer uma tela bonitinha pra mostrar pro cliente, a função do Tracer Bullet é informar pra equipe de desenvolvimento e infra o que terá que ser alterado antes do primeiro deployment. E como grande parte da infra será testada de forma direta, isso refletirá na redução de testes posteriores ao primeiro processo de deployment.

Dica: The Pragmatic Programmer

Vou usar o blog para indicar alguns livros interessantes que tenho tido contato. Embora pareça ser puro "jabá", a idéia é passar pra vocês o que tenho lido e que tem trazido benefícios reais no meu dia-a-dia.

Embora não tenha terminado de ler, tenho gostado muito do The Pragmatic Programmer. É um livro obrigatório, servindo de introdução geral para Refatoração, Source Control, TDD, técnicas DRY, e vários outros recursos que estão de uma forma ou de outra, englobados dentro dos processos ágeis de desenvolvimento.

Além de não ter uma linguagem chata e usar várias analogias interessantes, o livro é realmente prático, traz muitas situações que facilmente encontramos no dia-a-dia.

PHP para aplicações Enterprise

Esta discursão é antiga, mas foi bem explanada por Ivo Jansch na PHP London Conference 2008. O PHP tem recursos interessantes para o desenvolvimento de aplicações Enterprise, mas parece que a comunidade aqui no Brasil não acordou para isso. Fica a dica de usar os tópicos explanados na apresentação para nortear os estudos!

Enterprise PHP (PHP London Conference 2008)

View more presentations from Ivo Jansch.

Usando abas no VIM

Gosto de usar o VIM no dia-a-dia e encontrei um recurso muito útil disponível a partir da versão 7 deste ~~super~~ editor: abas!

Basta usar o :tabnew para abrir uma nova aba. Você pode opcionalmente fornecer o arquivo que deseja abrir na nova aba, passando o caminho como parâmetro.

Para navegar entre as abas, basta usar o :tabn n, onde n é a posição da aba, começando do 0. Para avançar ou voltar entre as abas, use o :tabnext e o :tabprev. Existe também o :tabfirst e :tablast, que respectivamente avançam para a primeira ou última aba.

Mate processos no Windows à la Unix

Sempre tenha o tasklist e o taskkill a mão. O primeiro você usará para pegar os processos abertos e seus PIDs, e com o segundo, você mata o processo.

Um exemplo prático:

C:\Documents and Settings\pmendes\Desktop>tasklist

Image Name                   PID Session Name     Session#    Mem Usage
========================= ====== ================ ======== ============
System Idle Process            0 Console                 0         28 K
System                         4 Console                 0        304 K
smss.exe                     648 Console                 0        392 K
csrss.exe                    712 Console                 0      4.424 K
winlogon.exe                 736 Console                 0      1.788 K
services.exe                 808 Console                 0      3.464 K
lsass.exe                    820 Console                 0      1.828 K
svchost.exe                 1012 Console                 0      4.840 K
svchost.exe                 1080 Console                 0      4.360 K
svchost.exe                 1168 Console                 0     35.352 K
svchost.exe                 1276 Console                 0      3.636 K
svchost.exe                 1412 Console                 0      4.732 K
spoolsv.exe                 1568 Console                 0      5.284 K
apache.exe                  1760 Console                 0     21.632 K
avgwdsvc.exe                1812 Console                 0      2.888 K
mDNSResponder.exe           1828 Console                 0      2.836 K
mysqld-nt.exe               1976 Console                 0      5.792 K
NMSAccessU.exe              2020 Console                 0      1.828 K
svchost.exe                  248 Console                 0      4.172 K
apache.exe                  2000 Console                 0     31.460 K
avgrsx.exe                  5276 Console                 0     40.048 K
alg.exe                     5676 Console                 0      3.588 K
explorer.exe                6664 Console                 0     34.880 K
ctfmon.exe                  7192 Console                 0      3.272 K
jusched.exe                 7244 Console                 0      6.148 K
avgtray.exe                 7580 Console                 0      6.180 K
Babylon.exe                 8152 Console                 0     21.432 K
xampp-control.exe           5308 Console                 0      3.332 K
jucheck.exe                 7564 Console                 0      6.492 K
firefox.exe                 7912 Console                 0    187.140 K
eclipse.exe                 6512 Console                 0    107.316 K
DAP.exe                     6768 Console                 0      5.032 K
pidgin.exe                  6296 Console                 0      5.332 K
cmd.exe                     8036 Console                 0      2.732 K
wmiprvse.exe                6788 Console                 0      6.044 K
tasklist.exe                6272 Console                 0      4.516 K

Supondo que eu queira matar o Eclipse, a ideia seria a seguinte:

C:\Documents and Settings\pmendes\Desktop>taskkill /PID 6512
SUCCESS: The process with PID 6512 has been terminated.

A idéia é simples. Claro que o kill do Unix é mais flexível, mas sejamos mais modestos. No taskkill você também tem o parâmetro -f para forçar o termino do processo e também pode matar o processo pelo nome.

Já tive vezes que o taskkill disse que o processo morreu mais o processo tava mas pra Highlander do que pra Gasparzinho. Vai entender. Não sei também como o taskkill funciona com as árvores de processos. Quem tiver algo mais a compartilhar, sinta-se a vontade.

Eu não vou nem dizer que na universidade eu consegui matar um software de controle de usuário pelo console usando essa dupla tão simpática, até porque seria um estimulo a desordem na instituição.

Aspect Oriented Programming e PHP

Chegando com mais um slide do Sebastian Bergman, o criado do PHPUnit, desta vez o rapaz dá uma pequena palinha sobre AOP, que é uma técnica complementar a OOP.

The State of AOP for PHP

View more presentations from Sebastian Bergmann.

Code Igniter - Code Generator

Tenho estudado ultimamente sobre o CakePHP e de cara já encontrei uma ferramenta muito útil, o bake que é um PHP CLI que permite desde a criação do projeto a scripts de forma automatica. A idéia é até simples, mas na prática ajuda a acelerar o processo de desenvolvimento e manter organizado.

Como conheço o Code Igniter faz um tempo e sei que ele não tem oficialmente uma ferramenta parecida, procurei na internet e achei algo ~~que nem se compara~~ criado por um Brazuca. Não é uma ferramenta "formal" e pelo visto nem pretende ser um grande projeto, mas já dá alguma facilidade. A página da ferramenta é essa. Só roda em ambientes *nix.

PDO - Conceitos Fundamentais

Com a chegada da quinta versão do PHP (na verdade na 5.1), nasceu uma poderosa ferramenta que ainda hoje pouca gente já parou pra estudar: o PHP Data Objects ou PDO.

Pra inicio de conversa, o PDO é uma camada de acesso a dados que como o php.net promete, "indiferente do banco de dados que esteja usando, você poderá usar as mesmas funções para executar queries ou pegar dados". Desenvolvida pelo Wez Furlong - um desenvolvedor do core PHP que até tenho na minha lista de links no lado esquerdo, o PDO realmente cumpre o que promete em unificar as interfaces de acesso a dados. Ele foi escrito em C e segundo alguns evangelistas da extensão, não perde em nada em desempenho para as extensões tradicionais.

Ainda hoje temos a opção de usar no PHP os antigos drivers especificos para cada DB, mas isso já tem caído em desuso. Vale repetir o que a Zend comentou, que o PDO não é uma abstração do que já tinha, ele é a reescrita dos drivers fornecendo uma mesma interface (na maioria das vezes) para o desenvolvedor. Pra quem usa o Pear (se você não conhece deveria) talvez já tenha se esbarrado no PearDB, que esta sim é uma abstração. Mas o PDO não.

Composição e Bases Suportadas

O PHP Data Objects suporta nativamente as seguintes extensões: PostgreSQL, MySQL (3,4,5), Firebird, Sybase, Informix, Oracle, ODBC, DBLIB, IBM DB2, SQLite (2,3), MSSQL e FreeTDS.

Para usar o PDO você terá que ter no mínimo duas extensões : a do core, que geralmente já vem instalada por default, e a do banco desejado, como por exemplo o pdo_mysql.

O forma mais fácil para instalar os PDO drivers em uma versão do PHP previamente instalado é através do PHP Extension Comunity Library. Uma vez tendo o PECL instalado, basta digitar pecl install <nome_do_driver> e depois atualizar o php.ini adicionando na parte de extensões o driver instalado.

Conectando ao bd

Vou comentar só sobre como conectar ao banco de dados e criar um handle para a conexão, pois basicamente é isso que difere de um bd para o outro - ao final, vou deixar alguns links com melhores exemplos.

// Criando o handle de uma conexão com o PostgreSQL
$db = new PDO("pgsql:dbname=MEU_DB;host=localhost", "USUARIO", "SENHA" );
 
// Criando o handle de uma conexão com o MySQL
$db = new PDO("mysql:dbname=MEU_DB;host=localhost", "USUARIO", "SENHA" );

Viu como é simples? E com os outros drivers o procedimento é bem parecido. Vale ressaltar que por dicas da própria Zend, que o processo de criação de um handle sempre deve estar dentro de um try/catch, para que informações do servidor não sejam lançadas para o usuário. Fique atento!

Para dar um close na conexão basta você atribuir qualquer valor ao handle, como null por exemplo.

Conclusão

O PDO veio para substituir de vez as antigas formas de acesso a dados no PHP. Existe um número generoso de artigos sobre essa ferramenta, e para não ficar recriando a roda, deixo abaixo alguns links interessantes de fontes que já publicaram algumas receitas de bolo:

Manual Oficial em Português
DevShed - Using PDO Objects in PHP5
Post anterior com slides do criador do PDO
HTMLStaff - PDO: Bancos de dados no PHP 5

Things to do...

Aproveitando um gancho no blog do Guilherme Chapiewski, dei "ctrl+v ctrl+c" em um trecho do livro "The Pragmatic Programmer" que ele publicou:

Learn at least one new language every year.
Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.

Read a technical book each quarter.
Bookstores are full of technical books on interesting topics related to your current project. Once you’re in the habit, read a book a month. After you’ve mastered the technologies you’re currently using, branch out and study some that don’t relate to your project.

Read nontechnical books, too.
It is important to remember that computers are used by people—people whose needs you are trying to satisfy. Don’t forget the human side of the equation.

Take classes.
Look for interesting courses at your local community college or university, or perhaps at the next trade show that comes to town.
Participate in local user groups. Don’t just go and listen, but actively participate. Isolation can be deadly to your career; find out what people are working on outside of your company.

Experiment with different environments.
If you’ve worked only in Windows, play with Unix at home (the freely available Linux is perfect for this). If you’ve used only makefiles and an editor, try an IDE, and vice versa.

Stay current.
Subscribe to trade magazines and other journals (see page 262 for recommendations). Choose some that cover technology different from that of your current project.

Get wired. Want to know the ins and outs of a new language or other technology? Newsgroups are a great way to find out what experiences other people are having with it, the particular jargon they use, and so on. Surf the Web for papers, commercial sites, and any other sources of information you can find.

As recomendações acima parecem óbvias, mas até mesmo o óbvio precisa ser definido para ser bem seguido. A fila tem que andar...

PHP 5.3 e seu Garbage Collector

O PHP tem(ou tinha) um pequeno problema para tratar referências circulares, principalmente entre objetos. No blog do Alex Netkachov, um ZCE desconhecido da vida que as vezes posta umas coisas legais, ele fez o seguinte benchmark :


class Node {
 public $parentNode;
 public $childNodes = array();
 function Node() {
  $this->nodeValue = str_repeat('0123456789', 128);
 }
}
function createRelationship() {
 $parent = new Node();
 $child = new Node();
 $parent->childNodes[] = $child;
 $child->parentNode = $parent;
}
echo 'Initial: ' . number_format(memory_get_usage(), 0, '.', ',') . 
" bytes\n";
for($i = 0; $i < 10000; $i++) {
 createRelationship();
}
echo 'Peak: ' . number_format(memory_get_peak_usage(), 0, '.', ',') . 
" bytes\n";
echo 'End: ' . number_format(memory_get_usage(), 0, '.', ',') . 
" bytes\n";

E o output disso foi:

Initial: 62,224 bytes
Peak: 34,905,216 bytes
End: 34,905,016 bytes

Muito interessante o resultado não ? 34mb para 10.000 requisições. Segundo o próprio Alex, isso seria o equivalente a "Modern systems with 1-2Gb can run 30-60 similar processes at the same time. But in shared hosting environment or when support of 100 simultaneous connections is a system requirement, such memory consumption is inadequate."

Pois bem, um cientista da computação de algum lugar do mundo chamado David Wang escreveu um patch para o garbage collector do PHP sanando este problema com as referências circulares. Ele mesmo confessa que o PHP usa "a simple garbage collection system", precisando de alguns improvements. Ele publicou um resumo do de suas idéias relativas a este patch e ao problema em si no news.php.net, mas eu trago abaixo uma cópia da mensagem dele:

Hello, everyone. My name is David Wang and I am one of the students
participating in Google Summer of Code this year. As you may remember,
my project is to implement a garbage collector for circular references
in PHP. As the midterm for Summer of Code is coming up, my mentor,
Derick Rethans, thought it would be a good idea if I shared my
progress with the community.

As you know, PHP uses reference counting as a simple garbage
collection system. One of the primary weaknesses of reference counting
systems is that objects that refer indirectly or directly to
themselves, i.e. reference cycles, are not collected. The accumulation
of unreferenced memory that is only deallocated at the end of a
request can be prohibitively expensive. The cycle collector I am
implementing directly addresses this problem.

The cycle collector is, of necessity, a type of tracing garbage
collector. However, it uses reference count information to accelerate
the collection process. Essentially, it works by removing the internal
reference counts (that is, references from an object within the cycle
to another object within the cycles )from candidate cycles. In a cycle
that can be collected, after all internal reference counts have been
removed, the reference count of all objects within the cycle should be
0. The particular algorithm that I am using is the synchronous cycle
collector described by David Bacon and V. T. Rajan in Concurrent Cycle
Collection in Reference Counted Systems (see the article for further
details). Various optimizations allow the cycle collector to be run
relatively infrequently and execute speedily when it does run.

Note that because PHP is designed to be single-threaded, a synchronous
algorithm is used which does pause program execution for cycle
collection when cycle collection becomes necessary. If a program has
no reference cycles, the cycle collector does not run at all.

The initial phase of implementation is complete, and I am currently
profiling, optimizing and trying the modified version of PHP on
various test programs in an effort to find bugs. Meanwhile, here are
some recent benchmarks.

Some aspects of the eZ Components (http://ez.no/ezcomponents,
available from SVN with the instructions here:
http://ez.no/community/articles/an_introduction_to_ez_components/installation)
testing suite use reference cycles heavily. The Template test uses
circular references the most frequently, the Graph test also uses
circular references, albeit less heavily.

On the Graph test, maximum memory usage with unmodified PHP was 133.9
MB with an execution time of 8 seconds.
On the Graph test, maximum memory usage with gc was 51.6 MB with an
execution time of 9 seconds.
On the Template test, maxmium memory usage with unmodified PHP was 1.5
GB with an execution time of 30 seconds.
On the Template test, maxmium memory usage with gc was 67.3 MB with an
execution time of 1 minute.
On the whole suite of tests (which includes the Graph and Template
tests), execution time with unmodified PHP was 12:03. With cycle
collection, it was 12:43.
These tests were conducted on my dual core AMD X2 4400+ desktop with
./configure --with-gd --with-jpeg-dir --with-zlib. As you can see,
there is the classic time vs. memory trade-off.

My project is currently being hosted on the xdebug CVS. You can get
the latest version with the following commands:

cvs -d :pserver:srmread@cvs.xdebug.org:/repository login
CVS password: srmread
cvs -d :pserver:srmread@cvs.xdebug.org:/repository co circular
Note that I'm implementing my project on top of a CVS version of PHP
5.2 that is a couple of weeks old. However, the cycle collector can be
ported into other versions of PHP fairly easily as it does not affect
the existing Zend engine code too much.

If anyone has any questions, I'll be more than happy to answer them!

Regards,

Yiduo (David) Wang

Fico feliz por essa melhoria, pois é uma pequena alteração que faz muita diferença. Só espero que não tenha seus efeitos colaterais...

Não mude o escopo dos seus objetos

Imaginemos a seguinte situação : você seguindo o modelo de classes criado para o projeto X, cria uma classe de usuários. Lá você tem todo o cuidado para definir os Gets e Sets, colocar seus atributos com seus devidos modificadores de acesso, cria todos os seus métodos e tudo fica perfeito, respeitando os mais elegantes padrões de programação. Logo após, você usa essa classe para, por exemplo, fazer uma busca pelo usuário de ID 7. Talvez a busca fique assim:

$usuario = new User();

$usuario->setId(7);

$usuarioDesejado = $usuario->selectUser();

Ok, tudo ok. Mas.... e se de repente você digita o nome do atributo de maneira errada, como por exemplo seid . O PHP vai retornar um erro, correto ? Errado. Ele não retorna erro algum. Ele não retorna nada. Na verdade, ele cria um atributo em tempo de execução chamado, neste exemplo, seid. Isso é um problema.

Claro que você, assim como eu, só alteraria o escopo de um objeto em tempo de execução por um enorme engano. Faria alguns testes, descobriria o erro e todos ficam felizes ( hipotéticamente ). Porém, existem alguns programadores que não pensam assim. Pensam que se a linguagem permite, tem que usar. Logo, aproveitam a festa pra fazer uma zona com seu objeto. Começam a criar atributos alterando o design original da sua classe.

Não faça isso. Em pouco tempo o projeto se tornará em uma bola de neve, onde não se tem controle nenhum sobre o comportamento do seu código. Use a cabeça.

Por hoje é só pessoal.

Profissional sim, mas, aonde ?

Semana passada surgiu um debate aqui na 3Jane sobre um problema encontrado por muitas equipes quando se encontra um profissional 'super-star' .

Se você esta acostumado a ler o blog do Phillip Calçado já de ter deparado com o termo 'super-star', que é como ele se refere aos programadores que dominam as ferramentas com que trabalham e por isso têm alguma visibilidade no mercado.

É bem provável que alguns dos leitores deste blog trabalham ou já trabalharam em equipes que tiveram a entrada de um super-star. Ae surge a pergunta: aonde você é um bom profissional ? Na empresa em que trabalhou ou no mercado, de uma forma mais ampla ?

Existem alguns profissionais que são bons nas empresas 'incubadoras' onde eles foram formados. Dominavam todas as regras de negócio, eram verdadeiros dbas-desenvolvedores-gerentes-selecionadores de currículos plênos. Como o dono aqui da empresa costuma dizer, se o cara for atropelado pelo caminhão do leite a empresa tem que parar ( embora ele esqueça que no Brasil não temos caminhão do leite).

É normal para qualquer um que já ocupou uma posição desta ( muito comum em empresas pequenas ) se sentir deslocado ao mudar de empresa. Quando saí da antiga empresa onde trabalhava para vir para a 3Jane me senti assim também. Mas o importante é entedermos que quando estamos em uma empresa nova, estamos lidando com novas regras de negócio, com novas pessoas ( e mentalidades ) e com provavelmente novas tecnologias.

Não é incomum vermos alguns destes profissionais 'super-stars' tentando impor suas formas de trabalhar, criticando tudo e colocando sempre suas formas de pensar e trabalhar como as ideias. Mas a coisa não é bem assim. Como o Rafael DX7 disse durante a nossa conversa aqui na empresa 'esses profissionais costumam lançar suas incapacidades nas pessoas ou rotinas a sua volta'.

Sempre podemos otimizar os processos em nosso ambiente de trabalho - afinal de contas, é assim que nos destacamos. Mas nunca devemos nos esquecer que os processos são formados por pessoas, e que elas são a parte mais importante do sistema. Se essas pessoas não enxergarem que você esta ali para acrescentar, é melhor você repensar seus conceitos ou procurar o telefone da antiga empresa onde trabalhava.

Experimentando o Slackware 12

Ola pessoal, saindo um pouco das linhas de codigo, decidi conversar com vocês um pouco sobre um mito que o Linux, em especial o Slackware, é um SO quase impossível de ser operado de tão complexo. Com isso vou descrever minhas experiências com o Slackware 12.1 - a versão mais recente.

Lembrando que esse post não é mais um daqueles “Instalando o Slackware passo-a-passo”. Existem inumeros destes na internet e no final do post eu colocarei alguns deles.

Qual é a dificuldade em se trabalhar no Linux ?

Por que alguns profissionais de TI teimam em migrar para o Linux com a desculpa deste SO ser extremamente complexo ? Isso não é real. Há quase 2 anos atrás eu decidi ir de cabeca para o Linux. Para isso, em um momento kamikaze, tirei por completo o Windows do meu pc doméstico e deixei na época apenas com o Suse 10.

Após a configuração e instalação através de um setup completamente grafico e intuitivo, cai direto no KDE ( que é um dos principais gerenciadores de janelas do Linux ), com todos os hardwares do meu PC configurados e funcionando. Em uma prévia comparação (sadia) com o Windows, até a versão XP ( que foi a ultima que eu mexi), o Linux se mostrou mais facil de se instalar que o MS Win. For a o fato de que a instalação do Linux já deixa seu computador com pacote de programas para Escritório, gravação de CD, programas para Design entre outros.

A única coisa que tive que fazer foi configurar o Linux para abrir conexão a internet via um modem adsl que eu tinha. Para isso foi só eu dar um adsl-setup no modo console para configurar tudo. Depois, para abrir efetivamente a conexão, foi soh dar um adsl-start ( que mas tarde aprendi a como colocar no startup do pinguim). Em outra comparação com o Windows, na época que eu ainda não tinha roteado o meu modem, tinha que instalar um CD com os drivers do Modem e ums aplicativos de gerenciamento de conexão. E como eu sempre perdia o CD, sempre estava em apuros. Depois que roteei meu modem adsl era só plugar o cabo de rede no pc que eu ja estava na internet em qualquer um dos sistemas operacionais.

Minha primeira experiência real com o Linux havia sido bastante satisfatória e, ao contrário do que muitos me falavam, não tive problema algum com o pinguim.

Grande (?) dificuldade : Wireless no Laptop.

O tempo passou e com muito esforço vendendo produtos de Herbalife, Foreverliving e lendo anuncios no pc que me retornam 0.001 centavo de dolar, eu consegui comprar meu laptop. Era (e ainda é) um HP DV5020, um modelo hoje ja fora de linha.

Acontece que ele veio com uma placa wireless chamada Broadcom 4318, mas conhecida no mundo Linux como uma das BCM 43XX . Pois é, como a fabricante decicidiu insistentemente não querer que o pessoal do mundo *nix utilizasse sua placa em seus pcs, ela não desenvolveu nenhum driver para nossa plataforma e nem disponibilizou seu codigo fonte para que um dos nosso gênios podesse recompila-los.

Na época, a unica solução que tive disponível foi utilizar uma técnica do Linux que utiliza o driver do Windows no Linux através de um pequeno emulador chamado ndiswrapper ( http://ndiswrapper.sourceforge.net/joomla/) .

Como eu já tinha ouvido falar bem do Ubuntu em laptops e um amigo ja o tinha baixado, decidi experimentá-lo. E gostei muito do que vi. Utilizar o ndiswrrapper nele era uma questão de alguns cliques. Como o Ubuntu só vem com um CD de instalação, tive que baixar da internet alguns programas que eu precisava, mas nada alarmante. O tempo passou, eu migrei para o Ubuntu 7.10 - até então a atual versão. Era tudo felicidade.

Confesso que até o Ubuntu 7.10 eu nunca havia precisado muito do console. Fazia uma coisa o outra só para tentar aprender, porém, ainda tinha um certo medo da tela preta.

Por que Slackware ?

A ignorância me irrita e por isso eu me sentia incomodado em ter uma janela bonitinha com um passo-a-passo misterioso sempre a mão para todos os meus problemas. Não estou falando mal do Ubuntu ou Suse ( inclusive sào as distros que eu aconselho a qualquer um que esteja entrando no mundo Linux ) mas eu queria aprender mais sobre o Linux em si, sem tentadores GUI que me façam a pular fases de aprendizados. Seguindo o conselho do pessoal aqui da 3Jane, decidi instalar o Slackware.

Minha primeira impressão.

Peguei o DVD da ultima versão, e instalei. Setup não era tão grafico, porém, de fácil entendimento mesmo para quem não tinha buscado maiores informações sobre ele. A instalação foi rapida e indolor.

O computador deu um reboot. Após eu selecionar o Slackware no gerenciador de boot ( Lilo ), ele comecou a carregar o SO. Já carregado, eis que surge a tela preta e um cursor piscando na tela pedido o login e senha. Loguei, apareceram algumas poucas informações e voltei para o cursor piscando, agora não mais pedindo um usuário, mas sim esperando algum comando. É neste pondo que alguém pensa: “O Slackware é isso ? Nada de interfaces gráficas, janelas ou algo parecido ?”.

Calma. O Slack antes de tudo é um SO voltado para o que você pede, e não para o que alguém acha que você iria pedir. Ele tem sim um gerenciador de janelas ( na verdade ele ja vem com vários ). Se quiser entrar em um gerenciador, tente o comando startx . Ele inicia o Window Manager padrão. Se você quiser ver a lista de WM instalados para experimentar outros, antes de iniciar o modo grafico, digite xwmconfig no terminal - ira aparecer todos os WMs disponíveis, escolha o seu e tecle enter. Depois inicie o modo grafico com o startx e teste seu novo WM.

Coisas que fiz.

Criando a conta de usuario.

Primeira coisa a ser feita em qualquer sistema operacional descente é separar as contas de root ( administrador ) e de usuarios ou serviços. A conta de root só deve ser utilizada para configuração do SO. As demais contas que cubram as outras necessidades.

E a minha placa wireless ?

Se lembra que eu disse que tive um problema com minha placa wireless por causa da falta de driver para Linux ? Nesta última versão do kernel do Linux ( 2.6.24.xx), os gênios do pinguim construiram um driver para minha Wireless com 100% de suporte, através de engenharia reversa. Verdadeiros artistas. O driver ficou tão bom que incluiram o modulo no kernel.

Logo não preciso configurar nem ficar emulando um driver de outra plataforma no meu Slack ( ou em qualquer outra distro com as ultimas versões do kernel Linux).

Se você utilizar o KDE, notará que ele vem com uma série de ferramentas administrativas. Cheque se as interfaces de rede wireless estão ativas e então execute o kwifi para entrar em alguma rede wireless. E obvio que dá para fazer isso em modo texto. Provavelmente ficará assim:

ifconfig eth1 up

iwconfig eth1 essid minharedewireless key [1] 0000000000

dhclient eth1

Onde eth1 será a sua interface de rede, minharedewireless é o nome da sua rede e 000000000 é a senha ( se a rede for protegida ). A ultima linha eu preciso porque meu modem adsl esta roteado, e portando preciso que ele forneça IP para a minha placa wireless. Claro que isso pode variar de rede pra rede, por isso, se você quiser algo mais instântaneo faça pelo KDE.

Placa de video e o Xorg.conf

Como meu note tem uma placa de video ATI, tive que abrir o xorg.conf ( /etc/X11/xorg.conf ) e alterar o drive para ati. Isso mesmo, não é necessario baixar o driver, instalar ou configura-lo. Só alterar o xorg.conf e ser feliz. O xorg.conf tem vários parâmetros de configuração de hardware como placa de video, monitor, layout de teclado, mouse e afins. Fique tranquilo pois se você não quiser alterar este arquivo na mão, o KDE tem ferramenta para alterar quase tudo do xorg.conf.

Lembre sempre de fazer backup desde arquivo, porque sempre antes de iniciar seu Window Manager, o X ira consultar o xorg.conf . Se alguma coisa estiver errada, simplesmente você não tera as janelas coloridas ..rs.

Caso você tenha feito alguma besteira e não tenha backup deste arquivo ( que vergonha ), digite xorgconfig no console e siga o passo-a-passo para criar um xorg.conf novinho em folha.

Habilitando o som.

Notou que não sai som pelas suas caixas de som ? Pois é, em 99% dos casos isso não significa que o Slack não detectou seu dispositivo de hardware, mas sim que o ALSA ( que é o gerenciador de som) não foi configurado. Basta digitar o comando alsaconf no console e seguir o passo-a-passo do configurador.

Que tal experimentar ?

Quer experimentar sem instala-lo diretamente na sua máquina ? Instale um gerenciador de maquinas virtuais e teste-o. Eu indico o VirtualBox que é leve, livre e funciona bem tanto no Linux quanto no Mac e Windows. No final do documento esta o link desta ferramenta.

Considerações Finais

Talvez você esteja se perguntando se vale mesmo migrar para o Slackware. Como eu disse, no meu caso valeu. Primeiro porque estou tendo que aprender um pouco mais sobre o comportamento do Linux para fazer algumas coisas que nas outras distros era só clicar e ver acontecer. Com isso ganho infinitamente mais poder sobre meu SO. ÓBVIO que da pra você fazer as coisas nas outras distros de maneira mais "underground". Mas se você SÓ poder fazer do jeito certo é bem melhor.

Outro grande motivo é o ganho de performance. O Slackware incomparávelmente mais rápido do que as outras distros que ja mexi. E procurando alguns benchmarks na web confimei minha teoria.

Bom esse foi um resumão da minha experiência com o Slackware e dos motivos que me levaram a migrar para ele. Se tiver alguma dúvida, poste na parte de comentários que eu tentarei ajuda-lo.

Links

Slackware – Site oficial - http://www.slackware.org/

Site em português com dicas para Slackware - http://www.slackware-brasil.com.br/web_site/

Virtual Box – gerenciador de máquinas virtuais- http://www.virtualbox.org/

Não conhece o conceito de virtualização ? http://www.dx7lab.com/virtualizacao

Sites com passo a passo para instalação do Slackware 12

1 - Video-aula da instalação do Slackware 12 - http://tuxtoriais.wordpress.com/2007/10/14/como-instalar-o-slackware-12/

2 – Outro site com o passo-a-passo - http://jrjuniorsp.wordpress.com/2008/02/27/instalando-o-linux-slackware-12-passo-a-passo/

3 – Instalação e Pós-Instalação do Slackware 12 ( http://www.howtoforge.com/the_perfect_desktop_slackware12 )

Agradecimentos

Eu não caí de para-quedas por completo no Slackware. Existiram duas pessoas aqui da 3Jane que me deram algumas dicas : Rafael Santos e Rafael Dx7 ( http://www.dx7lab.com ).

CSS Reset

Hoje estava conversando com um colega aqui na 3Jane sobre a técnica de "zerar" as diferenças entre a renderização de estilos entre os browsers para apartir de então começar a escrever as folhas de estilo.

Claro que isso não funciona sempre, mas já facilita bastante o começo e manutenção da camada de interface com o usuário. A tal técnica tem o nome sugestivo de CSS Reset. Acontece que dando uma olhada rápida na web, você acaba encontrando "n" pessoas dizendo ter a galinha dos ovos de ouro, inclusive a própria Yahoo através da YUI Library.

Depois de procurar um pouco, achei o blog Perishable Press, com uma lista de vários desses CSS Resets e alguns comentários. O link segue abaixo :

http://perishablepress.com/press/2007/10/23/a-killer-collection-of-global-css-reset-styles/

Vlw Pessoal!

Test your PHP applications!

Mais uma vez com um slideshow...Acho que vou mudar o nome do blog para blogdosslides. Bom, de qualquer forma, esse slideshow é deveras interessante. Trata-se de mais um do Sebastian Bergmann , um dos principais desenvolvedores do PHPUnit.

O slide traz uma vasta explanação sobre testes no PHP. Entenda bem, não estou dizendo que o slide fala tudo sobre TDD, mas fala sobre como aplicá-lo no PHP através do PHPUnit. O cara fez uma aplicação de teste e explanou sobre técnicas auxiliares para assegurar a qualidade do seu software.

I-Scrum

A notícia não é tão nova, mas fica registrada aqui: I-Scrum, uma comunidade social que foca debates sobre desenvolvimento ágeis. A idéia parece ser ótima, só espero que não vire um orkut pra nerds.

http://i-scrum.ning.com/

Segundo eles, agora temos um lugar certo para falarmos sobre "Scrum, XP e outras coisas relacionadas a desenvolvimento ágil".

Separando os meninos dos homens

Lendo o artigo do Jim Plush, acredito que ele acertou me cheio em listar os principais conhecimentos que um profissional PHP deva ter. Desde que entrei pra 3Jane, já participei de algumas etapas no processo de seleção dos cadidatos para vaga de desenvolvedor PHP, e sempre os candidatos tem certos problemas com coisas elementares. Logo se você estive aprendendo e quer um "mapa do tesouro", acredito que os itens do Jim resumem tudo:

PHP5 vs PHP4
You should at least three major features that separate PHP5 from PHP4

Networks
You should be able to do some basic socket programming or at least understand how you would connect to other machines

OOP
You should have a deep understanding of OOP and be able to answer simple questions like how private and protected methods differ. You should understand the following concepts(not really critical you use all of them but at least know why you would need them)

* interfaces
* constructors
* private, public, protected
* inheritance
* polymorphism
* static methods

Database
You should know what a normalized database is, you should understand primary and foreign keys,

Design Patterns
You shouldn't say "huh?" when I mention design patterns. Again, not critical you use that many, but important you understand why they're helpful and know at least a couple.

Source Control
You should be well versed in at least one major source control system (ZIP FILES IN TEMP DIRECTORIES DON'T COUNT!). bonus points for being able to name at least one reason cvs is a pain in the ass.

Unit Testing
You should understand what unit testing is, and why it's important (bonus points for test driven design, knowing how to unit test javascript, or how to use selenium).

Part of the Community
I should be able to find all sorts of good things on google that you're doing with php or web technologies, It generally is a red flag when I google you and nothing comes up(bonus points for having a project of your own or contributing to one).

Javascript Skills
You should know the methods use to manipulate the DOM (appendChild, removeChild, nextSibling, etc...), you should know how to create your own classes in JS (FORM VALIDATION IS 1999), bonus points for being able to show how to make a private variable in javascript.

CSS Skills
You should know the box model inside and out, understand css selectors and how to use inheritance

Passion for Improvement
I want you love what you do and not be looking for a bare minimum, what's the least I can do to get out of here at 5 job. You should be looking to build your skill sets and become more valuable.

Fonte: http://www.litfuel.net/plush/?postid=166

Confesso que embora os itens sejam poucos, eles são bastante vastos e é impossível dominar todos de uma hora pra outra. E não somente isso, muitas vezes faltam livros técnicos voltados para nossa plataforma, o que nos obriga a procurar por materiais em outras linguagems, como em Java por exemplo. Aqui no Brasil, algumas vezes o PHP tem uma imagem de "menos enterprise" que outras plataformas de desenvolvimento web, muito por culpa do mercado que ele tem maior participação. Vamos estudar pra mudar isso!

PHP 5.3 Features

O sr. Ilia Alshanetsky ( ufa!) andou liberando no blog dele um pdf com as features do PHP 5.3. Coloquei no Rapidshare e o link segue abaixo:

http://rapidshare.com/files/131456385/php53.pdf.html

A principais mudanças ao meu ver serão:

Feature complete implementation of namespaces
Overall Improvement 5-15%
Introduced __DIR__ magic constant indicating the directory where the script is located
?: Operator : Allows quick retrieval of a values and/or expressions
__callStatic() : __call() equivalent, but for static methods

Existem outras importantes modificações, entre elas no php.ini, PDO, E_DEPRECATED ( novo error mode) e no Garbage Collector. Vamos ver no que dá...

Desenvolvimento Web e Segurança

Continuando na onda dos slideshows, hoje estava lendo um sobre segurança na web em aplicações PHP. Aborda o básico de forma direta. Fala sobre Data Input, XSS, SQL Injection, Code Injection, alguma coisa sobre sessão e um pouquinho sobre servidores compartilhados. Seus autores são Anish e Mudha - não faço a mínima ideia de quem sejam...

PHP Security

View more presentations from manugoel2003.

Acessando atributos privados de um objeto em PHP

Lendo o ultimo slideshow ( do Sebastian) sobre a OOP no PHP, no slide 28 ele mostrou inocentemente um exemplo que me deixou no mínimo curioso. Ele cria um método qualquer em uma classe, que recebe por paramentro um objeto qualquer, e então consegue trabalhar com esse objeto como se TODOS os atributos fossem publicos.Não muito satisfeito com o exemplo do slideshow do carinha, eu realizei meus próprios testes. Eis ai os resultados:
1º - Tirando a prova real do exemplo do rapaz ( acessando um atributo privado de um outro objeto do mesmo tipo ) :

<?php

    class test {

        private $privateAtribute = "Atribute accessible";

  public function printMe( $obj ) {


    privateAtribute .= ' changed';
    print $obj->privateAtribute;

  }

 }

 $test = new test;
 $test->printMe(new test);

?>



Saida: Atribute accessible changed

2º - Acessando um atributo privado do mesmo objeto

<?php
class test {
private $privateAtribute = "Atribute accessible";

public function printMe( test $obj ) {       

$obj->privateAtribute .= ' changed';
print $obj->privateAtribute;
 
}

 }
 
$test = new test;
 $test->printMe($test); 
 ?>

 Saida: Atribute accessible changed

3º - Acessando um atributo privado de um outro objeto de tipo diferente

<?php

class testA {

private $privateAtribute = "Type A - Atribute accessible";

}

class testB {

private $privateAtribute = "Type B - Atribute accessible";

 public function printMe(  $obj ) {

print $obj->privateAtribute;

}

}

$test = new testB;
$test->printMe(new testA);
 
?>


   Saida: Fatal error: Cannot access private property testA::$privateAtribute in C:xampphtdocstestindex.php on line 15

Por fim, ele só lançou erro quando os objetos eram de tipos diferentes. Vendo alguns testes que o dx7lab fez aqui na 3jane, vi que em Java a coisa funciona do mesmo jeito. Eu hein...

Desenvolvimento Web e Segurança

view presentation (tags: php security)

PHP Object Model

Mais um slide show... Desta vez é de um desenvolvedor chamado Sebastian Bergmann, um dos desenvolvedores do PHPUnit. Ele da um resumão da implementação da OOP no PHP.

Understanding the PHP Object Model

View more presentations from Sebastian Bergmann.

Overload de Propriedades e Métodos em PHP

Essa dica é velha mas sempre é útil:

__get( $propriedade ) {}

Estoura quando se tenta ler o conteúdo de um atributo que não exista na sua classe. O parâmetro que ela recebe sempre será o nome da atributo inexistente.

Por exemplo:

class casa {

function __get( $propriedade ) {

throw new Exception("A propriedade $propriedade não existe no objeto " . get_class($this) );

}

}

__set( $propriedade, $valor ) {}

Exatamente como a de cima, porém, como é de se perceber, só estoura quando se tenta atribuir algum valor a um atributo inexistente. O primeiro o parâmetro é o nome do atributo, o segundo o valor. Acho que não precisa de exemplo neh ? Qualquer coisa adapte o de cima....

__call( $metodo , $argumentos ) {}

Este útimo serve para a chamada de métodos inexistentes... O primeiro parâmetro, obviamente é o nome do método e o segundo parâmetro é um array com os valores passados como parâmetros.

Checando tipagem de objetos por parâmetro

Em PHP, como tudo é dinâmico - até a tipagem de variáveis, é comum quando trabalhamos com objeto verificar seu tipo com o instanceof. Mas existem um jeito mais elegante que é o seguinte:

class carro {
    ... bla bla bla ...
}

class cavalo {
    ... bla bla bla ...
}

function imprimeCarros( carro $umCarro ) {
    print $umCarro;
}

$meuCarro = new carro();
$meuCavalo = new cavalo();

imprimeCarros( $meuCarro );
imprimeCavalos( $meuCavalo );

Na primeira chamada de imprimeCarro vai ocorrer tudo ok. Na segunda chamada, como o tipo de objeto é diferente, vai estourar um erro. Sei que parece óbvio mas, deixa o código mais elegante...

Primeiro Livro de RoR é Brasileiro

Isso mesmo, o primeiro livro de RoR 2.1 é tupiniquim. Graças ao trabalho de Carlos Brando e Marcos Tapajós .

Para baixar, clique aqui.

Hello World em Rails

Fala pessoal... Esse final de semana tirei algumas horas para estudar Ruby on Rails. Como não tenho um vasto conhecimento na plataforma, não vou me deixar guiar pelas poucas coisas que vi. O que posso dizer é que até então tenho gostado. Configurando no Windows Mesmo estando on Windows, achei a configuração do ambiente de desenvolvimento extremamente simples. Basta baixar a ultima versão do Ruby no próprio site do RoR e realizar alguns passos simples. Depois de rápidos next > next >finish, o Ruby teoricamente estará instalado. Basta agora instalar o framework Rails, abrindo o console do windows e digitando:

gem install rails --include-dependencies

Sua primeira aplicação Pronto! Ruby e Rails instalados. Para criar um "hello world", basta agora criar uma pasta em algum lugar ( de preferência via Console ) e logo após, dar um rails "nome a aplicação". Mais ou menos assim:

md C:\rubydevs cd C:\rubydevs rails hello

Como é notório, criei um diretório na raiz e, na ultima linha chamei o daemon do rails dando o nome da minha futura aplicação. Ele automaticamente cria toda a estrutura de desenvolvimento que preciso, colocando todos os arquivos usados pelo RoR lá. Para criar um primeiro controle para sua aplicação, entre no diretório do projeto ( no meu caso hello ) e, via prompt, faça o seguinte:

ruby script/generate controller helloworld

Fazendo isso, usamos um script gerador que já faz algumas coisas úteis para nós ( como criar helper e test para o controle novo). Agora é hora de criarmos alguma ação para o novo controler. Que tal sairmos um pouco do maldit... ehrr... bom, quero dizer, adorável Console do Windows ? A própria instalação do Ruby já nos deixa com o SciTE, um editor de textos bacana. Se preferir uma IDE, uma dica é começar utilizando o Aptana RadRails ( plugin para o Eclipse ). Se você seguir o mesmo caminho que eu, terá que baixar o Aptana Studio ( já com o Eclipse ) e depois fazer uma pequena atualização para o RadRails - que aparecerá automaticamente no startup do Aptana. Depois vá na pasta app/controllers e abra o controle criado - no nosso caso o helloworld. O nome do file sempre fica nomedocontrole_controller.rb . A estrutura do arquivo será identico a seguinte: class HelloworldController < ApplicationController end Temos o declarador class seguido pelo nome do controle, o "<" indicando herança, o nome da classe Pai e o end finalizando a classe. Vamos criar o método dummie. Agora seu arquivo deve ficar da seguinte maneira: class HelloworldController < ApplicationController def dummie end end Já é o suficiente. Vamos agora para a visão. Dentre a estrutura de diretórios, existe um chamado views. Se você abrir este diretório, notará que existe um subdiretório com o nome do seu novo controle - isso não é magia, é pura tecnologia. Agora, crie um aquivo com a extensão rhtml que será a visão do seu controle. Como o nome da ação que criamos é dummie, logo, o nome da visão será dummie.rhtml . Esse arquivo será automaticamente chamado pelo RoR, quando o método dummie do controle for chamado. Como ele será a parte html da sua aplicação web, escreva alguma coisa para estar no browser. Agora é só rodar. Para isso, retorne ao console e, dentro do diretório da sua aplicação, digite:

ruby script/server

O script server levanta automaticamente o servidor na porta 3000. Para testar, vá no seu browser favorito ( provavelmente Firefox, Opera ou Safari ) e teste a url:

http://localhost:3000/helloworld/dummie

Eis aí a criança. Sei que o tópico foi extremamente simples, mas tentei abordar desde a instalação a primeira aplicação. Tenho feito alguns teste e tenho gostado do que tenho visto. Com o passar do tempo vou dividindo com vocês.

Console online de Ruby

Tenho me acostumado com a idéia de estudar Ruby on Rails. E como dita a regra, se Rails é somente um framework sobre Ruby, nada mais lógico do que procurar ter um bom conhecimento nesta linguagem para se dar bem.

Para auxiliar nesta tarefa, eis o tryruby, uma aplicação web que permite executar alguns comandos na linguagem.

http://tryruby.hobix.com/

Design Patterns no PHP

Ola pessoal, esse é o primeiro estudo relacionado a PHP que publicarei no blog - e espero que seja o antecessor de muitos outros. Por o PHP ser uma linguagem extremamente fácil, tanto pela sintaxe, quanto pela comunidade de programadores que mantem blogs e fóruns pela internet, cada programador PHP acaba tendo uma "escola" diferente. Obviamente, isso eh bom pois, cada um aprende de acordo com o seu próprio ritmo de estudos, mas, in other hand, vejo muita muita gente dizendo-se programador com deficiências em áreas basicas da programação. Falando de maneira simples, a galera ta mais preocupada em fazer um site do que construir uma solução. Pensando nisso, resolvi começar falando a respeito de Padrões de Projetos ou Padrões de Desenho de Software, termos estes originários do inglês Designer Patterns. Ao longo desse estudo, vamos tentar abordar os principais pontos de desenvolvimento de software estruturado e no final pretendo realizar um passo-a-passo de um projeto junto vocês, ok? Antes de comerçarmos o estudo em si, existe um ponto muito importante que necessita ser ressaltado: o PHP, ao contrário de outras linguagens como C ou Java por exemplo, não obriga o programador a desenvolver pensando nos moldes da Orientação a Objetos (OO). Não caindo no mérito desta caracteristica do PHP ser boa ou ruim, é importante o programador ver-se motivado a querer aprender esse padrão e utilizá-lo sempre em seus projetos. Como tem sempre aquele pessoal que aprendeu programar de uma forma, e fica meio reguardado para migrar para uma outra forma de pensar, gosto sempre de dizer que existem soluções e soluções. Como li em algum lugar certa vez "Qualquer chimpanzé consegue escrever um código que o computador entenda, o dificil é escrever um código que o homem também possa entender". Esse é o espirito da coisa. Qual são os principios da Orientação a Objetos ? Para podermos aprendermos os Design Patterns, devemos impreterivelmente entendermos como funciona um código Orientado a Objetos. Um código OO deve seguir os seguintes conceitos :

- Encapsulamento : Todo código que segue os moldes da OO, deve encapsular, ou seja, dividir em pequenas partes um problema/solução bem definido. Cada parte ou capsula, deve ser independente e bem formulada, de maneira a ficar claro onde ela se aplica no seu projeto. - Generalidade: Todo código orientado a objetos deve ser construido pensando sempre em ser reaproveitado em outros projetos. - Equilíbrio: Quando escolhemos seguir um padrão em um projeto, devemos sempre usarmos o esquilibrio em até onde vamos padronizar nossos códigos. Devemos sempre analizar qual tipo de problema teremos que resolver, vermos como funcionam as soluções tradicionais e como funcionam as soluções ruins ou fracassadas. Com isso, conseguimos facilmente entender como se comportará o nosso código. - Abstração: Para desenvolvermos um código elegante, devemos usar abstrações, ou seja, analizarmos os conceitos do conhecimento cotidiano na nossa vida real e aplicarmos ao nosso código. Parece loucura, mas realmente é assim que funciona. - Abertura: Ao adotarmos o padrão OO em nosso código, ele deve ser flexível para que cada capsula tenha liberdade de se aprofundar tanto quanto for necessário em um problema. - Combinatoriedade: A capsulas em seu código deve ser relacionadas hierarquicamente. Isso significa que você deve ter partes maiores em seu código, que se relacionam com diversas outras partes menores.

Lembrando que não é necessário você ficar decorando esses conceitos. Basta entendê-los e fazer alguns poucos exercícios tentando combinar os itens acima. Em pouco tempo, esses conceitos serão notados naturalmente em seus códigos. O PHP pode não ser considerada a linguagem-modelo ao falarmos de OO (tal como Java), mas, através da versão 5 do nosso tão amado HyperText Preprocessor conseguimos utililzar praticamente todos os padrões mais comuns do Designer Patterns. Boiou ? Fique atento nos "próximos capítulos" deste estudo que você poderá entender melhor. No próximo estudo falarei sobre o Modelo de Classes, explanando sobre Classes, Instâncias, Objetos, Métodos, Propriedades, Herança entre outras coisas e, vou montar um exemplo básico em PHP. Links interessantes para quem quiser saber mais por enquanto: - Apostila em PDF do Professor Fenando Lozano falando sobre diversos conceitos de OO no PHP : http://www.lozano.eti.br/palestras/oo-php.pdf - Criar Web - POO no PHP 5 - http://www.criarweb.com/artigos/330.php - Grupo de PHP no Yahoo! Grupos - sempre com alguém disposto a tirar duvidas - http://br.groups.yahoo.com/group/php-pt/ Um grande abraço e sorte nos estudos! Pedro Mendes

Design Patterns no PHP

Dando continuidade ao estudo sobre Design Patterns no PHP, vamos hoje começar a falar sobre o Modelo de Classes e a sua aplicação usando o PHP. No ultimo post ( Design Patterns no PHP - Introdução Geral ), eu havia falado sobre teorias como : Encapsulamento, Generalidade, Equilíbrio, Abstração, Abertura e Combinatoriedade. Agora, levando em consideração que você entendeu o principio teórico da coisa, vamos lá. Caso não, envie perguntas através dos comentários e/ou tente ler novamente o primeiro tópico do estudo.

A invenção da Roda.

O paradigma, ou seja, modelo ou padrão da Orientação a Objetos não é novo. Foi criado na década de 60/70, quando os softwares começaram a ficar extremamente complexos. Além do motivo óbvio de melhor reutilização do que já foi escrito, era necessário uma forma mais eficaz na organização dos sistemas. Até por que, cada vez mais os projetos estouravam seus prazos e valores previstos.

Talvez, ao descrever o passado, muitos programadores enxerguem seu presente ou o da empresa onde trabalha. Projetos que pareciam ser extremamente simples, mas, acabam se tornando uma verdadeira Caixa de Pandora. Historicamente, a primeira linguagem a introduzir conceitos do paradigma de Orientação a Objetos foi a "Simula". Logo após veio o Smalltalk (criada pela Xérox) que se tornou a primeira linguagem popular Orientada a Objetos - e que alavancou o paradigma.

Mesmo tendo rodas, bicicleta ainda não é carro.

Talvez alguém afirme: Mas o meu código é organizado, afinal de contas eu o separo em varias funções. Será ? Em um sistema simplório, como de um pequeno gerenciador de notícias, você pode pensar que não tem tanto a perder. Mas ai surgem questões do tipo : E se a estrutura do banco tiver que mudar, o quanto você terá que alterar o seu código ? E se novas regras aparecerem ? E se a fonte de dados vier de diferentes meios (RSS, BD1, BD2, arquivos de texto, web services) ? E na hora de documentar o sistema, o que você faz ?

E lá vai o bendito programador abrir um arquivo com umas trinta functions diferentes, copiando e colando uma função qualquer para criar a mesma coisa mas agora com um ou dois parâmetros diferentes. Geralmente você terá que revisar TODO o projeto pois, não existe uma arquitetura flexível a mudanças.

Embora hoje a sigla OOP (Oriented Object Programming) ou POO (Programação Orientada a Objetos) cause certo frisson, ela não é algo tão complexo a ponto de somente nerds com coeficiente de rendimento 9.9 de Harvard possam entender. A POO nada mais é do que a evolução natural da programação procedural. Invista seus esforços para entender a lógica da POO - não fique tão preocupado em decorar " qual é a sintaxe no php que faz alguma coisa . É realmente simples.

Voltando a falar sobre Encapsulamento.

No ultimo post do estudo, eu defini encapsulamento da seguinte forma :

“Todo código que segue os moldes da OO, deve encapsular, ou seja, dividir em pequenas partes um problema/solução bem definido. Cada parte ou cápsula, deve ser independente e bem formulada, de maneira a ficar claro onde ela se aplica no seu projeto."

Partindo deste principio, imagine que você tenha umas 20 funções que você costuma usar sempre. Funções como acesso ao banco de dados, validação de formulários, cadastro de alguma coisa em alguma tabela, etc. Você tentou organizar seus códigos dividindo-os em pequenas partes. Mas imagine que você pode agora melhorar a interação dessas partes. Fazer com que elas façam o trabalho sujo de maneira mais "automatizada". Imagine que você pode agora alterar o comportamento das suas funções de acordo com algum evento, melhorar o tratamento de erros, reaproveitar melhor seu código enfim, imagine que você poderá ter mais tempo livre para se preocupar com outras coisas. Essas são as conseqüências naturais da POO.

Com um código seguindo as boas regras da POO, você consegue maior independência e controle entre as suas "cápsulas". Agora você começará a separar seus códigos não mais por functions, mas sim por classes, que terão um subconjunto de funções (métodos). Vamos ver alguma coisa mais prática no próximo tópico.

Dissecando o sapo.

Vamos à prática. Que tal analisarmos a estrutura de uma classe bem simples ? Ela só tem uma misera função (que vamos começar a chamar de método) que imprime "Ola Mundo". Como o objetivo da classe é estudarmos sua sintaxe, logo, não ligue muito para essa função tão tola.

class OlaMundo{
      
              /**
               * Classe de estudo cuja unica função é escrever Ola Mundo
               *
               * @author            Chuck Norris.
               */
         function imprime(){

                           echo( "Ola Mundo" );

              }

}

Primeiro começamos dizendo que vamos escrever uma classe utilizando o comando class, pós-cedido de um espaço e o nome da classe que iremos criar. Darei dicas para uma boa nomenclatura de uma classe no próximo tópico. Logo após, colocamos o primeiro bracelete "{", escrevermos todos os métodos e atributos (veremos atributos depois) e finalizamos o método com o bracelete "}".

Em seqüência criamos os comentários. Isso é uma verdadeira preciosidade em qualquer código fonte. Utilizei o mesmo padrão usado pelo javadoc, onde o comentário deve dizer resumidamente o seguinte: O que o método faz, seu autor, o tipo de retorno que ela pode gerar (String, Array, Boolean, Integer, Double, Object) e os parâmetros (se houver). Como essa é uma classe pra estudo e portanto é bem simples, somente descrevi o método e coloquei seu autor. Sempre comente tudo o que você criar, a ponto de qualquer outro programador conseguir entender seu código se guiando apenas pelos comentários. Isso ajuda a deixar seus códigos auto-documentados.

Depois, criamos nosso primeiro método. Note que utilizei o comando function para dizer que o que vem após será um método. Assim como em uma função simples, devemos fornecer um nome ao método e, entre parênteses dizer se haverão parâmetros. Abrimos então o método com "{" e depois de tudo, fechamos com "}".

Claro que o método criado para o exemplo é extremamente simples. Mais tarde, veremos o uso do $this ( que faz referencia ao próprio objeto), modificadores de acesso( public, private e protected), o uso de atributos heranças e polimorfismo. Vamos prosseguir.

Cada macaco no seu galho.

Há uma filosofia no mundo Unix que é : "Não desenvolva coisas grandes que tenham inúmeras funções. Desenvolva coisas pequenas, que em primeiro lugar realize perfeitamente o propósito para qual elas foram designadas e, em segundo lugar, possam se encaixar uma com as outras, para que juntas possam fazer as mesmas inúmeras coisas mas com extrema perfeição".

Desenvolver seguindo a lógica Orientada a Objetos, não é você pegar todas as suas functions, escrever um "class NinhoDeUrubu { " no inicio do Armagedon e colocar um " } " no final. Como já disse, o principio do enca psulamento é você criar blocos de código que irão se relacionar. Não adianta criar uma classe de conexão com o banco de dados e colocar métodos que irão manipular suas tabelas, envio de e-mail, contas a pagar, etc. Uma coisa é a classe de conexão, outra coisa são as suas tabelas, outra é enviar e-mails, e por ai vai.

Separe suas classes em arquivos diferentes e dê nome CERTO aos bois. Não chame a classe que irá manipular a tabela usuários de DbListaTodos . Pense com carinho na nomenclatura das suas classes. Tenho um amigo pseudo-chinês que sempre diz "O principio da sabedoria consiste em você chamar as coisas pelo nome". Chame a classe conexão com o banco de dados de algo parecido com ConectaBD , ou DBConnect caso há um padrão de nomenclatura em inglês. Outra coisa: assuma um padrão de nomenclatura para todas as suas classes. Veja um exemplo de como NÃO nomear as suas classes:

class connect_BasedeDados2eenviaemail {}

Vamos aos erros: separação visual com letras iniciais maiúsculas e underscore ao mesmo tempo; palavras em inglês e em português ao mesmo tempo (só faltou espanhol e kanji); nome grande que não diz muita coisa ( esta é a segunda classe de conexão ou ela se conecta ao segundo banco de dados ?); uma classe que conecta ao banco de dados e envia e-mail ? Conclusão : NUNCA coloque seu nome como autor desse anticristo.

Classes hoje, objetos amanhã.

Assumindo que você não saiba, um objeto nada mais é que a sua classe em ação, ou seja, nada mais é que a sua classe instanciada. Diferente de uma function, uma classe precisa ser inicializada ( transformada em objeto ) para poder ser utilizada. Veja o exemplo abaixo de uma função que imprime "ola mundo".

function ImprimeOlaMundo() {
echo("Ola mundo");
}

Para utilizar a função acima, basta somente você chamar a função da seguinte forma:

ImprimeOlaMundo();

E pronto. Seu texto aparecerá na tela. Agora, vamos construir isso utilizando uma classe ?

class OlaMundo{

/**
* Escreve Ola Mundo
*
* @author Chuck Norris.
*/
function imprime(){

echo( "Ola Mundo" );

}

}

Analisando a classe acima, podemos perceber que: ela se chama OlaMundo e tem um método chamado imprime() que cospe na tela o texto. Não adianta você escrever algo parecido com o seguinte:

OlaMundo(imprime());

Ao tentar fazer isso (leia-se besteira) você terá um erro catastrófico de sintaxe. Você precisa iniciar o seu objeto, utilizando a classe OlaMundo como base para esse objeto. Para isso você utilizará o construtor new, que cria um objeto no formato que você construiu sua classe. Veja o exemplo da utilização da classe acima.

$ObjetoOlaMundo = new OlaMundo();
$ObjetoOlaMundo->Imprime();

Ooooopa.... peraí, acaba de surgir um camarada novo em cena. Trata-se da seta ( -> ). Sinceramente, não faço a mínima idéia da onde Andi Gutmans tirou essa idéia de que a seta era mais prática ou tornava o código legível. Bom, mas ela existe e não pode ser ignorada. Essa seta serve para separar o objeto (a direta) da chamada de algum método ou atributo (à esquerda). A ordem é sempre a seguinte: $ (cifrão) nomeDoObjeto (objeto) -> (seta) chamadaDeAlgumaCoisa ( método ou atributo ). Em outras linguagens ( 99.9% das outras que tenha OO) a separação é feita não com seta, mas sim com ponto. Algo como $nomeDoObjeto.chamadaDeAlgumaCoisa.

Voltando ao exemplo do OlaMundo, veja que você criou um objeto chamado $ObjetoOlaMundo que é uma instância da classe OlaMundo(). Esse objeto agora pode utilizar todos os métodos ou atributos públicos da classe OlaMundo.

E quanto aos atributos, o que são ? Bom, eles são elementos que juntamente com os métodos, definem a estrutura de uma classe. Também chamados de variáveis de classe, eles são nada mais que uma espécie de "variáveis" onde são guardadas informações dentro da classe. Bom, é difícil ser simples demais sem pular vários conceitos, mas, A PRINCIPIO entenda atributos como um padrão para entrada de informação na classe. Vamos aprimorar a classe acima ? Além do Ola Mundo, vamos escrever o nome do usuário.

class OlaMundo{

var $nomeDoUsuario;

/**
* Escreve Ola Mundo
*
* @author Chuck Norris.
*/
function imprime(){

echo( "Ola Mundo e ola " . $this->nomeDoUsuario );

}
}

Ooooopa (novamente) .... Que história é essa de $nomeDoUsuario lá em cima ???? E que $this é esse no echo ? Simples: se lembra que foi dito que atributos são chamados também de variáveis de classe ? Pois bem, quando você cria uma variável FORA de algum método, essa variável ser torna automaticamente um atributo. Logo, o valor que estiver dentro do atributo $nomeDoUsuario poderá ser acessado por qualquer método da classe. O que eu fiz no echo do método imprime() foi justamente acessar o atributo criado.

Ah, quanto ao $this, o conceito dele é um pouco mais complexo. Para simplificar, entenda que você necessita utilizá-lo toda vez que quiser chamar um atributo ou método dentro da mesma classe. No exemplo acima, eu utilizei o $this para alcançar o atributo nomeDoUsuario. Quando queremos chamar outros métodos pertencentes à mesma classe, nós também utilizamos o $this. Para você utilizar a classe acima, atribuindo um nome qualquer no atributo, basta somente você fazer o seguinte:

$ObjetoOlaMundo = new OlaMundo();
$ObjetoOlaMundo->nomeDoUsuario = "Jeremias";
$ObjetoOlaMundo->Imprime();

Observações Finais.

Bom, por enquanto é isso. Acho que para um post eu passei bastante conteúdo. Eu tinha em mente passar modificadores de acesso( public, private e protected), o uso de heranças e polimorfismo no mesmo post, mas, acredito que vai ficar puxado para aqueles que estão vendo isso pela primeira vez. Vou criar um post futuro só com exemplos e depois continuamos. Minha meta é chegarmos o quanto antes em UML.

Links interessantes para você já ir lendo:

Centro de Computação da UNICAMP: http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.html
Fernando Lozano, consultor independente: http://www.lozano.eti.br/palestras/oo-php.pdf

Se tiver alguma dúvida sobre o que já foi explicado, use os comentários.

Um abraço e sorte nos estudos.
Pedro Mendes

Simulando um With no PHP com Interfaces Fluentes

Esses dias estava conversando com um grande colega programador sobre a carência do comando With no PHP. Estive procurando por algum tempo e como não tive uma solução que me agradasse joguei a idéia para o limbo.

Até que ontem, em mais uma das minhas noites de insônia, tive a idéia de simular o comando With com umas das melhores práticas de legibilidade de código: Fluents Interfaces, ou Interfaces Fluentes.

Primeiro Passo: Falando de Fluents Interfaces e PHP

Acredito que para muitos o termo "Interfaces Fluentes" não é novidade alguma. Mas, para quem não conhece, trata-se de uma maneira mais intuitiva de construir suas classes. Como a implementação de POO no PHP4 era deficiente (leia-se precária) não era possível a prática de Interfaces Fluentes graças à seguinte limitação: no PHP4 você não consegue criar uma referência direta ao objeto através do retorno dos seus próprios métodos.

Mas no PHP5 e sua OO totalmente reescrita, eis que tudo (ou quase) se fez novo. Agora, como a deficiência acima foi suprida, podemos facilmente fazer referencia direta ao objeto retornado por um dos seus próprios métodos.

Exemplo:

// Classe que retorna a própria referencia em todos os métodos
class escreveONomeCompletoUsandoInterfaceFluente {

public function escreveNome( $str ) {

// Escreve um nome qualquer
echo( $str );

// Retorna a referencia do próprio objeto
return $this;

}

public function escreveSobreNome( $str ) {

// Escreve um sobrenome qualquer
echo( $str );

// Retorna referencia ao próprio objeto
return $this;
}

}

Ao ler a classe de exemplo acima, você notará que eu sempre retorno o próprio objeto. Pois bem imaginemos uma possivel utilização NORMAL da classe acima:

$escreveNomeCompleto = new escreveONomeCompletoUsandoInterfaceFluente();
$escreveNomeCompleto->escreveNome( ‘ Pedro ‘ );
$escreveNomeCompleto->escreveSobreNome( ‘ Mendes ‘ );

Porém, como eu estou retornando o próprio objeto nos métodos da classe criada, a implementação Fluente do código seria a seguinte:

$escreveNomeCompleto = new escreveONomeCompletoUsandoInterfaceFluente();
$escreveNomeCompleto->escreveNome( ‘ Pedro ‘ )->escreveSobreNome( ‘ Mendes ‘ );

Desta forma, esta criada uma implementação simples das Fluents Interfaces no PHP. Como você pode perceber, a idéia central é você encadear a chamada dos seus métodos da seguinte forma: $objeto->metodo1()->metodo2()->metodo3()->…->metodofinal(); ao invés de ficar chamando o objeto a cada vez que você queira chamar um método.

Segundo Passo: Aplicando o conceito de Fluents Interfaces para alcançar o conceito de With

Em algumas linguagens você tem o comando With, que funcionada da seguinte forma:

With instanciaDoObjeto

metodoUm();
metodoDois();
metodoTres();

End With;

Com isso, você fornece a instância do objeto e simplesmente trabalha com seus atributos e/ou métodos dentro do bloco criado, diminuindo o código a ser escrito e deixando-o mais limpo. No PHP eu não achei nada que criasse o With diretamente, mas com o conceito de Interfaces Fluentes, o mesmo código acima poderia ficar da seguinte forma:

$instanciaDoObjeto
->metodoUm();
->metodoDois();
->metodoTres();

Pronto! Esta criado o conceito do With com uma estrutura mais aprimorada. Espero que tenham gostado e enviem suas duvidas/criticas/sujestões.

Um abraço,
Pedro Mendes

Palestra de JQuery com uma criança

Pois é, eu ontem ficando mais velho e o pessoal aqui da empresa me passa um vídeo de um garotinho de 12 anos dando uma palestra de Jquery. Pelo menos dessa vez não foi o Rafael dx7 que acabou com a minha vida, foi o Rafael Peixe.

[youtube=http://www.youtube.com/watch?v=8mwKq7_JlS8&hl=pt-br&fs=1]