PHP oferece diferentes alternativas para criptografar uma senha. Cada uma delas pode ter suas peculiaridades na hora de se montar o mecanismo de autenticação. Vejamos algumas das principais funções usadas para criptografia de senhas:

• md5 – Gera uma sequência binária de 16 bytes (ou 32 símbolos hexadecimais)
• sha1 – Gera uma sequência binária de 20 bytes (ou 40 símbolos hexadecimais)
• crypt – Gera um hash de acordo com um algum algoritmo escolhido (poucas opções)
• hash – Módulo que oferece diferentes algoritmos de criptografia (para saber os disponíveis, basta usar hash_algos)
• mcrypt – Módulo que oferece diferentes algoritmos de codificação/decodificação (para saber os disponíveis, basta usar mcrypt_list_algorithms)
• mhash – Módulo obsoleto por hash.

$hash_hex = md5('teste'); // Gera 698dc19d489c4e4db73e28a713eab07b
$hash_bin = md5('teste', true); // Gera 16 bytes (inclusive não imprimíveis)

$senha_codificada_bd = $dados_bd['senha']; // exemplo de senha obtida do BD
$senha_codificada_informada = md5($_POST['senha']);

if ($senha_codificada_bd == $senha_codificada_informada) {
    // As senhas sao compativeis
}

$hash_hex = sha1('teste'); // Gera 2e6f9b0d5885b6010f9167787445617f553a735f
$hash_bin = sha1('teste', true); // Gera 20 bytes (inclusive não imprimíveis)

$hash_md5 = crypt('teste', '$1$abcdefgh$');
// Gera $1$abcdefgh$DYdsp/CvdHfTi6XSCsPdg.

$hash_md5 = crypt('teste', '$1$abcdefgh$DYdsp/CvdHfTi6XSCsPdg.');
// Tambem gera $1$abcdefgh$DYdsp/CvdHfTi6XSCsPdg.

$senha_codificada_bd = $dados_bd['senha']; // exemplo de senha obtida do BD
$senha_codificada_informada = crypt($_POST['senha'], $senha_codificada_bd);

if ($senha_codificada_bd == $senha_codificada_informada) {
    // As senhas sao compativeis
}

$hash_md5 = hash('md5', 'teste', false); // Gera 698dc19d489c4e4db73e28a713eab07b
$hash_md5 = hash('md5', 'teste', true); // Gera 16 bytes (inclusive não imprimíveis)

$hash_md5 = hash_hmac('md5', 'teste', 'chave', false); // Gera d1c9c8e42bb681e024dd07ae91aeeb4a

$hash_md5 = mhash(MHASH_MD5, 'teste'); // Gera 698dc19d489c4e4db73e28a713eab07b
$hash_md5_hmac = mhash(MHASH_MD5, 'teste', 'chave'); // Gera d1c9c8e42bb681e024dd07ae91aeeb4a

Rubens Takiguti Ribeiro

Website - More Posts

Bebê Foca

Programar pode ser uma tarefa árdua ou gratificante e geralmente isso está relacionado com o tipo de código que você está mexendo. Existem vários tipos de código, mas o mais repulsivo sempre é o Spaguetti: uma maçaroca generalizada de todas as coisas, páginas que ultrapassam as milhares de linhas geralmente codificadas por pessoas que não acreditam no uso de funções e boas práticas de desenvolvimento (não vou nem cogitar Orientação a Objetos).

Agora, existem também os desenvolveres sobrinhos criativos. Eles se esforçam (ou não) mas acabam por não chegar lá, falhando miseravelmente em sua tentativa frustrada de resolver um problema. Na verdade eles resolvem, não o problema em si mas o resultado do problema e quando isso acontece, um inocente bebê foca é morto violentamente por uma facção de desenvolvedores xiitas.

O problema

É incrível como podemos sempre contar com os usuários. Existe uma síndrome constante que se espalha como praga no mundo: espaços duplos. Não sei o porquê disso, mas é incrível como sempre precisamos tratar espaços duplicados dentro das nossas aplicações a fim de não quebrar o layout ou ferrar com todo o design imaculado de um portal.

Vamos a primeira tentativa do nosso querido amigo:

function remover_espacos_duplos($texto) {
    $texto = str_replace("   "," ", $texto);
    $texto = str_replace("  "," ", $texto);
    return $texto;
}

Com o tempo nosso sobrinho percebeu que poderiam haver mais que dois ou três espaços e que essa função não era a solução pro problema. Não demorou e surgiu a versão 2.0 da função:

function remover_espacos_duplos($texto) {
    $espacos = array("     ","    ","   ","  ");
    foreach ( $espacos as $espaco ) {
        if ( strpos($texto, $espaco) !== false ) {
            $texto = str_replace($espaco, ' ', $texto);
        }
    }
    return $texto;
}

Há! Bem melhor agora! Agora ela contempla até 5 espaços consecutivos. Já imaginou quando alguém colocar 20 espaços consecutivos? Como será que nosso amiguinho iria resolver? Que Deus proteja os bebês foca.

A solução

Para evitar que o pessoal copie as funções acima sem ler o post e consequentemente entender que se trata de uma brincadeira e de como não resolver o problema, vamos sempre propor uma solução, e pra esta a melhor é:

function remover_espacos_duplos($texto) {
    return preg_replace('/\s\s+/', ' ', $texto);
}

Ajude a salvar bebês foca

Nos envie algum código de sobrinho que você achou por aí. Não precisamos de nomes, mas uma história é sempre interessante. Envie um email para sobrinhagem@phpsp.org.br

Augusto Pascutti

Augusto Pascutti é desenvolvedor PHP a 5 anos, trabalhou em projetos Open Source como CakePHP, Zend Framework e Habari. É evangelista PHP e de boas práticas, Zend Certified Engineer para PHP 5, fundador/coordenador do PHPSP, host do PHPSPCast e headbanger nas horas vagas.

Website - More Posts

O PHPSP esta preparando grandes surpresas para a comunidade neste final de ano. Nosso primeiro passo confirmado é o Seminário PHP que acontece no dia 31/Outubro.

O Seminário PHP é realizado pela Tempo Real Eventos com o apoio do PHPSP para montar o seu conteúdo. A coordenação do grupo se reuniu e definimos que o tópico ideal para o evento seria a profissionalização do desenvolvedor PHP, ou como falamos por aqui, a Des-Sobrinhação. Portanto o foco do evento é apresentar técnicas, formas de pensar, estratégias de carreira e novidades sobre o PHP.

Participando deste evento você poderá levar a sua carreira a um novo patamar, melhorando seu ambiente de trabalho com novas tecnicas que facilitam o trabalho em equipe e se destacar profissionalmente, abrindo caminho para novas experiências profissionais.

Nosso grupo de palestrantes é formado por grandes nomes da comunidade e pessoas que construíram suas carreiras utilizando o PHP. Rafael Dohms e Augusto Pascutti são coordenadores do PHPSP e possuem vasta experiência em contribuir com projetos open source como o Habari, PHP e outros, além de serem hosts do PHPSPCast. Guilherme Blanco se destaca ainda mais na comunidade por ser contribuidor do Doctrine, um sistema de ORM excelente para o PHP, além de já ser palestrante de carteira carimbada em grandes eventos de PHP no Brasil. Alex Piaz também possui um grande histórico de participação em projetos Open Source e se destaca pela evolução que causou no ISA com o seu conhecimento de ambientes e equipes.

Com essa equipe de “heróis” o evento passará por palestras de carreira, PHP 5.3, boas práticas e ambientes de desenvolvimento, com certeza uma grande contribuição para quem quer dar o próximo passo em sua carreira.

A pré-inscrição no evento custa apenas R$ 79,00 e se prolonga até o dia 19/Setembro. Este evento não segue o formato de eventos do PHPSP, pois estamos apenas realizando o conteúdo do evento. Mas não deixe de participar por isso, parte do dinheiro da inscrição será repassada ao PHPSP e convertido em benefícios para a comunidade, como a confecção de camisetas, canecas, coffee breaks nos eventos e muito mais, tudo isto será apresentado à comunidade de forma transparente com uma prestação de contas online, contribua para o grupo!

Se quiser saber mais sobre o conteúdo do evento, aguarde o lançamento do PHPSPCast #3 em breve, nele reunimos parte desta equipe de palestrantes e conversamos sobre diversos fatores de uma carreira profissional.

Esperamos que todos possam participar do evento e que ele traga uma luz a todos que querem construir uma carreira com tijolos de PHP e melhorar seus ambientes de trabalho para melhorar ainda mais seu trabalho. E aguardem pois temos mais novidades a caminho, fiquem de olho no blog.

Coordenação PHPSP

Rafael Dohms

Rafael Dohms é um Evangelista PHP e membro ativo da Comunidade PHP. Ele ajudou na fundação de dois Grupos de Usuários de PHP ao longo do tempo e hoje compatilha a coordenação do PHPSP. Desenvolvedor, gamer e apaixonado por código ele também é host do primeiro podcast de PHP do Brasil: PHPSPCast. Atualmente ele trabalha na equipe SWAT do grupo MIH, uma equipe de experts que fornecem conhecimento técnico para o grupo além de trabalhar com P&D buscando novos nichos da internet e tecnologia. Seu papel como Desenvolvedor Sênior é codar, treinar e auxiliar outras empresas e se divertir enquanto faz isso.

Website - Twitter - More Posts

O Problema

Eu já tentei explicar conceitualmente, mas, sinceramente? Ninguém entendeu (comigo incluso). Então vamos pra prática. Vamos supor que tenhamos as duas classes abaixo:

class User {
public static function getTipo() {
return 'user';
}

public static function showTipo() {
echo self::getTipo();
}
}

class Admin extends User {
public static function getTipo() {
return 'admin';
}
}

Admin::showTipo(); // imprime: 'user'

A linha 17 do código acima deveria retornar ‘admin’ e não ‘user’ como foi retornado. Esse seria o comportamente esperado. O problema é a palavra reservada self não resolve a chamada estática, assim como a contante __CLASS__ que se for usada, também retorna a classe errada. Ambos não resolvem a chamada em tempo de execução, eles somente verificam ondem foram declaradas e retornam isso.

A solução

A solução não é nenhuma mágica, ou seja, o código não se resolverá sozinho. Quem sabe um dia? A partir da versão 5.3 que será lançada este ano, você poderá usar uma palavra reservada do PHP (que não é nova) e ela – ao contrário do self – irá resolver a chamada em tempo de execução e retornará os valores corretos. A palavra é: static. Sugestivo não?

class User {
public static function getTipo() {
return 'user';
}

public static function showTipo() {
echo static::getTipo();
}
}

class Admin extends User {
public static function getTipo() {
return 'admin';
}
}

Admin::showTipo(); // imprime: 'admin' (PHP 5.3)

Com a troca do self pelo static, o PHP consegue resolver a classe que chamou o método e retornar o valor correto.

O problema (A revolta dos que não foram)

Magicamente, a solução no PHP 5.3 apresenta um (pasme) novo problema. Antes tínhamos o problema (Late Static Binding) de que o PHP não resolvia a classe que chamava o método, o PHP só via em chamadas estáticas o local onde ele foi declarado. Agora nosso problema passa a ser que o PHP não consegue mais ver corretamente chamadas de classes pai, veja o código abaixo e tire suas próprias conclusões.

class User {
public static function getTipo() {
return 'user';
}

public static function showTipo() {
echo static::getTipo();
}
}

class Moderador extends User {
public static function getTipo() {
return 'mod';
}

public static function norris() {
User::showTipo();
parent::showTipo();
self::showTipo();
}
}

class Admin extends Moderador {
public static function getTipo() {
return 'admin';
}
}

Admin::norris();
/**
* Imprime
* user
* admin
* admin
*/

Enfim, o PHP 5.3 está chegando com grandes mudanças, é importante ressaltar que esta é uma major release e que muitas coisas devem ser levadas em consideração. O PHP já possui release candidates para você testar, então se você ainda não testou o que está esperando? Se você puder ainda compilar, não esqueça de rodar um `make test` e enviar os dados para o http://qa.php.net/ para que suas estátisticas dos testes efetuados sejam computados; só isso já é uma contribuição para o projeto. Aguardem essa semana o PHPSPCast sobre as novidades do PHP 5.3, e logicamente, vão se preparando para ele.

A documentação do PHP sobre a implementação de Late Static Binding já existe, inclusive em português e pode ser vista aqui: http://br2.php.net/manual/pt_BR/language.oop5.late-static-bindings.php

Augusto Pascutti

Augusto Pascutti é desenvolvedor PHP a 5 anos, trabalhou em projetos Open Source como CakePHP, Zend Framework e Habari. É evangelista PHP e de boas práticas, Zend Certified Engineer para PHP 5, fundador/coordenador do PHPSP, host do PHPSPCast e headbanger nas horas vagas.

Website - More Posts

Eu não canso de ficar “de cabelo em pé” com as coisas que eu leio, principalmente na internet. Uma coisa que devemos aprender é a questionar as coisas que lemos, a internet é de domínio público. Eu posso – por exemplo – escrever um artigo sobre como fazer inseminação artificial! Seria tão ruim quanto o artigo que eu citei?! Difícil…

Vamos aos fatos. Nosso mundo é o mundo do desenvolvimento! Pro inferno com a fábrica da Coca-Cola, de Dadinhos de Amendoim e de Muppy. Quase nada que é válido pra eles é válido para o “nosso mundo”, por que insistir em querer replicar coisas que funcionam na administração de empresas em desenvolvimento de software? A resposta é simples: é muito mais fácil repetir do que pensar! Vamos analisar todos os erros do artigo, e ver como realmente medir a performance de uma aplicação.

Profiling x Benchmark

O ato de medir a performance de uma aplicação é conhecido como profiling, já benchmark é utilizado para medir a performance relativa da aplicação. benchmark é utilizado para medir o desempenho de uma aplicação em diferentes ambientes, fazem isso através de testes genéricos pré-definidos e os dados que resultam dos testes não dizem nada a respeito da aplicação, eles só são úteis se você possui outros resultados para usar de base de comparação.

Já o resultado de um profiling é absoluto. Através deste resultado você sabe em que parte do seu código estão os gargalos e os possíveis gargalos futuros. Quando se está analisando problemas de performance, o profiling é a base de todas as ações que você vai tomar enquanto que o benchmak existe para resolver problemas mais específicos.

No artigo o autor não deixa isso explícito e é extremamente fácil confundir benchmark e profiling. Medir um algoritmo contra outro (como ele fez) é benchmark, medir a performance da aplicação para saber onde ela demora mais é profiling!

Regra Número um de Análise de Performance

Agora sim as coisas ficam um pouco parecidas com o mundo real: como um cientista, no momento de analisar qualquer coisa, você não assume nada. Nada! Esse é o primeiro erro que você pode cometer e todo mundo comete. Para assumir qualquer postura em relação a algo, você precisa ter argumentos. Que argumento é mais convincente do que o resultado de um teste?!

Ferramentas de Benchmark

Quantos de nós usamos o Apache Httpd?! Praticamente todos! Pois então, o Apache Httpd vêm com uma ferramenta imbutida de benchmark muito boa, o “ab” ou “Apache Benchmark”. Com ela você consegue executar testes de chamada a uma determinada URL especificando o número de requisições que você deseja simular, o número de requisições simultâneas e depois comparar os dados. Eis os dados de comparação entre algumas ferramentas de cache em PHP.

Usar o “ab” é bem trivial, um simples “ab –help” é autoexplicativo e você não terá dificuldades em examinar os resultados.

Ferramentas de Profiling

Existe um formato bem conhecido de resultado de profiling chamado “CacheGrind”. É bem comum que ferramentas de profling (independente da linguagem) gerem um resultado em formato CacheGrind, o que aos olhos humanos é um terror, mas que com um programa de leitura fica muito melhor.

Portanto temos duas etapas: gerar um arquivo CacheGrind e analisá-lo. Gerar é fácil, você pode usar o xDebug para fazer isso. O Xdebug, se configurado para, irá gerar um arquivo CacheGrind sempre que uma página for executada. Se nunca usou o xDebug aconselho começar a usar, ele ajuda muito no desenvolvimento além de ser uma ótima ferramenta de profiling.

Para analisar o arquivo gerado temos diversas opcões para diferentes sistemas operacionais. A que eu mais gosto? Webgrind! Você instala ele e pronto. Nada de ficar acostumando com interface que depende do S.O. nem sentir falta de alguma funcionalidade! O WebGrind é bom o suficiente pra substituir qualquer ferramenta de análise CacheGrind desde que o arquivo de análise não seja muito grande. “Mas o que eu posso ver?” deve estar se perguntando.

Através do CacheGrind podemos saber quantas vezes determinada função, arquivo ou método foi executado; quando ele foi executado e quanto tempo demorou cada execução. Podemos ver isso em diversos níveis e em diversas ordens. Isso facilita a análise de gargalos na sua aplicação e direciona seu esforço nesses gargalos e não em suposições.

Performace x Manutenção de Código

Isso é algo que gera controvérsia, mas é muito simples. Tudo o que vimos neste post está relacionado a performance. Benchmark e profilling servem de ferramentas para ajudar a melhorar a performance de sua aplicação, elas por si só não fazem nada. Mas sem elas, você provavelmente não fará nada muito útil nessa área também.

Tenha como prioridade a manutenção de seus códigos! Vamos repetir isso mais uma vez: tenha como prioridade a manutenção dos seus códigos. Esqueça a performace de início. Peformance em último caso se resolve com hardware, manutenção não tem preço que pague nem reza que resolva.

O artigo cita, por exemplo. Trocar objetos por array torna uma aplicação mais rápida? Torna. A pergunta pertinente que deveria ser feita é: a que custo?

Você não vai precisar deixar de usar objetos em sua aplicação, o benefício é mínimo em termos de performance pra perda que você tem na manutenção do código. Dificilmente para qualquer um de nós essa troca chegue a trazer algum benefício! Por esse motivo eu critiquei tanto o artigo no início desse post. O autor foi infeliz na comparação e na conclusão.

Chega de usar PHP como uma linguagem qualquer. Ela evoluiu a muito tempo! Se você se considera um programador, evolua junto com ela! Sem mais “echo” para debug, sem mais “microtime()” para medir desempenho! Estudem, testem, pratiquem, cheguem às suas próprias conclusões!

Conclusões

Não darei nenhuma conclusão aqui, já os incitei o suficiente. Testem o que foi mostrado nesse post em suas aplicações ou seus blogs e cheguem a suas própria conclusões. Uma coisa que não citei no decorrer do post, mas acho importante, é que não existe como chegar a uma conclusão a partir de um único teste. Tenha seu “rol” de dados e a partir dele obtenha suas conclusões.

Eu fui bem duro nas críticas ao artigo citado por um motivo. Se o intuito é ensinar alguma coisa, se preocupe com as coisas que você passa. Pessoas lerão e usarão aquilo em seu dia a dia. Respeito muito as pessoas que passam o conhecimento adiante, mas isso deve ser feito com cuidado. Sugerir indiretamente ao público leitor que arrays são mais rápidos que objetos mostrando uma diferença numérica em um caso hipotético de forma isolada é prejudicial, a impressão que se tem ao final do artigo é de que não devemos usar objetos pois eles irão deixar nossas aplicações lentas, quando provavelmente (pra não dizer certamente) os objetos nunca serão os culpados pela lentidão da sua aplicação.

Augusto Pascutti

Augusto Pascutti é desenvolvedor PHP a 5 anos, trabalhou em projetos Open Source como CakePHP, Zend Framework e Habari. É evangelista PHP e de boas práticas, Zend Certified Engineer para PHP 5, fundador/coordenador do PHPSP, host do PHPSPCast e headbanger nas horas vagas.

Website - More Posts

    1 <?php
    2  if ($_SERVER['REMOTE_ADDR'] == '192.168.2.89')
    3  {
    4    phpinfo();
    5  } else {
    6    echo "<h1>You're like, not authorized to view this.</h1>";
    7  }
    8 ?>

A falha se encontra no fato de que não se deve confiar na variável $_SERVER. É comum as pessoas acreditarem que quem fornece esses dados é o servidor http e que eles são intocáveis. Mas a super global $_SERVER é tão manipulável quanto qualquer outra variável, portanto o que foi criado acima foi uma falsa idéia de segurança.
O post original pode ser encontrado aqui.

Augusto Pascutti

Augusto Pascutti é desenvolvedor PHP a 5 anos, trabalhou em projetos Open Source como CakePHP, Zend Framework e Habari. É evangelista PHP e de boas práticas, Zend Certified Engineer para PHP 5, fundador/coordenador do PHPSP, host do PHPSPCast e headbanger nas horas vagas.

Website - More Posts

Agora ! Podemos conversar de igual pra igual. Pense em um framework. Uma coisa grande. Com várias opções, módulos, suporte a plugins, MVC, talvez um Data Mapper, etc, etc, etc. Agora pense em um tweet: 140 caracteres. São coisas como óleo e água, gato e cachorro, são paulinos e mulheres (eu ainda vou escutar por causa disso).

Pois bem, tentando mostrar a beleza feminina aos São Paulinos – ou que um framework não precisa ser uma coisa grande, pra quem não entendeu a piada -, o fundador do Symphony (o framework) criou o Twitto: um framework do tamanho de um tweet, ou seja: 140 caracteres. Na verdade – e lógico – ele não e grande coisa, simplismente funciona como um Front Controller bem básico. Mas é uma prova de conceito e usa novas features do PHP 5.3, enfim … o dito cujo segue abaixo.

    1 <?php
    2 require __DIR__.'/c.php';
    3 if (!is_callable($c = @$_GET['c'] ?: function() { echo 'Woah!'; }))
    4   throw new Exception('Error');
    5 $c();

Agora você pode se parguntar, quais são as coisas “novas” que o twitto está usando, simples:

• Constante __DIR__
• Operador ?:
• Funções anônimas

No fim, o Twitto existe apenas como brincadeira, e para mostrar alguns novos recursos do PHP 5.3, mas se ele realmente for aceito como framework ele é o mais rápido existente. Mais pra frente mostro uns benchmarks que estou fazendo e o twitto já está neles.

O site do Twitto é: www.twitto.org

Augusto Pascutti

Augusto Pascutti é desenvolvedor PHP a 5 anos, trabalhou em projetos Open Source como CakePHP, Zend Framework e Habari. É evangelista PHP e de boas práticas, Zend Certified Engineer para PHP 5, fundador/coordenador do PHPSP, host do PHPSPCast e headbanger nas horas vagas.

Website - More Posts

Onde queremos chegar com tudo isso? Simples! O mal dos sobrinhos é que logo após seu “Hello World!” eles já se consideram programadores, e logicamente, as coisas não funcionam bem assim. Inspirado num post do Cal Evans (se você nunca ouviu falar nesse nome, google-for-it ! agora!) em que ele diz 5 ferramentas que um programador PHP precisa conhecer, nós dizemos mais: considere-se um programador somente se você conhecer PELO MENOS as cinco ferramentas abaixo!

5: Testes Unitários

Todo mundo bate nesta tecla, hoje temos ótimas soluções ( PHPUnit e SimpleTest ) para isso, todas muito maduras e largamente utilizadas. A vantagem de se desenvolver com o apoio dos testes de unidade ou até mesmo utilizando TDD (Test Driven Development) é notável e díficil de apresentar a quem nunca utilizou. No começo tudo pode parecer muito trabalhoso e inútil, mas com o tempo os testes unitários que você (teoricamente) “perdeu tempo” escrevendo se provam fiéis amigos do programador.

4: Debug

Debugar um código está bem longe de sair dando “echo” pelo código ! Isso vale para as mais rebuscadas técnicas que variam dessa, como por exemplo escrever uma função específica pra isso ou controlar isso através de alguma constante e/ou variável. O debug de um código consiste em ver o que existe na memória de execução do PHP em determinado momento do script, além de possíbilitar controlar o interpretador, parando, avançando a medida que for necessário ao programador. Existem – pra variar – muitas ferramentas pra isso: xDebug, dbg, Zend_Debug, etc …

3: Modelo ER

Trabalhar com PHP invariavelmente significa trabalhar com um Banco de Dados assim como trabalhar com desenvolvimento de sistemas implica invariavelmente em constantes mudanças; é muito lógico no momento de criação de uma nova tabela a modelagem dela e os relacionamentos que ela possui dentro do sistema, mas e depois de 1 ano ? As pessoas mudam, amadurecem (ou não) e mudam o jeito de conceber as coisas, mas o banco de dados continua o mesmo e toda a lógica vai pro saco ! Por isso ter um diagrama de entidade-relacionamento do seu banco de dados pode ser crucial para o andamento de um projeto durante muito tempo, você não perde muito tempo fazendo isso e existem ainda várias ferramentas para ajudar !

( Vamos atualizar a listagem das ferramentas para auxiliar na produão de MERs com o tempo … )

2: Sistema de Controle de Versões

Não vamos perder muito tempo discutindo isso aqui, se você trabalha em equipe ou não, seja seu projeto gigante ou não: use ! Além de manter todas as versões do seu projeto você têm um backup do código. Trabalhar com um sistema de controle de versão se equipara aos Testes de Unidade: você pode passar uma vida inteira sem eles, mas uma vez com eles, nunca mais sem eles !

Existem diversas opções, as mais famosas: CVS (utilizado no desenvolvimento do PHP mas sendo migrado pro Subversion), Subversion (mais novo que o CVS e muito semelhante a ele), GIT (feito pelo Linus Torvalds para o desenvolvimento do kernel do Linux)

1: (Um) Framework

Esse aqui vai gerar briga, mas a briga vale a pena. Primeiro: um CMS (Joomla, Drupal, etc) não é um framework ! Nunca foram e nunca serão, este não é o propósito deles. Um framework é um conjunto de ferramentas genérico que deve servir bem um programador fazendo um site e um fazendo um sistema de gerenciamento logístico de entrega de camisinhas musicais no sertão brasileiro!

Você não precisa utilizar um framework em seus projetos, mas conhecer um ou mais frameworks ajuda em muito seu nível de desenvolvimento! Acredite: você não é o melhor programador que existe ! Existem muitos outros que pensam a mesma coisa! Um fato é que um framework possui muito conhecimento alheio agregado dentro do código, assim como muito teste em ambientes reais.

Muitos pregam que a curva de aprendizado custa demais a empresa. Ora, se a empresa fizer um sistema a partir do zero, novos desenvolvedores também terão que aprender a utilizar as coisas existentes que provavelmente terão menos padrão, menos qualidade e muito menos teste. Outro motivo latente é a performance, uma besteira nós dizemos! Existem muitas formas de se obter performance sem ao menos mexer em uma linha de código, além de que a probabilidade de um framework criado por você ser mais lento do que um existente é bem grande!

Enfim, utilizando ou não um framework no dia-a-dia; conhecer um ou mais é fundamental para o desenvolvimento profissional do programador! Existem MUITOS frameworks em PHP, vamos citar alguns:

• CakePHP (Rails do PHP)
• Zend Framework
• Kohana (baseado no CodeIgniter mas somente para PHP5)
• Symphony
• Prado (Event Driven Framework)

Conclusão

Programar vai muito além de simplimente saber escrever códigos. Um programador não é a pessoa que simplismente escreve o código para máquina interpretar e executar o que ele deseja, ele precisa fazer isso de forma legível para os demais programadores além de garantir que tudo continue funcionando perfeitamente. Todos os cinco itens citados acima contribuem exatemente pra isso!

Tenha sempre em mente o que foi dito acima: você escreve para os outros e não para você! Raramente você vai escrever algo para esconder do resto do mundo, ou que não vá precisar da mão de alguém no código, mas se nada disse te convenceu, escreva os códigos pensando que o próximo que for dar manutenção no seu código pode ser um serial killer que sabe onde você mora! E outra; não existe nenhuma medida que diga seu nível em PHP. Atualmente a melhor delas é a Certificação da Zend, mas excluindo ela da lista, o que vai dizer se você é ou não é um bom programador é a opinião dos outros sobre seu código. Pense nisso na próxima vez em que você for programar!

Notem também que IDEs nem entraram nos pontos, uma porque isso é uma discussão infindável e outra porque uma IDE não vai tornar você um melhor programador, ela com certeza vai te tornar um programador mais produtivo! Então escolha bem a sua!

Contamos com suas opiniões sobre os asssuntos acima! E vamos indo rumo a des-sobrinhação  do PHP!

Augusto Pascutti

Augusto Pascutti é desenvolvedor PHP a 5 anos, trabalhou em projetos Open Source como CakePHP, Zend Framework e Habari. É evangelista PHP e de boas práticas, Zend Certified Engineer para PHP 5, fundador/coordenador do PHPSP, host do PHPSPCast e headbanger nas horas vagas.

Website - More Posts