Este ano esteve em destaque a PHPTestFest09, sendo realizada em vários cantos do mundo e destacando-se a participação do PHPSP que contribuiu com o maior número de testes. Ficou de fora? Então já comece a se preparar para ano que vem.

O PHPT é um framework extremamente simples de testes criado e usado internamente pelos desenvolvedores do core. Ele é extremamente atômico e centrado em testes como os que esperamos do PHP, como testar funções e bugs específicos.

O que preciso saber?

A grande vantagem do PHPT é que para poder escrever um teste, tudo que você precisa saber é: como escrever código PHP. Claro que um pouco de conhecimento interno do funcionamento do PHP vai te ajudar a procurar detalhes para testar, mas sabendo escrever PHP você já pode contribuir com uma grande percentagem dos testes que precisamos.

Vamos então atacar por partes:

1. Preparando o ambiente
2. Escolhendo um teste
3. Escrevendo um teste
4. Rodando um teste
5. Enviando seu teste para o PHP

1. Preparando o Ambiente

A preparação do ambiente não é nada complicada e exemplos estão disponíveis para referencia. A primeira coisa que você precisa é da versão do PHP que vai precisar para rodar testes. No caso do TestFest focamos no PHP 5.3, no momento recomendo pegar as últimas disponíveis na página do PHP QA (qa.php.net) vá lá e baixe o pacote (source ou binary para windows).

Em ambientes Linux/Mac Os X, você irá passar pelo processo de compilar o PHP, passando pelos processos normais de “./configure”, “make” mas antes de rodar o “make install”, você poderá rodar o comando “make tests”. Este comando irá rodar todos os testes do PHP (em torno de 900+), pode demorar, mas é um ótimo procedimento, pois ao final você poderá mandar um relatório para a equipe de QA e “fazer sua parte”. Rode também o comando make install pois durante a confecção de um teste será interessante você poder testar ele com a versão correta do PHP.

Mais pra frente vamos ver como usar o make tests para rodar os seus novos testes.

2. Escolhendo um teste

Antes de escrever um teste é necessário escolher o objeto de nosso teste. Para tal é preciso identificar um ponto do PHP que necessita de um teste, isto pode vir de duas fontes, um bug ou uma linha de código não “coberta” (code coverage). Para descobrir bugs com/sem testes a melhor forma é olhando a pasta de testes da extensão do bug (GD -> /ext/gd/tests) ou conversando com o pessoal na lista do QA.

Para testes específicos de linhas de código sua melhor aposta é o site http://gcov.php.net onde você deve navegar até a versão correta que esta testando e então escolher uma área sem cobertura. No caso da testfest deste ano, o PHPSP focou na GD pois sua cobertura estava bem baixa então navegamos até o gcov do gd.c para ver onde poderiamos atuar. Para fazer esta parte do processo um conhecimento básico de C e de como o PHP funciona por baixo dos panos é muito bom, mas após alguns testes você aprende a identificar os pontos e durante o testfest o Guilherme Blanco e o Erick nos ajudaram a entender o código.

Para exemplificar melhor vamos ver como identificar estas linhas e o que elas fazem. Veja por exemplo a linha abaixo:

O que queremos é que todas as linhas fiquem azuis (executadas) ou brancas (código não executável), as linhas não testadas estão marcadas de vermelho. Identificando a linha 1856 como não executada devemos interpretar que como há um if logo antes, a condição “== FAILURE” nunca é atingida, ou seja, esta linha nunca é executada pois a função zend_parse_parameters não retorna falso em nenhuma das chamadas a função imagecolorallocatealpha identificada logo ali encima na linha 1848.

Mas e ae? Ok, a função zend_parse_parameters é responsável por validar os parâmetros da função, ou seja, para testar esta função precisamos escrever alguns testes que passem parâmetros inválidos para a função e verifique se ela alerta o erro corretamente. Agora podemos passar para o passo de escrever este teste.

3. Escrevendo um teste

Escrever um teste é incrivelmente simples, e como testes devem ser objetivos e pontuais isso é bem claro. Você deve limitar o escopo de seu teste, procurando testar apenas uma função ou aspecto. Isso irá facilitar a nomeclatura de seu teste.

3.1 Nomeclatura de arquivos

A nomeclatura é bem simples:

• Teste para bug: bug<bugid>.phpt
• Funcionamento básico da função: <função>_basic.phpt
• Erros da função: <função>_error.phpt
• Variação do funcionamento da função: <função>_variation.phpt
• Extensões: <extensão>_<#>.phpt

3.2 Estrutura de um .phpt

Arquivos de teste seguem uma estrutura bem simples:

--TEST--
strtr() function - basic test for strstr()
--FILE--
/* Do not change this test it is a README.TESTING example. */
$trans = array("hello"=>"hi", "hi"=>"hello", "a"=>"A", "world"=>"planet");
var_dump(strtr("# hi all, I said hello world! #", $trans));
?>
--EXPECT--
string(32) "# hello All, I sAid hi planet! #"

Como vemos, a sessão TEST é um título de uma linha do teste descrito no arquivo. A sessão FILE é usada como o corpo de um arquivo .php que será gerado para o teste, e a sessão EXPECT demonstra o resultado que esperamos da execução da função. Recomenda-se o uso de var_dump para gerar saídas.

Estas são sessões padrões, mas a documentação completa pode ser vista aqui: phpt format

Você poderá ver situações onde os blocos acima não são o bastante, mas em geral você estará checando para ver se executando a função X irá retornar a saída esperada. Porem um bloco é interessante ser mencionado aqui, o bloco CREDIT. Caso você não tenha acesso ao CVS, colocando seu nome nesse bloco irá levar seu nome aos créditos do PHP, no caso do TestFest utilizamos este formato:

--CREDIT--
Rafael Dohms <myemail@gmail.com> #PHPSPTestFest 2009-04-DD

Ok. Vamos tentar escrever um teste agora para ver se entendemos tudo até agora. Usando o exemplo acima onde identificamos uma linha não coberta por testes, vamos escrever um teste para testar o primeiro parâmetro da função. Observe a linha abaixo:

zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rllll", &IM, &red, &green, &blue, &alpha)

O que devemos entender aqui é o trecho que diz “rllll” pois ele identifica o tipo que cada parâmetro deve ter, neste caso o primeiro parâmetro deve ser um “Resource” por isso o “r”, e os outros devem ser do tipo “long”. Pare um momento agora e verifique o manual do PHP para esta função

int imagecolorallocatealpha ( resource $image , int $red , int $green , int $blue , int $alpha )

Ele confirma exatamente o que vemos no código, mas você poderia também achar uma situação onde o manual esta incorreto, mais um ponto onde você poderia contribuir com o PHP.

Voltando ao nosso exemplo, vamos então escrever um teste para testar a validação do primeiro parâmetro da função. Verificando a pasta /ext/gd/tests vemos que não há testes desta função, mas especificamente não há um teste chamado imagecolorallocatealpha_error1.phpt, então como vamos testar justamente isto, podemos usar esse nome. (podemos usar _error2… para os outros parametros por exemplo)

--TEST--
Testing imagecolorallocatealpha(): Wrong types for parameter 1
--CREDITS--
Rafael Dohms <rdohms [at] gmail [dot] com>

Primeiramente vamos definir o título, deixando claro que estamos testando o parâmetro 1 da função e adicionar nosso crédito, que também é importante se houver algum erro no teste ou adaptação e precisarem saber quem foi o autor original do mesmo.

--SKIPIF--
<?php
if (!extension_loaded("gd")) die("skip GD not present");
?>

O bloco –SKIPIF– é muito importante neste caso. Como estamos testando uma função da GD, que é uma extensão do PHP, ela não estará sempre ativada, portanto só devemos executar os testes caso a extensão esteja ativa. O bloco SKIPIF é exatamente para isso, faça as verificações necessárias, caso não deva rodar, execute um die. O processo que executa os testes interpreta isso como SKIP e não FAIL. Isto vale para outras condições também, como arquivos necessários e qualquer outro fator que possa determinar se um teste deve ou não ser “pulado”.

--FILE--
<?php
$resource = tmpfile();

imagecolorallocatealpha($resource, 255, 255, 255, 50);
imagecolorallocatealpha('string', 255, 255, 255, 50);
imagecolorallocatealpha(array(), 255, 255, 255, 50);
imagecolorallocatealpha(null, 255, 255, 255, 50);
?>

Este é o corpo do teste, a parte mais importante. Basicamente estamos executando a chamada à função com diversos parâmetros inválidos, como strings, arrays e um resource que não é uma imagem. Passando um resource que não é imagem estamos na verdade testando a linha 1859, mas é uma condição importante de se testar também. O restante dos parâmetros recebem valores válidos.

--EXPECTF--
Warning: imagecolorallocatealpha(): supplied resource is not a valid Image resource in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, %s given in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, array given in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, null given in %s on line %d

Finalmente vamos testar o resultado. Aqui no caso utilizamos o EXPECTF que funciona como um printf, poderíamos ter usado outros disponíveis com expressões regulares por exemplo, mas o funcionamento deste é bem mais simples. Aqui basicamente estamos conferindo se o texto de erro bate com o que esperamos e como usamos um formato de printf $s e %d substituem textos que são dinâmicos, como o nome do arquivo que varia em cada máquina.

Dica: Para obter as mensagens de erro, rode o arquivos usando o PHP, ex: php imagecolorallocatealpha_error1.phpt. O arquivo será executado, todo conteudo dele será echoado na tela, mas dentro do bloco –FILE– o conteudo que aparecer é o resultado da execução.

4. Rodando um teste e fazendo faxina

Agora você tem um arquivo phpt pronto e precisamos ver se este teste esta mesmo passando. Para isso precisamos chamar o executor de testes e passar o nosso teste, caso contrário ele irá executar todos os 900+ testes. Para fazer isso o processo é simples, execute o comando make test da mesma forma de antes, mas definindo o parâmetro TESTS, assim:

make test TESTS=ext/gd/tests/imagecolorallocatealpha_*.phpt

Você pode dar o caminho completo para o arquivo, ou usar um wildcard como assim, isso é útil se você acabou de escrever os testes para todos parâmetros e quer rodar todos testes daquela função.

Veja o resultado:

Note que o teste passou, como indica o PASS logo em frente ao que escrevemos no bloco –TEST–.  É interessante também comentar o que acontece quando um teste falha, além de ser marcado com um FAIL o sistema gera um numero de arquivos com o mesmo nome e diferentes extensões:

• .out – output do arquivo php criado po teste
• .php – o código gerado para o teste (bloco –FILE–)
• .diff – uma comparacao do que foi o output e do que se esperava
• .exp – o texto em –EXPECTEDF– isaolado
• .log – um resumo do processo

Estes arquivos são muito uteis para que se analise o resultado e poque da falha.

5. Enviado seu teste para o PHP

Você possui algumas formas de fazer seu teste chegar no PHP. A primeira é participando do PHPTestFest anual, onde todos os testes são enviados para um repositório separado e então integrados ao SVN oficial. A segunda forma é você enviar este teste que escreveu para a lista do QA Team e alguem irá colocar ele no SVN por você. A terceira forma é uma junção de ambas, muitas pessoas apos a testfest são presenteadas com contas do SVN e karma para poderem comitar seus próprios testes, como ocorreu comigo (viu, não é mentira!)

Conclusão

Pronto, agora você tem todas as ferramentas para começar a escreve testes para o PHP. O PHPT é excelente para sua função em testes do PHP, mas testes não param por ai, procure incluir os testes em seus sistemas e bibliotecas, mas para isso procure o PHPUnit e aprende sobre Test Driven Development (TDD). Em breve falarei destes por aqui também.

PHP, phpt, tdd, testfest

PHP, tek09

O primeiro dia em Chicago começou cedo, as 5h. Do aeroporto pro hotel foi uma viagem tranquila, após ligar para o excelente supporte da MTACon que prontamente me apontou pro transporte do hotel, sim.. o aeroporto é enorme!

Checkin sem problemas, internet fácil e dencente (fail no form, letras brancas/fundo branco), um banho e pé na estrada. Mas não antes de esbarrar com grandes nomes na porta do hotel, como Derick Rethans, Andrei Zmieski, Sara Golemon e mais uma meia duzia, a caminho da Microsoft, que cedeu uma sala para uma reunião interna do PHP (go Gates!). O resto da tarde foi o que é toda viagem de um brasileiro para os EUA… cara! Muitas compras, mas faz parte.

No retorno desci para o lobby onde pude conversar com muitas figuras, dentre elas Eli White, Keith Casey, Gregg, Sebastian, enfim, muitos. Após muita conversa vem, conversa vai o papo seguiu para o Shoeless Joe’s, ou era Shirtess Schmoe’s? Enfim, janta regada a muita cerveja e mais “celebridades”, como Ben Ramsey, Elizabeth Smith, Michalangelo Van Dam, e diversos. Por sinal, FAILS stickers brotavam de todo lado, sem dúvida a culpa é do Spoons.

Chegada no hotel ainda me surpreendeu com um encontro com Lorna Jane, Chris Jones .. são muitos nomes. Dentre todas estas conversas destaco uma com o Gregg sobre tecnologias e projetos de geolocation. Um execlente papo com o Michelangelo sobre comunidades e o que anda acontecendo pela Bélgica, esse papo merece mais atenção em breve. E um papo legal sobre conferencias e o que o Brasil tem a oferecer neste campo com o grupo de volta no hotel.

Dia pré-evento foi um sucesso, muitos contatos e amigos. O primeiro dia de conferência amanha promete.

PHP, tek09

Este ano estarei presente na php|tek, conferencia de PHP muito famosa que ocorre em Chicago nos Estados Unidos. A conferencia é organizada pela MTA, mesma empresa responsável pela PHP|architect renomada revista impressa e digital de PHP.

Fique atento ao meu twitter e neste blog (ou no blog em inglês) pois estarei postando novidades nele ao longo da viagem, que vai ocorrer de 18/05 a 22/05.

Desde que me mudei para São Paulo minha participação na comunidade PHP em geral esta cada vez mais emocionante. Desde que conversei com alguns amigos e decidimos organizar o PHPSP (Grupo de Desenvolvedores PHP de São Paulo) as ídeias não param de surgir, e muitas ideias já estão virando fatos concretos.

A algum tempo venho ouvindo ótimos podcasts, tudo começou com o Nerdcast que tras um pouco de diversão ao meu dia toda manha no trem. Logo me vi procurando algo relacionado ao PHP e acabei esbarrando em dois podcasts, o PHP Abstract realizado por Cal Evans e o P3 da equipe do php|architect. Este projetos eram otimos e renderam alguns bons episódios e descobertas. Porém, perto do final de 2008 todos sumiram, sendo que o último P3 foi gravado ao redor de uma mesa em um evento descontraido de PHP, gerando um excelente episódio com o mesmo ambiente de descontração.

Continuei alimentando minha fome de podcasts ouvindo o Nerdcast, que para quem não conhece é um bate papo divertido entre amigos sobre diversos assuntos, algo muito próximo de um papo de mesa de bar. Este clima de mesa de bar rende momentos excelentes, muita risada e ao mesmo tempo uma absorção de conhecimento enorme, como dizem, você aprende sem perceber.

Por algum tempo pensei que o PHP precisava de um podcast, e após ouvir meu colega Luciano do site “A Sala” gravar o primeiro podcast junto com amigos (CineCast), a idéia estalou. Por que não unir a diversão do Nerdcast com meu ganha pão, o PHP? Foi exatamente isso que fizemos.

Conversei com os coordenadores do PHPSP, respectivamente, O Augusto, Anderson e Ivan, e decidimos que a idaia tinha tudo para dar certo. Nem duas semanas depois do espório da ideia, já estavamos testando nossos softwares gravando o primeiro episódio. No momento da gravação este seria apenas um “teste de microfones” mas a facilidade que encontramos em começar a falar sobre o assunto nos levou a seguir em frente. Variando entre uma apresentação da iniciativa, falando sobre o PHPSP e apresentando projetos relacionados, como o PHPBC,  o podcast foi um excelente primeiro passo. Após a gravação possamos pela primeira grande dificuldade, a edição. Sem nenhuma pessoa com experiência em edição e audio em geral tivemos que nos virar com vinhetas e musicas, mas a experiencia foi muito divertida e o resultado final muito satisfatório.

Assim nasceu o PHPSPCast, que você pode ouvir aqui, especificamente o primeiro episódio. A recepção foi incrível com diversas mensagens de apoio e incentivo, além de centenas de downloads em poucos dias. Este resultado só que dizer uma coisa, acertamos e devemos seguir em frente.

O PHPSPCast #1 já esta sendo gravado, desta vez eu não estarei participando, pois estou atualmente na África do Sul a trabalho e sem uma conexão de internet decente o bastante para podermos gravar o cast, sem contar o fusu horário que me faria gravar no meio da madrugada. Este episódio será coordenado pelo Augusto e contará com dois convidados então fiquem de olho no resultado e aguarde novos episódios. Visite o site do PHPSPCast e descubra como enviar sugestões de assuntos, feedback e você poderá inclusive ter seu email lido no proximo episódio.

Espero que gotem do resultado e que possamos trazer mais informações para a comunidade PHP com este cast, 0 primeiro podcast de PHP na lingua portuguesa.

PHP, phpsp, phpspcast, podcast

Com o crescimento continuo da importancia do Wordpress no mundo Blogger um item está cad vez mais em destaque, os plugins para wordpress. Muitos defendem que o Wordpress já não é mais um simples sistema de blog e que pode virar muito mais, como um CMS e diversos outros usos, vejamos por exemplo o Ministério da Cultura, cujo site é feito com base no WP.

O sistema, embora tenha diversas polêmicas sobre seu código, foi desenhado de forma a permitir diversos ganchos e pontos de conexão em sua API para podermos plugar nossos plugins, executando atividades nos mais diversos momentos da execução de um request, ou da exibição de um post. Algum tempo atrás me dediquei a escrever um artigo completo sobre o desenvolvimento destes plugins, que é hoje o segundo post mais acessado no meu blog.

A algum tempo venho recebendo ideias e pedidos de pessoas que querem desenvolver plugins para seus blogs, eles tem um problema, inventam uma solução, mas esbarram no PHP ou no codigo fonte do WP e acabam deixando de lado. Muitas vezes já existe um plugin no repositório do WP que atende ao que é buscado, porém em alguns casos sua ideia tem um twist, uma diferença ou é simplesmente original, e nessas horas você precisa de alguma ajuda.

Venho querendo pegar projetos pontuais e pequenos para fazer, já que projetos grandes acabam de vez com meu tempo livre e me ocupam por muito tempo. Portanto estou abrindo aqui um espaço para ajudar estas pessoas aqui, e estarei disponibilizando uma oportunidade para criar plugins para os outros.

Esta iniciativa possui tres planos:

1. Plano Open Source: Você contribui com a ideia do plugin, eu desenvolvo ele, divulgo aqui no blog e publico no repositório do link. O código fica aberto a todos e o crédito do plugin é dividido entre você e eu.
2. Plano Pago: Você me fornece com o briefing do plugin, eu desenvolvo o plugin e lhe entrego todo o código para você usar ou divulgar como quiser. O plugin carregará apenas o seu nome nos créditos.
3. Plano Combinado: Este plano é uma mistura dos dois acima, novamente a ideia é sua, mas neste caso o código não é aberto (open source), pertencendo apenas a você, porém o crédito é novamente dividido entre você e eu. Neste caso o custo de desenvovimento é reduzido.

O preço dos plugins será feito sobe encomenda de acordo com o nivel de complexidade do mesmo e de outros fatores, e será divulgado após o contato inicial para o orçamento. Somente no caso do Plano Open Source não existe nenhum custo.

Vou desenvolver os plugins dentro do tempo livre que tiver então os prazos serão negociados cuidadosamente para evitar maiores problemas. Para acompanhar todo esse serviço, estarei utilizando o Redmine, um gerenciador de projetos, por isso vejam ele aqui:

DMS Systems – Gerenciador de Tarefas

Usem esta página [http://dev.rafaeldohms.com.br/wiki/wp-plugins/Open-Source_Plugin_Ideas] para cadastrar suas ideias de plugins Open Source, ou este email [rafael+plugins@rafaeldohms.com.br] para pedir orçamentos de plugins nos planos Pago e Combinado

Observação! É importante notar que cadastrar sua ideia não tras garantia de que seu plugin será escolhido e desenvolvido, tudo irá depender do meu tempo livre e da quantidade de plugins que apareça por ai.

PHP, plugin, Wordpress

O primeiro encontro do PHPSP foi um sucesso!

Não pela número massivo de presentes, perto de eventos como a PHPConf , 25 pessoas é um número pequeno, mas sob a perspectiva de que foram 25 onde só tinhamos espaço para 30, e que este foi um evento gratuito e por isso sem “compromisso”, o número de presentes foi sim incrível.

Não pelas palestras, ou será que o ambiente descontraído que mais parecia uma mesa redonda deixa de ser uma palestra? É isso também foi incrível.

Não pelos prêmios, até porque não forma prêmios, foram brindes, prêmios são itens reservados a poucos, quando todos ganham… é brinde não é?

E finalmente não pelos “congressistas”.

Sim pelos companheiros! Todo evento conta com congressitas, você conhece um ali, outro lá, mas 70% do tempo você não conhece quem esta sentado do seu lado, ou até palestrando. No encontro não tinhamos congressistas, tinhamos companheiros, a partir da abertura sabiamos exatamente quem etava sentado de cada lado e estava la na frente falando. Isso foi sim um dos fatores de sucesso do evneto, na minha opinião, nada de números, um grupo pequeno, mas que ficou unido. Isto promoveu um networking sem igual, muitas trocas de cartão e muitos “ah, você é o fulano?”, “você é responsável por aquele site?”.

O almoço em grupo também teve esse reflexo, todos juntos, uma mesa enorme, e muito papo. O valor maior que tiro da experiencia foi a motivação, todos interessados em participar, em mudar, não só suas carreiras, mas mudar o PHP, contribuir, participar. Essa mensagem é a mesma que foi passada em evento gigantes como a ZendCon, participe, contribua. Mas é possível comparar nosso encontro com um evento destes? Sim! É um encontro menor sim, mas tenho certeza que os contatos que lá forma feitos, se assemelham muito aos que se faria em grandes eventos, e tenho certeza, que deste primeiro passo começa uma grande caminhada e veremos muitos destes primeiros presentes, no futuro do PHP.

Parabéns à coordenação e aos presentes

Foquem de olho neste espaço PHPSP.org.br que o movimento não para aqui.

Seguindo a frase cunhada no evento “PHPSP – Rumo a des-sobrinhação”

des-sobrinhação, encontro, PHP, phpsp

Embora publicado em 2005, o livro “Essential PHP Security” trata de um assunto que até hoje é muito atual. Escrito por Chris Shiflett o livro trata de todos aspectos de segurança relacionados a uma aplicação em PHP, por isso ainda hoje seu conteúdo pode ser considerado atualizado e aplicável a qualquer situação do dia a dia de um desenvolvedor.

O livro possui uma forma muito leve e exemplificada de expor os diversos aspectos de segurança que são tratados. Assuntos estes que são muito bem expostos e claramente separados em capítulos, tratando desde forms até includes e segurança em ambientes compartilhados. Cada tópico é analisado com detalhe e dividido internamente por formas de se burlar/atacar a falha de segurança, com isso o livro se torna também uma fácil fonte de consulta onde é possível se ir direto ao capítulo que trata do aspecto que esta sendo codado e verificar as falhas que se deve prestar atenção. Além disso, o capitulo introdutório também trata do assunto de segurança de uma forma mais geral, como técnicas de análise de risco e conceitos como “Defense in Depth” que ajudam a ver segurança como um processo bem maior que analisar um único ponto de falha da sua aplicação.

Mesmo sendo de 2005 o livro trata de assuntos como XSS que no atual momento da web e seu uso de AJAX deve ser sempre analisado cuidadosamente em novos e antigos projetos. Além disso velhos amigos como “Session Hijacking” e “SQL Injection” são analisados sobre diferentes pontos de vista, alinhados a segmentos específicos de um site. Esta estrutura proporciona uma leitura relaxante e de ritmo agradável que pode ser facilmente encaixada em momentos de descontração ou nas salas de espera das ocasionais idas ao médico (pelomenos funcionou para mim).

O livro merece com certeza fazer parte do histórico (ou prateleira) de qualquer desenvolvedor, pelomenos para servir como ponto de reflexão, mesmo em um novo mundo onde cada vez mais Framework aparecem internalizando todos aspectos de segurança, mas como sempre digo, nos desenvolvedores temos sempre de saber o que ocorre por trás das cortinas.

Essential PHP Security A Guide to Building Secure Web Applications

By Chris Shiflett
October 2005
Pages: 124
ISBN 10: 0-596-00656-X | ISBN 13: 9780596006563

PHP, review, Segurança, shiflett

Está disponível para download a sexta edição da PHP Magazine, esta edição conta com os seguintes tópicos:

# Um gerenciador de Downloads em PHP-GTK
por Pablo Dall’Oglio
Neste artigo iremos desenvolver um pequeno utilitário em PHP-GTK para baixar arquivos remotos. Assim como nos artigos anteriores, nosso objetivo não é desenvolver nenhuma ferramenta profissional, mas mostrar de forma didática como utilizar os recursos do PHP em conjunto com o GTK.

# Upload seguro de arquivos usando FTP verificando vírus
por Helton Eduardo Ritter
Este artigo apresenta uma técnica não usual de fazer upload de arquivos para o servidor. Essa forma não garante, mas auxilia a segurança do servidor. Da maneira proposta, o daemon do apache não precisa ter permissão de gravação em um diretório ou arquivo em uma URL pública para fazer a transferência.

# Mapeamento objeto-relacional usando PHP e MySQL
por Alexsandro Assis
Conceituar e demonstrar o desenvolvimento e uso de classes em PHP para efetuar o mapeamento objeto-relacional, visando padronização, produtividade e portalibilidade entre diferentes bancos de dados. Tornando, dessa forma, o uso de programação orientada a objetos transparente nas tarefas de manutenção de registros em banco de dados.

# Mapas temáticos gerados com PHP
por Raquel Deizério Souto
Neste artigo, por meio de um exemplo prático, demonstraremos como programar em PHP para geração de mapas temáticos. Diversos sistemas de informações geográficas já foram desenvolvidos e oferecem o recurso de geração de mapas temáticos. Entretanto, o tempo gasto na aprendizagem do funcionamento de tais sistemas pode ser economizado quando seguimos os passos simples deste breve tutorial.

# Integrando Ferramentas na construção de um calendário
por Leandro Schwarz
Este artigo introdutório visa abordar todos os passos na criação de um módulo de calendário. O artigo é voltado para o público iniciante, através do desenvolvimento de um calendário simples. Leitores mais experientes poderiam continuar o desenvolvimento para tornar o script um módulo integrado a um sistema de gerenciamento comercial.

Faça do download aqui

PHP, php_magazine, publicações

Depois de muito prometer, finalmente consegui recuperar os arquivos necessários para escrever esta segunda parte do post sobre meu Projeto Final de Graduação.

Postei aqui no blog sobre o meu projeto final d uma vez, descrevendo que eu havia feito e compartilhando o texto da monografia que em grande parte explica o sistema inteiro e como fazer, além dos slides que utilizei na apresentação do mesmo. 

Porém na epoca não possuia em mãos algo que depois me foi extremamente pedido por muitos leitores e alunos interessados, o código fonte do site. Estes arquivos tinham ficado perdido em um velho HD e somente agora consegui localizar o HD e recuperar estes arquivos. Portanto estou finalmente compartilhando estes arquivos para que possam usar de base para os estudos e extensões do projeto.

ESte código na verdade é uma prova de conceito apenas, portanto algumas coisas estão manuais e não bem acabadas, e claro o código é de 2005~6 portanto é capaz de não ser nem compatível com o PHP5. Mas ele funcionou e acredito que com o ambiente correto ainda deve funcionar.

A licença deles é a mesma do resto do material, CC, usem a vontade, mas lembrem de me dar o credito no material e de que isto nao pode ser usado para fins comerciais sem minha permissão.

O pacote é exatamente o que eu tinha rodando no dia da apresentação, ele tem todos arquivos como o banco de dados e tudo mais, além disso se vc estiver em uma maquina Linux ele possui um script de reset. Como usei isso para apresentação eu precisava em diversos momentos voltar a um ponto inicial com tudo certinho, esse reset deixava o site limpo e enviava sinais de reset para o circuito que também voltava a um ponto zerado.

Ele volta com o cadastro apenas de uma casa com planta baixa, voce pode adicionar uma sala e uma imagem de exemplo esta no diretorio temp “amb_1″

Então seguem os arquivos, baixe o código fonte aqui: Código Fonte – Projeto Final de Graduação.

automação, Carreira, PHP, projeto final