Digamos que isso é um problema de otimização:

1. um código bem documentado facilita e muito a sua manutenção;
2. documentar código leva tempo;
3. tempo é um recurso escasso em desenvolvimento de software;

Olha o problema… sem tempo, não há documentação e sem documentação você precisará de mais tempo para dar manutenção – oras, mas você já não tinha tempo para documentar, como vai ter mais tempo agora para dar manutenção?

Tentando equacionar esse problema surgiram várias ferramentas que visam facilitar todas as atividades relacionadas ao desenvolvimento.

Como a maior parte do meu tempo dedico ao PHP e CakePHP, tomarei estes como base para as ferramentas, porém várias delas podem ser utilizadas com outras linguagens/frameworks sem grandes problemas ou então possuem similares em outras linguagens.

Padrão de código

A primeira etapa, e talvez a mais importante, seja definir e disponibilizar um conjunto de regras explicando como o código foi escrito.

Este padrão envolve nome de classes, atributos, métodos, comentários, tabelas e colunas do banco de dados, organização de diretórios dentre outras coisas. Até coisas simples como a indentação deve ser padronizada.

Veja alguns guias de codificação para ter um exemplo do que quero dizer:

• WordPress
• CakePHP
• Joomla!

Versionamento de código

Um dos recursos mais importantes durante o desenvolvimento é a capacidade de se desfazer determinada alteração e manter um registro de todas as alterações feitas durante o desenvolvimento.

Atualmente, minha ferramenta favorita para versionamento é o Git um sistema distribuído de controle de versão. Porém existem vários outros que podem agradar, como o centralizador SVN e os também distribuídos Mercurial e Bazaar.

É muito fácil trabalhar com qualquer um destes sistemas e após conhecer as facilidades que o versionamento de código lhe proporcionam, você terá dificuldade em trabalhar com código sem controle de versão, pode apostar.

Caso você opte por um sistema distribuído, dê uma olhada neste modelo de organização para seu código: A successful Git branch model

Versionamento do Banco de Dados

Por melhor que seja o projeto do seu sistema uma coisa sempre ocorrerá: mudança. E isso envolve mais do que código, muitas vezes alterações na estrutura do banco são necessárias.

Como controlar essas alterações? A resposta é “Migrations”

No CakePHP precisamos de plugins para dar essa capacidade a aplicação, há dois largamente utilizados:

• Projeto do Juan Basso: https://github.com/jrbasso/migrations
• Projeto do CakeDC: https://github.com/CakeDC/migrations

Outros frameworks fornecem suporte “nativo” ao recurso, como o Ruby on Rails e Doctrine para PHP em geral.

Testes unitários

Acredito que todos os frameworks modernos fornecem suporte a criação de testes unitários em seus projetos. Os testes são uma fase importante do design do software e fundamental para documentação de qualidade.

O CakePHP até sua versão 1.3 utiliza o framework de testes SimpleTest, porém passará a utilizar o PHPUnit em sua versão 2.0 (atualmente em desenvolvimento).

Não sabe o que são testes unitários? Bom, segue alguns links sobre o assunto:

• Desenvolvimento Orientado a Testes
• Wikipedia: Testes de Unidade/Unitário
• TDD: Desenvolvimento Orientado a Testes
• Criando Testes com CakePHP
• Testes Automatizados no CakePHP
• Como fazer testes unitários em Models no CakePHP

Testes são como controle de versão… depois que você usa, não vive sem.

Documentação

Como comentado anteriormente, um passo importante para documentação são os testes unitários. Porém não devem ser o único.

Uma forma muito eficiente de documentação são os blocos de comentários, no PHP, o padrão PHPDoc é o mais utilizado.

Existem várias ferramentas que varrem o código de sua aplicação e identificam esses blocos para gerar a documentação, alguns deles são:

• phpDocumentor: ferramenta mais utilizada no mundo PHP
• Mais informação em português sobre PHPDoc
• Documente seu código PHP usando PHPDoc
• Gerador de Api para CakePHP

Quando sua documentação é concisa e completa, entender o funcionamento da aplicação passa a ser fácil, independente de quando ela foi criada. Quando isso é aliado aos testes unitários, fazer manutenção passa a ser uma atividade mais fácil e gratificante.

Por fim, é preciso saber o que/quando está errado e como/quando foi corrigido, ajudando na manutenção do histórico e acompanhamento da evolução do software. Para isso temos o tópico a seguir.

Controle de Bugs/Atividades

Como controlar o que, quando e por quem uma determinada atividade deve ser feita? E como verificar por quem e quando determinada funcionalidade foi implementada? O controle de versão pode fornecer parte destas respostas, mas ficar analisando logs normalmente não é muito comodo. A melhor maneira é utilizar uma ferramenta de controle de bugs/atividades.

Utilizo no meu dia-a-dia o excelente Redmine, um sistema simples porém poderoso para controle de tarefas. Suporta diferentes projetos, sub-projetos, integra-se com vários sistemas de versionamento de código, permite criação de wikis para documentação além de vários outros recursos.

Além deste, existem vários outros sistemas como o Bugzilla, Trac, Mantis e PHProjekt.

Conclusão?

Não, não tem conclusão. O texto visa apenas apresentar algumas atividades que juntas ao planejamento e desenvolvimento de software tendem a tornar a vida dos desenvolvedores melhor, seja diminuindo o stress causado por alterações dos requisitos ou manutenção de código mal projetado/escrito, seja tornando o desenvolvimento mais ágil, permitindo mais horas de lazer e descanso e menos fios de cabelo branco.

A intenção nunca foi cobrir todos os tópicos a exaustão, mas sim apresentar alguns exemplos e motivos para adoção de tais ferramentas/ideias. Caso tenha surgido dúvida a respeito de qualquer item, deixe um comentário =]

Sentiu a falta de algum item? Utiliza algo de forma diferente? Deixe um comentário também.

————-
Postado originalmente no blog da Radig

Todo mundo que trabalha com a biblioteca jQuery conhece a chamada:

$(document).ready({
//seu código javascript
});

Ela diz ao browser para executar o bloco interno somente quando o DOM do seu documento tiver sido totalmente carregado, isso permite que ele faça o parser de seu documento utilizando os seletores sem esquecer de nenhum item. Porém quando carregamos estruturas externas ao DOM, como uma imagem, não temos garantia de que o código dentro do bloco anterior será executado quando a imagem já tiver sido carregada.
Dessa maneira, caso você precise de informações sobre a imagem, seu script falhará.

Para contornar isso, podemos utilizar uma outra chamada, que é disparada somente quando TODO o documento tiver sido carregado:

$(window).load({
//seu código javascript
});

As duas diferenças, além do comportamento são:

1. Saí o ‘seletor’ document para a entrada do window;
2. Saí o evento ready para a entrada do load;

A primeira alteração ocorre por conta da segunda, já que o evento load não pode ser associado a um document.

Com essa pequena alteração você garante que seu script rodará apenas quando todo o documento tiver sido carregado – o que é essencial em algumas situações, como a citada anteriormente, porém dispensável na maioria das vezes.

Fonte: http://api.jquery.com/load-event/

Porém os anos passaram e algumas coisas começaram a fazer falta: como faço quando estou desenvolvendo algo grande, fico sem commitar até ter algo estável/usável? crio um branch para isso? mas e depois para unir os branches, e os conflitos? além disso, se só eu estou trabalhando em cima disso, porque commitar para todo mundo algo não pronto?

Foi aí que descobri o GIT, um sistema de controle de versão distribuído, open source e gratuito. Ok, ele é gratuito e open source, mas isso não é motivo suficiente. Como disse, ele é um sistema de controle de versão distribuído, isso quer dizer que cada um que tem uma cópia do repositório tem de fato uma cópia dele, e pode servir outras pessoas, ver histórico, tudo localmente.

Então de quebra, ele resolve o problema de ter de criar um branch para desenvolver uma funcionalidade que só eu vou mexer, posso controlar cada alteração minha localmente, e quando quiser – se quiser – posso sincronizar meu repositório local com um outro central (que eu considero central, já que essa figura não existe no GIT). E mais, ele é MUITO RÁPIDO. Acho que para ajudar na argumentação de que é rápido basta dizer que ele foi feito por alguns desenvolvedores do Kernel Linux, e gerencia todo o código trabalhado por eles – e não é pouca coisa.

Ainda estou caminhando com o GIT, tenho aproveitado minha ânsia de aprende-lo junto com a de contribuir com softwares open source para criar e disponibilizar projetos no GitHub.

A grande maioria dos projetos é voltado ao CakePHP, mas há outras coisas também. Alguns projetos que podem interessar são:

• Comitiva – Sistema construído em CakePHP 1.3 para gerenciamento de eventos;
• Plugin Mailer – Um plugin que ajuda na utilização da biblioteca PHP SwiftMailer dentro do CakePHP;
• Behavior Locale – Um behavior para transformar dados vindo do usuário de seu padrão local para um padrão internacional (de banco de dados)
• Libs – uma coleção de pequenos scripts PHP que fui fazendo ao longo da vida. Há coisas boas, coisas úteis, coisas não tão úteis, mas tudo pode ser usado ao menos como ponto inicial para uma implementação mais elaborada.

A idéia por trás da classe foi matar a curiosidade geek de ver o tamanho de uma “criança” que ajudei a criar, além disso quero estudar uma forma de fazer melhores estimativas para custo e prazo para desenvolvimento de software.

A classe está disponível livremente, sob a licença MIT. Faça o download dela metrics.class.php. Qualquer dúvida sobre sua utilização, deixe nos comentários ou entre em contato comigo.

Vou aproveitar e disponibilizar a atualização da classe para validação de dados e outras “firulas” mais que já disponibilizei anteriormente, porém agora com pequenas adições. Visualize ela validation.class.php.

Qualquer sugestão sobre ambas as classes pode ser feita nos comentários. Espero que seja útil para alguém.

Até a próxima.

———–

Atualizado: troquei os arquivos por equivalentes compactados em arquivo .zip . Valeu Gelinho e Felipe ;]

———–

Atualizado novamente: à um bom tempo meu amigo Raphox indicou na lista do PHPMS uma classe criada pelo grande Sebastian Bergmann para mensurar softwares em PHP, o nome da classe é PHPLOC e ela está disponível neste endereço: http://github.com/sebastianbergmann/phploc . Vale a pena conferir

Habilitar a internacionalização e ter a localização em uma aplicação com CakePHP desde a versão 1.2  é relativamente simples: basta uma lida no nosso Cookbook e pronto.

Outra coisa que é relativamente simples de se fazer é validar os dados, basta termos um atributo em nosso modelo chamado “validate” e seguir as dicas do livro de receitas.

Mas pelo Cookbook somos induzidos a fornecer a mensagem de erro na hora de criar a View, algo que eu particularmente não gosto. É até comum termos um modelo que é usado por Controllers diferentes e consequêntemente por Views diferentes.

Uma maneira de evitar isso, é definir as mensagens de erro já na definição das regras de validação, dentro do atributo “validate” do seu modelo. O grande problema é que para traduzir uma determinada expressão utilizamos um método, e a chamada de método na definição estática de um atributo não é permitida no PHP (dúvida? tente fazer o código abaixo)

class Modelo extends AppModel {
var $validate = _('ola mundo');
}
//esse código não devera ser executado

A solução para isso é a atribuição das regras de validação no momento da instanciação da classe, ou seja, no seu método construtor, da seguinte maneira

 class Modelo extends AppModel {
var $validate;
function __construct(){
parent::__construct();
$this->validate = array( /* aqui você pode definir as regras e mensagens,mesmo chamando um método */ );
}
}

Qualquer dúvida não deixem de utilizar os comentários ;]

——–
Atualizado: havia esquecido da chamada ao construtor da superclasse AppModels ( através do parent::__construct() ) no último código mostrado.
——–
Atualizado

Obrigado ao José Tranca e Thiago Goulart pelos comentários, as soluções propostas por eles devem ser adotada em detrimento da minha, já que melhora consideravelmente a modularidade e reusabilidade das traduções.

Desde que descobri o CakePHP faço parte do grupo CakePHP Tuga e ocasionalmente no canal de IRC do grupo #cakephp-pt na rede Freenode.org, e já tive a oportunidade de aprender e ajudar diversas vezes.

Vamos as dúvidas:

1. Como salvar dados de um formulário que envolva um relacionamenteo de “muitos para muitos”/many-to- many ou ainda de HasAndBelongToMany (HABTM) ?

Nesta dúvida temos que ter em mente que o CakePHP faz todas as ligações entre nossos modelos desde que sigamos suas convenções, caso façamos isso, não haverá dificuldades.
Mas quais são essas convenções? Veja você mesmo.

Um detalhe que não podemos esquecer é que por padrão o CakePHP está preparado para tratar suas convenções em inglês, então, se não quisermos ter de modificar as configurações padrões, temos de desenvolver em inglês. Ok?

Seguindo todas as conveções o que fica faltando? É preciso saber como um relacionamento HABTM se manifesta em um formulário, ou seja, como ele é apresentado. No CookBook temos um texto sobre o caso. Resumindo, o que temos de ter é:

• Um formulário com o nome de um dos modelos envolvidos no relacionamento. Por exemplo, em um blog temos um modelo Post e outro Tags, os dois estão ligados por um HABTM, então no formulário para inserir um Post, o nome de formulário seria Post.
• Um ou mais campos identificados com o outro modelo parte do relacionamento e sua chave. No nosso exemplo seriam um ou mais campos com o nome ‘Tag.Tag’.

No item anterior que surge a principal dúvida: como definir o nome do meu campo? que tipo de campo usar?

Primeiro definimos o tipo de campo a se utilizar: normalmente utilizamos um Select box para multiplas seleções OU um conjunto de Checkbox. Qualquer que seja a escolha o restante é bem simples:

/*
$tag é o retorno de um find('list') com os campos id e name selecionados
$tags = array( array('id' => 1, 'name' => 'tag 1'), array('id' => 2, 'name' => 'tag 2') );
 
o índice 'multiple' só deve ser utilizado quando quiser um conjunto de checkbox
*/
echo $form->input('Tag.Tag', array(
	'type' => 'select',
	'multiple' => 'checkbox',
	'options' => $tags,
	'labels' => 'Selecione as tags'
	));

Com isso seu formulário já retornará o que é esperado pelo CakePHP e tudo que será necessário para salvar os dados do relacionamento é utilizar o método ‘saveAll’ ao invés de ‘save’.

Ainda esta semana comentarei das dúvidas sobre validação.

Para isso, fiz como meu amigo PorKaria e montei um sisteminha simples de comentários (na verdade o dele era o guestbook, mas no fim fazem a mesmo coisa, hehehe).

Descrição do sistema:

Sistema usando AJAX (na verdade o X aqui é de XHTML, porque não utilizo XML) Permite a inserção de comentários, salvando-os em um banco de dados (MySQL), tudo de forma assíncrona. A bibliote utilizada para implementação da parte em javascript é a Prototype, a formatação (CSS) foi retirada de um tutorial do Tableless sobre formatação de formulários e o PHP foi escrito por mim. Além do cadastro, fiz o que pode se chamar início de um sistema de busca com sugestão (famoso autocomplete). Digo o início porque ele não avalia bem o momento de se fazer a busca e não é possível clicar nos resultados, apenas vê-los.

Estrutura:

• main.php : é a página onde está todo o sistema, apartir dela que é feito a leitura dos comentários e o envio de novos comentários;
• adiciona_comentario.php : nesta página fazemos o processamento dos dados vindos do formulário e os salvamos no banco;
• le_comentario.php : arquivo que recupera do banco todos os comentarios e retorna os dados em uma lista html;
• busca_comentario.php : script que faz a busca dos comentários no banco para o “autocomplete” e retorna-os como uma lista;
• validation.class.php : velho conhecido que faz a validação dos dados… a classe ainda está em implementação, mas já está mais completa do que a versão anterior que compartilhei.

Irei comentar apenas a parte javascript, qualquer dúvida sobre o restante, deixe nos comentários ou email-me.

//Funcao que recupera os dados do banco para apresentar ao usuário
function recupera(){
	new Ajax.Updater('comentarios', 'adiciona_comentario.php');
};

O trecho acima define uma função que cria uma nova instância de Ajax.Updater, que fará uma chamada ao arquivo adiciona_comentario.php e usará a resposta para substituir o conteúdo da tag XHTML com ID ‘comentarios’. Ou seja, é essa função que ira carregar os comentários feitos na página.

//Funcao que envia os dados do formulário para serem salvos no banco
function envia(){
	new Ajax.Request('adiciona_comentario.php',
	{
		method: 'post',
		parameters: $("adiciona").serialize(),
		onCreate: function() {
			$('adiciona').hide();
			$('enviando').show();
		},
		onSuccess: function(transport){
			$('enviando').hide();
			$('adiciona').show();
			recupera();
		},
		onFailure: function(){ alert('Alguma coisa não deu certo...') }
	});
}

Este outro trecho define a função envia os dados do formulário para o arquivo adiciona_comentario. Aí é utilizado o objeto Ajax.Request, que é a implementação mais genérica do Prototype para Ajax.
O que é passado para o objeto:

1. O arquivo que receberá a requisição
2. Aqui vem o segundo parâmetro que é composto por vários subparâmetros
   1. Método de envio: POST;
   2. Variáveis enviadas: utilizo a função ‘serialize()’ no formulário, ela transforma os dados dele em uma lista de variáveis, entendíveis pelo navegador e PHP;
   3. Uma função callback que é disparada quando é criado a requisição. Uso ela para mostrar uma mensagem ‘Enviando…’;
   4. Uma função callback que é disparada quando é concluído com sucesso a requisição. Ela esconde a mensagem mostrada anteriormente e chama a função ‘recupera()’ para recarregar os comentários;
   5. Por última uma função callback que é disparada quando ocorre um erro na requisição.

//Funcao que faz uma busca em Ajax e retorna os resultados como em um autocompletar
function fazBusca(event){
	new Ajax.Request('busca_comentario.php',
	{
		method: 'post',
		parameters: $('termo').serialize(),
		onCreate: function() {
			$('resultados').hide();
		},
		onSuccess: function(transport){
			$('resultados').update(transport.responseText);
			$('resultados').show();
	},
	onFailure: function(){ alert('Alguma coisa não deu certo...') }
	});
}

Aqui uma função que faz a busca pelos termos digitados. Utiliza o mesmo objeto da função anterior, o Ajax.Request, então não entrarei em detalhes.

//Evento que é disparado quando o documento termina de carregar sua estrutura
document.observe("dom:loaded", function() {
	$('enviando').hide();
	$('carregando').hide();
	$('resultados').hide();
	recupera();
 
	$('busca').observe('keydown', fazBusca);
});

Por ultimo utilizo a função ‘observe()’ no elemento ‘document’ para que após concluída o carregamento da página (não incluído aí o carregamento de possíveis imagens), execute alguns comandos:
Com a função ‘hide()’ escondo os elementos de aviso ao usuário;
Com a última linha, faço com que sempre que uma tecla for pressionada (keydown) no elemento com ID ‘busca’, execute a função ‘fazBusca’.

Um bônus:

Muitas pessoas enfrentam problemas com codificação quando trabalham com AJAX, para poupar dores de cabeça é recomendado o uso de UTF8 tanto no seu editor de texto (na hora de criar os códigos), quanto nos header dos documentos e no banco de dados. Tendo certeza que está tudo em UTF8, você provavelmente não terá problemas. Só não esqueça de um detalhe: o PHP não trabalha nativamente com UTF8, então, antes de usar qualquer função que trate uma string, use a função utf8_decode do PHP e depois, mas antes de salvar no banco de dados, utilize a função utf8_encode. Isso será necessário até o lançamento do PHP 6.

Download de todos os arquivos do exemplo.
obs.: descompacte os arquivos numa mesma pasta, em seguida crie um novo diretório chamado ‘lib’ e mova o arquivo validation.class.php para ele.

um erro tradicional

A lista foi subdivida em três categorias: “Interação Insegura entre Componentes”, “Risco no Gerenciamento de Recursos” e “Defesa Porosa” – no original: Insecure Interaction Between Components, Risky Resource Management e Porous Defenses.

Há na lista falhas como possibilidade de injeção de códigos, utilização de algorítmos de criptografia defasado e transferência de dados sensíveis sem criptografia.

No artigo original[en] há várias informações sobre os erros e comentários de renomadas empresas de segurança sobre a importância da lista.

Sem dúvida um texto que vale a pena para todo desenvolvedor.

via: IDG NOW!

E apesar do PHP fornecer centenas de funções prontas para diversas tarefas rotineiras, ele perde feio comparado a outras linguagens mais novas como Ruby ou Python, principalmente quando juntamos a estas seus grandes frameworks – Rails no caso do Ruby e Django no caso do Python.

Mas a comunidade PHP tem suas cartas na manga, vários frameworks agilizam o desenvolvimento tanto em aplicações simples como em aplicações sofisticadas.
E são várias as opções. Tem para todos os gostos, nos próximo posts vou falar um pouco deles.

Hoje começo com o CakePHP:

Descrição:
Compete de frente com o Rails. Possui uma base bem estruturada, código bem organizado, comunidade participativa e uma licensa flexivel. Seu grande destaque está no baker, que gera ações básicas (criar,ler,atualizar e apagar entradas) para uma tabela do banco de dados.

Como usa-lo?
É muito fácil, basta ir a página dele e fazer o download do último lançamento. Recomendo a versão 1.2.xx , apesar de ser RC2 (candidata a estável) ela já está bem estável e possui vários melhoramentos em relação a versão 1.1.xx.
Em seguida descompacte o arquivo onde achar melhor (dentro de seu servidor web) e pronto. Agora só falta você configurar o arquivo “/app/config/database.php”. Nele você encontra instruções de como inserir as informações para acessar o seu banco de dados, há até um exemplo de como fazer.
Agora é só acessar, através do navegador, a pasta que você descompactou o CakePHP.

Onde encontrar material para estudo?
Como comentei antes, o CakePHP possui uma comunidade bem participativa, mas a maioria não fala português, então você encontrará bastante informação em inglês, aqui listo alguns sites e blogs com informações sobre o tema, bons estudos:

• CakePHP – A página oficial, sempre com novidades (inglês)
• The Cookbook – O manual oficial do cake. Possui conteúdo para versão 1.1 e 1.2, sendo que a segunda esta sendo finalizada. Obrigatório. (em inglês com parte do conteúdo em português, só alterar no rodapé da página).
• API for CakePHP – A documentação das classes, métodos e funcionalidades do CakePHP. Não é muito rica em detalhes, mas está melhorando. Obrigatório. (inglês)
• lemoncake – Um blog com várias discussões sobre CakePHP e dicas/tutoriais de como usar recursos do Cake. Muito recomendado. (inglês).
• aranworld – Um blog que tem posts esporádicos a respeito do CakePHP, mas no link que vinculei, há uma série de posts sobre o sistema de controle de acesso do CakePHP, uma ferramente extremamente poderosa mas que pode parecer complicada de utilizar no inicio. Muito recomendado. (inglês)
• CakePHP – Brasil – Portal brasileiro sobre CakePHP, ótimo para quem não arrisca muito o inglês, possui dicas e até uma versão traduzida do manual. Muito recomendado. (português)

E podem esperar que em breve haverá vários posts a respeito. Estou utilizando bastante o CakePHP e tenho gostado muito. Colocarei algumas dicas aqui logo logo.

A Fundação Mozilla está desenvolvendo uma Máquina Virtual que implementa o ECMAScript(linguagem que deu origem ao ActionScript do Flash, similar ao JavaScript) versão 4, e graças a idéia de um de seus desenvolvedores, será possível rodar aplicativos escritos no Muito Bom e também muito velho C. Sim, aquela linguagem que é preferida por pessoas como Linus Torvalds e Paulo Adonis.

Além do C, já é possível rodar aplicações Python com esta máquina virtual, e no futuro será possível utilizar várias outras linguagens.

Para provar o feito, a equipe do Tamarin rodou Quake e Zelda ( rodando em um emulador de Nintendo escrito em C ). Tudo funcionou, som e imagem, mas claro, a perfomance não é a mesma. Segundo o desenvolvedor, é aceitável.

Esta pode ser mais uma arma da Mozilla e uma carta na manga da Adobe para enfrentar a Microsoft e seu Silverlight+Visual Studio( que já permite a utilização de linguagen .NET ). Se isso vai gerar bons frutos, só na prática saberemos.

A grande notícia relacionada ao projeto, é que além de tornar possível rodar estas linguagens, o Tamarin poderá substituir o flashplayer nos navegadores, sendo uma alternativa Open Source ( e integrada ao navegador ).

Fontes: INFO Online, The Web at Toolness[en], Tamarin Project[en].