Pensando nas expressões regulares

Se você já leu uma classe documentada no padrão PHPDoc ou JavaDoc já viu que existe um padrão de criação desses comentários. Eles, na maioria das IDEs, são reconhecidos e para alguns até servem de artifício para que o code insight funcione, buscando essas informações de comentários, negritando nomes ou tipos de variáveis e essas coisas.
Um dos casos mais legais para servir de exemplo seria o caso de um ORM (Object-Relation Mapping). Há pouco tempo, eu e mais dois amigos concordamos em tocar um projeto de um ORM juntos. Esse ORM baseava-se na sintaxe do django e ao documentarmos pareceu um desafio bem legal. Pensamos nas anotações e tudo mais para que pudéssemos dividir as tarefas e uma delas era de criar classes baseadas nos tipos de dados que queríamos para que elas fossem instanciadas nos atributos das classes.
Ao abrir o código de uma classe e vermos a sua documentação, nós podemos ver tags como @author, @since, @version etc. As anotações tem o mesmo padrão, com a diferença que podem ser personalizadas de acordo com a necessidade. No caso de um ORM a primeira que podemos falar seria algo como @table. Essa tag, claramente, nos informaria qual a tabela do banco seria a fonte de dados para essa classe. Veja um pequeno exemplo:

<?
namespace Teste;

/**
* Classe que manipula a tabela de pessoas
* @author Evaldo Barbosa
* @table=tb_pessoa
*/
class Pessoa {
	private $id;
	private $nome;
}
?>

Veja, como falado acima, temos tags que são padrão (como @author). Nesse nosso caso escrevemos a tag @table para informar qual a tabela seria a fonte dos dados. Outras sintaxes, principalmente quando formos anotar dados sobre atributos será mostrados, pois podem necessitar de atributos multivalorados.
Veja abaixo como podemos anotar os dois atributos (id e nome) da classe Pessoa mostrada acima:

<?
namespace Teste;

/**
* Classe que manipula a tabela de pessoas
* @author Evaldo Barbosa
* @table=tb_pessoa
*/
class Pessoa {
	/**
	* @column(type=serial,sequence=tb_pessoa_id_seq);
	*/
	private $id;
	/**
	* @column(type=string,notnull=true,size=80);
	*/
	private $nome;
}
?>

Veja que a tag @column pode ter seu valor type é diferente para cada atributo. Um type serial é para um campo serial, ou seja, uma sequence. No caso do mysql isso é conhecido como auto_increment. O outro tipo (type), string, tem outros atributos como notnull (campo não nulo) e size (tamanho do campo).
Com esses exemplos já podemos detectar alguns padrões de anotações e a partir dai começarmos a implementar as expressões regulares para apanhar essas anotações.

Como fazer e onde testar

Expressões regulares são muito comuns em todas as linguagens e no PHP não é diferente. Nas suas últimas versões aposentamos algumas funções como ereg, eregi, ereg_replace e eregi_replace. Usaremos em nossos exemplos a função preg_match_all que serve melhor para esse propósito.
De acordo com o escrito na sua documentação, existente no site php.net sob o endereço <a href=”http://php.net/manual/en/function.preg-match-all.php”http://php.net/manual/en/function.preg-match-all.php, vemos o seguinte:
int preg_match_all ( string $pattern , string $subject [, array &$matches [, int $flags = PREG_PATTERN_ORDER [, int $offset = 0 ]]] ), onde:
$pattern: é a nossa expressão regular, ou seja, a string que simboliza o padrão a ser reconhecido
$subject: é o texto a ser pesquisado em busca do padrão $pattern. No nosso caso será o comentário da classe ou do atributo;
$matches: é uma variável do tipo array que receberá todas as ocorrências de $pattern em $subject.
Se você usa linux pode baixar o kiki para realizar os testes de expressões regulares. Se não, pode usar sites do http://regexpal.com/ ou http://www.solmetra.com/scripts/regex/ (esse último mais alinhado à nossa função preg_math_all, pois você pode escolher usar a mesma função). O kiki é, para o gnome, a sua melhor opção, nem precisa estar conectado.
Sabendo disso, vamos ao próximo passo, que é criar as expressões regulares para os nossos padrões.

Reconhecendo as suas anotações

Temos @table e @column, ambas tags que precisaríamos no nosso para mapear essa classe, e cada uma com uma sintaxe diferente. Vejamos cada uma separadamente até encontrar cada padrão.
Para a nossa anotação de tabela, temos @table=tb_pessoa, que tem o seu padrão representado por:
@ + tag + = + valor.
Para esse padrão a nossa expressão regular será a seguinte:
@[\w]+[ ]{0,1}=[ ]{0,1}[\w]+, onde:
[\w]+ é a string que dá nome à tag;
[ ]{0,1} é um espaço que pode ou não existir antes do =;
= separa os dois termos (tag e valor)
[ ]{0,1} é um espaço que pode ou não existir depois do =;
[\w]+ é a string que atribui valor à anotação;

Já para a tag de coluna nós temos um padrão um pouco diferente:
@tag + ( + valor + ).
E a expressão regular para isso é pode ser:
@[\w]+[ ]{0,1}\([\w=, \.\-<>:]+, onde:
[\w]+ é a string que dá nome à tag;
[ ]{0,1} é um espaço que pode ou não existir antes do =;
\( escapa a abertura parênteses
[ ]{0,1} é um espaço que pode ou não existir depois do =;
[\w]+ é a string que atribui valor à anotação;
\( escapa o fechamento parênteses.
Para separar os valores dentro dos parênteses você pode usar expressões regulares, explode ou outra função que seja necessária. No momento vamos focar somente em encontrar as tags e descobrir seus valores de forma mais bruta.
Para que usemos a expressão regular tanto para @table quanto para @column, vamos uni-las com o caracter “|” que concatena as duas formando um só $pattern.
A implementação em PHP disso ficaria como no bloco abaixo:

<?
$tags = array();
$pattern = '/@[\w]+[ ]{0,1}=[ ]{0,1}[\w]+|@[\w]+[ ]{0,1}\([\w=, \.\-<>:]+/';
$subject = '/**
* Chave primária
* @type= integer
* @notnull = true
* @size=255
* @meta (atributo1=valor1, atributo2=valor2)
* @meta1 (atributo3=valor3)
*/';
preg_match_all( $pattern, $subject, $tags );
?>

Como obter os comentários e extrair as anotações

Em PHP usamos as classes de Reflection para obter os comentários de classes, métodos e atributos. Para um caso como o nosso devemos usar duas dessas classes: ReflectionClasse e ReflectionProperty.
Extrair os comentários de uma classe é a tarefa de ReflectionClass. Ela é uma classe muito fácil de usar e só precisa de um parâmetro para que possamos começar seu uso. Vejamos:

<?
$reflection = ReflectionClass('Person');
$doc = $reflection->getDocComent();
?>

Agora que já instanciamos ReflectionClass, podemos tranquilamente obter os comentários de seus atributos instanciando ReflectionProperty como a seguir:
<?
$reflection = ReflectionClass(‘Person’);
$doc = $reflection->getDocComment();

$prop = ReflectionProperty($reflection,’id’);
$comment_id = $prop->getDocComment();
?>
No código acima instanciamos ReflectionProperty e a partir dai obtemos os comentários do atributo id na variável $comment_id.
Nesse momento já temos a faca e o queijo na mão, ou melhor, as expressões regulares e os comentários que devem ser submetidos à função preg_match_all e nada mais nos falta.

Conclusão

Anotações em código são coisas muito legais de se ver. Elas organizam, informam e ainda podem servir de metadados para que possamos reaproveitar melhor nossos códigos, nos propiciando uma maior produtividade.
Os códigos acima foram parte da minha base de testes para reconhecer as expressões regulares das tags mostradas acima, mas não pense que outros padrões não podem surgir. Eles, tanto para mim quanto para qualquer outro programador, podem aparecer diante de uma necessidade específica. Tome a liberdade de testar outros padrões.
Eu pesquisei essa solução porque outra (Addendum) não era exatamente o que eu precisava para o momento. Mais uma vez vemos aquela máxima de que “A necessidade é a mãe da invenção”.
Os códigos aqui dispostos estão em uma classe que estão disponíveis para a comunidade no endereço http://github.com/evaldobarbosa. Baixe, brinque, modifique, use. Não se esqueça de me informar se tiver algum outro padrão interessante.
Se solução for interessante e você quiser falar mais sobre, estou no @evaldobarbosa.

Leia direto da fonte: http://computerworld.uol.com.br/gestao/2011/12/12/o-que-custa-mais-corrigir-falhas-em-aplicacoes-java-ou-cobol/

Por PATRICK THIBODEAU, DA COMPUTERWORLD (EUA)

Análise global revela número crescente de erros no desenvolvimento de software por causa da metodologia adotada, aumentando o chamado débito técnico da TI.

Aumenta a quantidade de software mal projetado no mercado mundial, criando uma série de riscos para as organizações, revela relatório global que analisou 745 aplicações. Esses produtos apresentam problemas de programação que violam as boas práticas de arquitetura e de codificação, contribuindo para elevar o chamado débito técnico, que vem ganhando ampla atenção no mundo corporativo.

O termo débito técnico está sendo utilizado pelo mercado para definir a dívida que as equipes de desenvolvimento assumem quando escolhem uma metodologia mais fácil e rápida para criação de aplicativos. Esse tipo de abordagem pode comprometer a qualidade do software e trazer impacto para as companhias no longo prazo.

Os especialistas dizem que assim como o saldo negativo em banco exige pagamento com cobrança de juros, a dívida técnica também pode ter custo alto para as corporações. Uma hora ela precisa ser quitada com a correção das linhas dos códigos escritos errados.

A pesquisa das 745 aplicações foi realizada pela Cast Software, desenvolvedora de ferramentas que avalia a solidez de engenharia da arquitetura e codificação de um aplicativo. A empresa analisou programas de 160 companhias de aproximadamente 12 segmentos da economia.

Uma das conclusões do estudo é que o desenvolvimento de programas com códigos de má qualidade é muitas vezes resutado das decisões de negócios de cortar custos. Para reduzir os investimentos dos projetos, as companhias acabam contratando programadores sem muita habilidade.

Outro fator é a pressão em cima da equipe para que as aplicações sejam desenvolvidas rapidamente para cumprir o cronograma dos projetos. O reflexo são programas que causam falhas de sistemas, diminuem o desempenho dos computadores e abrem brecha de segurança para ataques, entre outros problemas.

Reparar as linhas de código depois que o software está pronto, além de custar muito causa problemas técnicos. Um exemplo histórico de débito técnico foi o “Bug de 2000”, quando muitas aplicações estavam prontas para interpretar os dígitos “00” na virada daquele ano como 1900.

Organizações em todo o mundo gastaram somas incalculáveis de dinheiro para corrigir os dois dígitos. Muitas das aplicações foram destruídas porque desenvolvedores sabiam que o erro surgiria eventualmente.

Custo da correção

A análise da Cast encontrou 1,8 mil tipos de falhas de desenvolvimento em aplicações escritas em Java EE, Cobol, .Net, C, C + + e outras linguagens de programação. A companhia estima que o custo médio para eliminar os bugs por linha de código é de 3,61 dólares. Esse cálculo se baseia no preço hora de 75 dólares cobrado nos Estados Unidos para correção de erros de software.

Outra constatação da pesquisa da Cast é que corrigir falhas de aplicativos desenvolvidos em Java custa mais. O preço para eliminar bugs desta tecnologia é de 5,42 doláres por linha de código, enquanto o mesmo trabalho na plataforma Cobol sai por 1,26 dólares.

Bill Curtis, cientista-chefe da Cast, explica que corrigir linhas de código de Cobol custa menos porque a linguagem é mais antiga e os programadores são mais experientes. Por estarem atuando há mais de 30 anos com nessa tecnologia, eles conseguem corrigir falhas críticas mais rapidamente.

Sobre Java, Curtis constata que há muitos profissionais iniciando agora o desenvolvimento nesta linguagem sem formação científica em computação. “Tem uma enorme quantidade de pessoas escrevendo código sem ser guru em engenharia de software”, percebe o executivo.

Implicações do débito técnico

O estudo da Cast reforça a necessidade de as companhia entenderem as implicações do débito técnico, informa Carolyn Seaman, professora adjunta de sistemas de informação da Universidade de Maryland, em Baltimore (EUA), e coordenadora de um programa da National Science Foundation sobre esse tema. De acordo com ela, o tema gera preocupação devido ao risco que pode trazer para os negócios.

O instituto de pesquisas Gartner estima que o débito técnico no mercado mundial subirá de 500 bilhões de dólares em 2010 para um trilhão de dólares em poucos anos. Para Carolyn diminuir essa dívida não é tarefa fácil. Ela considera que o maior obstáculo é a incerteza sobre adoção de técnicas de desenvolvimento e abordagens que realmente resultam em maior qualidade de software.

O crescimento do débito técnico está estimulando a criação de um guia de riscos para os negócio informa John Heintz, consultor técnico da Cutter Consortium. Ele diz que esse problema já está sendo tratado como uma questão de due diligence em fusões e aquisições, aumentando a consciência de que o tema está influenciando as práticas de desenvolvimento de software.

Na opinião de Heintz colocar mais atenção sobre o débito técnico não significa que os desenvolvedores não tenham de diminuir gastos para acelerar o desenvolvimento. “Às vezes é apropriado e necessário cortar custos, mas esse fato não pode ser ignorado”, disse ele.

O Software Engineering Institute (SEI) da Universidade Carnegie Mellon, centro de pesquisa financiados pelo pelo Departamento de Defesa dos EUA, está trabalhando a questão do débito técnicos há cerca de dois anos. A instituiçao vem organizando workshops sobre o tema, de acordo com Ipek Ozkaya, membro sênior da equipe técnica.

“Existe interesse crescente neste assunto porque empresas e desenvolvedores querem entender seus fundamentos”, afirma Ozkaya. Ele observa a falta de orientação sobre como fazer o levantamento dessa dívida e como quitá-la para evitar implicações futuras.

Visto em: http://www.robertodiasduarte.com.br/o-que-custa-mais-corrigir-falhas-em-aplicacoes-java-ou-cobol/

Me perguntaram outro dia: como enviar uma requisição POST usando PHP com dados JSON corretamente formatados? Recorri aos slides do meu tutorial de web services para a resposta, e pensei em colocar aqui com algumas explicações. Afinal, publicar seus slides é algo bom, mas sem o tutorial de fato, acho que eles raramente são úteis.

Não podemos enviar campos POST, porque queremos enviar JSON, e não simular um formulário (o mérito de uma API que aceita requisições POST com dados em formato de formulário é um debate interessante). Ao invés disto, nós criamos o JSON, o definimos como corpo da requisição POST e definimos os cabeçalhos corretamente para que o servidor que receba a requisição possa entender o que enviamos.

$data = array("name" => "Hagrid", "age" => "36");
$data_string = json_encode($data);                                                                                   

$ch = curl_init('http://api.local/rest/users');
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_POSTFIELDS, $data_string);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
    'Content-Type: application/json',
    'Content-Length: ' . strlen($data_string))
);                                                                                                                   

$result = curl_exec($ch);

Todas estas definições estão bem explicadas na página curl_setopt(), mas basicamente a idéia é definir a requisição para que seja um POST, fazer com que os dados codificados em JSON sejam o corpo da requisição e definir os cabeçalhos corretos para descrever o corpo da requisição. O CURLOPT_RETURNTRANSFER é puramente para que a resposta do servidor remoto seja colocada em $result, ao invés de “ecoado”. Se você precisa enviar dados JSON com PHP, espero que isto ajude!

Autoria: lornajane@lornajane.net, @lornajane

Foi um grande 2011. Tivemos PHPráticas com palestrantes nacionais, tivemos a terceira edição do Fórum Maranhense de Profissionais PHP (3.PHP) com palestrantes internacionais. Ganhamos dois articulistas para o blog (e ainda estamos precisando de mais). O grupo recebeu novos integrantes, repensamos algumas “verdades” sobre a realização dos eventos locais, dentre outras evoluções profissionais dos envolvidos.

Este não deve ser o último artigo do ano, já que em dezembro ainda participaremos da PHPConference 2011, o principal evento de PHP da América Latina, e devemos trazer algumas novidades.

Para 2012, muitas inovações no radar. Acompanhe o site (assine nosso RSS) e se inscreva na lista para não perder nada.

Todos os integrantes da equipe de eventos agradecem a participação de cada estudante e profissional que tem esta vontade de crescer e que esteve presente nas edições. Agradecemos também aos parceiros, apoiadores e patrocinadores. Nenhuma ação que fizemos seria possível sem cada um de vocês.

Até o ano que vem, no PHPrática de fev. 2012, em 11/02/2012.

Agradecemos ao Er Galvão pelo excelente minicurso. A impressão geral dos participantes foi de que o curso foi realmente focado nos aspectos práticos, mostrando como explorar as vulnerabilidades e principalmente como resolvê-las. Alguns participantes se confessaram preocupados e disseram que, apesar da noção do trabalho que têm pela frente, já sabem por onde começar e como resolver os problemas dos seus sistemas.

Nosso agradecimento especial ao Uniceuma, em especial ao Prof. Sérgio Martins, que viabilizou toda a infra necessária à realização do evento.

Seguem algumas fotos do minicurso:

O material do minicurso está disponível em http://slideshare.net/ergalvao.

Nossa próxima edição é só no ano que vem. Fique ligado para não perder. Até lá.

Anunciamos a realização do PHPrática nov/2011. Será no Uniceuma Campus Renascença. Como nas edições anteriores, os participantes devem entregar 1 Kg de alimento não-perecível no local do evento. Os alimentos serão encaminhados para doação.

Nesta edição teremos a presença do especialista em segurança da informação Er Galvão Abbott, que virá de Porto Alegre, RS para ministrar o minicurso “Top 10 Owasp Vulnerabilities”, elencando as 10 maiores vulnerabilidades Web e como mitigá-las.

O público-alvo são desenvolvedores Web de qualquer linguagem. As soluções que ele mostrará utilizando PHP são facilmente adaptáveis para quaisquer linguagens, já que tratam-se principalmente de mudanças de abordagem, método ou técnica e não são específicas do código.

Estão todos convidados.

Dia 18/11, sexta-feira, das 14h00 às 18h00.

Leve 1 Kg de alimento não-perecível.

Após o evento, participe do PHPinga^©, nosso happy-hour pós-evento que acontecerá no Por Acaso da Lagoa, a partir das 19h00.

A hashtag oficial do evento no twitter é #phpratica e a venue no 4sq é “PHPrática novembro de 2011.”

Uma das palestras que seguiram foi a do Er Galvão, falando sobre Zend_Acl e de uma implementação bem interessante a que ele chegou.

No fim da palestra dele, um dos congressistas fez uma pergunta muito interessante que eu gostaria de compartilhar. Ele informou que tinha enfrentado muitos problemas com o uso de Acl com módulos do Zend e pediu orientações sobre como resolvê-los.

Como este é um dos assuntos que me interessam e porque minha palestra falava exatamente sobre APIs, pedi licença ao Galvão e me meti na conversa. Tenho visto que o principal benefício “vendido” por quem usa módulos é o reuso da camada model da aplicação. Você pode implementar “sub-aplicações” usando o mesmo conjunto de classes, evitando a reescrita do código de negócios.

Na minha opinião, isto é uma gambiarra para tentar contornar uma limitação clara do modelo MVC, que é o de estar contido em uma aplicação.

Quem acompanhou a evolução dos frameworks, biblioteca de classes e template engines sabe que surgiram diversas tentativas de generalizar controllers e views. A maioria vai bem, obrigado. Mas não faz sentido usar um componente de software para generalizar o model, uma camada que é específica para uma aplicação ou um grupo de aplicações. E esta é a limitação.

A resposta que dei para o congressista e sobre a qual voltei a comentar ontem é sobre um paradigma de desenvolvimento que estamos usando massivamente na Nexy: APIs.

Todos os novos sistemas que estamos desenvolvendo abusam de APIs. Mesmo que sejam apenas para uso interno. O que está lá implementado é a antiga camada model, acrescida de um fino controller apenas para rotear, instanciar, executar e retornar. Existem várias soluções para implementação rápida de APIs. A mais simples que conheço é o GRS, de código aberto e desenvolvido internamente (http://github.com/ramcoelho/grs), onde você implementa apenas as classes do model. Outra, muito mais flexível é o Respect/Rest (http://github.com/respect/rest).

São evidentes as vantagens de usar esta abordagem em todas as aplicações (mesmo as internas). Talvez você não perceba a necessidade de manter o controle de pedido de materiais sob uma API, mas apenas o fato dela existir, torna muito mais fácil a automatização posterior que venha a surgir, além de reforçar o mantra “programe para uma interface”, facilitando a vida de outro programador que seja envolvido na solução.

O resultado direto é que, sem a necessidade de compartilhar o model dentro da aplicação, os módulos viram aplicações distintas, todas compartilhando a mesma API.

Esta idéia é suportada por empresas como Twitter, Foursquare, Google, e certamente estão no cerne do grande sucesso do Facebook e seus aplicativos e jogos.

Este ano tivemos o apoio inestimável do SEBRAE-MA, com infra-estrutura profissional elogiada por todos os palestrantes e congressistas.

A organização e promoção do evento ficaram à cargo da Nexy, como em todas as edições anteriores, custeando o evento como um todo. Nosso muito obrigado a todos os envolvidos.

Nossos agradecimentos especiais também à DBSeller e à PlumWillow, que mesmo tendo atuação maior fora do estado, fizeram questão de patrocinar um evento de comunidade local.

Vamos aos números.

Foram 12 palestras, de 10 palestrantes, 7 de fora do estado. Passaram pela sala cerca de 115 pessoas diferentes, em sessões de até 60 por vez. Alcançamos um total de 231 pessoas via streaming. Todas divulgando o evento nas redes sociais.

Nossa projeção de alcance totalizou 1.300 pessoas. Nada mal para um evento de comunidade regional.

Ano que vem tentaremos uma sala maior para que ninguém fique de fora.

Parabéns aos congressistas, aos palestrantes, à organização e aos patrocinadores. Até a próxima.

Seguem algumas fotos do evento.

Projeto finalizado e homologado, era hora do deploy. Como o cliente já possuía um servidor configurado e rodando outras aplicações internas, solicitou a disponibilização no mesmo ambiente.

Então nos deparamos com o obstáculo que motivou este artigo.

O ambiente era Debian Lenny (5.0), que por padrão usa a versão 5.2 do PHP em seus repositórios.

Grande parte do código do Grs não funciona no PHP 5.2 e é claro que a nossa primeira sugestão foi upgrade do ambiente. Por diversos motivos que não cabem no objetivo deste artigo, o cliente não autorizou o upgrade.

Ao invés de realizar o downgrade do Grs, optamos por investir um pouco mais de tempo fazendo o upgrade específico do PHP 5.3 no Lenny.

Já que todos adoramos a flexibilidade dos pacotes .deb, tentamos evitar recompilar o PHP a partir dos fontes.

Segue o procedimento que resolveu o problema, com nossos agradecimentos a http://www.dotdeb.org/2009/11/30/php-5-3-1-packages-for-debian-lenny-theyre-here/. Se você for seguir o texto do artigo, lembre-se de trocar “stable” para “lenny”, já que a versão stable hoje não é mais lenny (na data deste artigo é “squeeze”).

Inclua as linhas abaixo em seu /etc/apt/sources.list:

deb http://php53.dotdeb.org lenny all
deb-src http://php53.dotdeb.org lenny all

Atualize os repositórios locais: sudo apt-get update

Se o sistema reclamar que a chave não está presente (NO_PUBKEY), tente a solução de http://en.kioskea.net/faq/809-debian-apt-get-no-pubkey-gpg-error, lembrando de substituir a chave do artigo pela indicada na mensagem de erro (quando o artigo foi escrito: E9C74FEEA2098A6E)

gpg --keyserver pgpkeys.mit.edu --recv-key E9C74FEEA2098A6E
gpg -a --export E9C74FEEA2098A6E | sudo apt-key add -
sudo apt-get update

E por fim:

sudo apt-get dist-upgrade

Lembre-se de fazer backup antes de realizar procedimentos de ampla atualização e, se possível, testar em um box de homologação antes.

Boa sorte.