Testando rapidamente projetos PHP, ou com Vagrant, ou com Docker ou com Servidor Web embutido

Olá, pessoal!

Dica rápida para quem quiser testar algum projeto PHP usando o Vagrant, ou o Docker, ou o Servidor Web embutido no PHP.

Vagrant

Já conhece o https://phpagrant.github.io/ ? Nada mais é do que uma lista de sites geradores de Vagrantfile (e tudo o mais que você precisa de provisionadores) para seu projeto PHP com base no Vagrant.

Phpagrant_github_io_by_PHPagrant

Tem para todos os gostos: Puppet, Chef, Ansible. Você escolhe! Acesse lá, https://phpagrant.github.io/!

Docker

O novo “queridinho” do mundo da virtualização e conteinerização, o Docker, está evoluindo rápido e é importante você correr atrás do prejuízo e aprender sobre ele.

Docker_-_Build__Ship__and_Run_Any_App__Anywhere

Até a versão 1.2.x tinha um sério problema para os usuários de sistemas não Linux: o Boot2Docker, camada VM para permitir que usuários de OS X e Windows usem o Docker, não permitia usar pastas compartilhadas por padrão. Alguns hacks foram lançados (como o ótimo artigo do Chris Jones) , mas depois do lançamento da versão 1.3.0, tudo ficou mais fácil: foi embutido suporte para pastas compartilhadas e está mais simples para quem não usa Linux como máquina principal de desenvolvimento ter o Docker como parte do seu processo de trabalho.

Mas e sobre o PHP? Vamos lá! Algumas imagens disponíveis no https://registry.hub.docker.com/ para você se divertir:

  • oficialhttps://registry.hub.docker.com/_/php/ (falta FPM, mas já tem CLI e Apache com mod_php)

  • @brunoric: https://hub.docker.com/u/brunoric/ (brasileiro, aqui de São Paulo, especialista no Docker. Tem uma série de imagens PHP, vários sabores, até HHVM)

Além disso, seguindo a issue https://github.com/codeguy/php-the-right-way/pull/453, dá para ver que em pouco tempo o PHP: The Right Way (e o PHP: Do Jeito Certo) terá conteúdo sobre Docker e PHP (hoje eles já tem conteúdo sobre Vagrant).

Para quem quer ir direto colocar a mão na massa, o que estou fazendo:

  • Primeiro instalei o Docker (e, como estou num OS X, o Boot2Docker também. Comando para garantir que ele está ligado: boot2docker up)

  • [OS X apenas:] coloquei no meu ‘/etc/hosts’ o hostname ‘localdocker’ apontando para o IP 192.168.59.103 (esse ip é o que comando boot2docker ip mostra). Isso só é necessário para quem usa boot2docker, pois o Docker de verdade está rodando dentro de uma VM, com esse IP aí de cima. Quem está rodando no Windows deve ser algo parecido. Quem está rodando no Linux, não tem que se preocupar com isso, pois o Docker está usando o IP da sua máquina de verdade.

- Vou na pasta que seria o document root da minha aplicação (onde tem o front controller, geralmente index.php) . Como estou no OS X, essa pasta tem que estar dentro de /Users para usar o compartilhamento de pasta automático do boot2docker 1.3+. Ex:

$ cd /Users/eu/projetos/php123/

  • De lá, rodo o seguinte comando:

$ docker run --name my-php-webserver -p 8080:80 -v `pwd`:/var/www/html/ php:apache

O que aconteceu por trás do comando DOCKER RUN:

  • cria e já executa um container, baseado na imagem php versão apache

  • habilita o volume/disco internamente (dentro do container) como /var/www/html/ e externamente (na máquina host/vm boot2docker) como o resultado comando pwd (diretório atual)

  • redireciona a porta 80 interna (no container) para a porta 8080 externa (na máquina host)

É isso!

Quando precisar desligar o container, fazer os seguintes comandos:

  • $ docker ps -a (e copiar o CONTAINER ID)

  • $ docker rm CONTAINER_ID_QUE_VOCÊ_ACHOU_NO_COMANDO_ANTERIOR

Servidor embutido

Vai ter momentos que você não quer ou não pode ir para um dos modelos acima, Vagrant ou Docker. E nem quer instalar um servidor web completo (Apache, Nginx etc.) na sua máquina de desenvolvimento. O que fazer?

Se você tem o PHP CLI já instalado, é bom saber que desde a versão 5.4 é possível usar o servidor web embutido. Leia mais na documentação oficial.

PHP__Built-in_web_server_-_Manual

Então, na pasta onde seria o document root da sua aplicação PHP (onde ter o front controller, certo?), digite o seguinte comando:

$ php -S localhost:8899

A porta ali, no caso 8899, poderia ser qualquer uma de sua preferência. E você já tem um servidor web rodando servindo seu código PHP, no seu navegador disponível em http://localhost:8899. Fácil, não? Você ainda pode configurar algo como um .htaccess, a Lorna Jane Mitchell tem um artigo de 2012 falando do assunto. Mas, de novo, leia a doc oficial que você tem muita informação lá.

Considerações finais

Hoje você não é mais obrigado a instalar um servidor web como o Apache ou o Nginx apenas para testar uma aplicação PHP básica. O Servidor web embutido, desde o PHP 5.4 (março de 2012), fornece a estrutura básica para que, em desenvolvimento, você tenha um servidor mínimo.

Caso você precise espelhar o servidor de produção (hardware, sistema operacional e softwares utilizados), vá para o Vagrant, que te entrega isso de forma fácil com a virtualização, tanto para projetos genéricos quanto para projetos PHP.

E, se quiser estar na crista do onda, aplicando conteinerização também no ambiente de desenvolvimento, teste o Docker com PHP.

E fique a vontade de usar os comentários se quiser ajuda!

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Pra não dizer que não falei de Vagrant

Esse post é uma republicação do artigo no site do PHPSP (http://phpsp.org.br/index.php/pra-nao-dizer-que-nao-falei-de-vagrant/).

Olá, pessoal.

Vagrant logo

Vamos falar um pouco dessa ferramenta super útil que promete (e cumpre) ser a revolução para ambientes de desenvolvimento virtualizados, o Vagrant! Mas antes de falar da ferramenta em si, é importante começar com o seguinte: como é hoje o seu ambiente de desenvolvimento?

Evolução do ambiente de desenvolvimento

Vou contar um pouco da evolução do meu ambiente de desenvolvimento, talvez faça você recordar de algo que provavelmente já ocorreu com você:

- Sem noção, altero tudo em produção

- Separação do ambiente, instalo tudo na minha máquina

- Minha máquina vira uma carroça, e tudo dá conflito

- Leio o texto do Anderson (Duodraco) Casimiro, aprendo que é uma boa virtualizar o ambiente de desenvolvimento dentro de uma máquina virtual, que posso ligar e desligar a qualquer momento

- Virtualização dá trabalho!

Virtualização, promessa

A VM permite deixar os ambientes:

- leves

- reproduzíveis

- portatéis

Virtualização, os 3 pilares

- Hardware

- Sistema operacional

- Softwares

Automatizando os 3 pilares da Virtualização, aqui que entra o Vagrant

Vagrantfile: é a cola

Boxes: são VMs base, que já tem o Hardware e o Sistema Operacional definidos

Provisionamento: são os scripts que automatizam a instalação e configuração dos Softwares

Como começar

- Leia o artigo do Duodraco, http://duodra.co/2012/02/18/desenvolvimento-php-usando-maquinas-virtuais-fastcgi-fpm/, e fique bravo se não funcionar com você (é o que aconteceu comigo ;-) )

- Baixa o instalador do Vagrant e leia a documentação no site oficial, http://www.vagrantup.com/ (existe um trabalho para traduzir a documentação para português, se quiser dê uma olhada em http://friendsofvagrant.github.io/, contribuições são bem-vindas)

- Conheça as Boxes oficiais e as criadas pelas comunidade em http://www.vagrantbox.es/, várias diferentes distribuições de Linux

- Comece com módulos e cookbooks para provisionamento prontos e ajuste para o que precisa (o Vagrant suporta muitos mais, no entanto o Puppet (https://forge.puppetlabs.com/) e o Chef são os mais conhecidos (http://community.opscode.com/)

- Importante!!!: Procure aprender mais sobre Gerência de Configuração e Provisionamento, vão ser uma mão na roda para você

Aprofunde-se

Depois que você tiver passado por esses passos, já entender o mínimo do conceito e tiver colocado pelo menos um pouquinho a mão na massa, aí compensa você ir para coisas mais avançadas, seguindo a própria documentação do Vagrant e o monte de informação disponível na web (minha dica, procure pelos plugins para Vagrant https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins).

Me ajude mais!!!

E para facilitar bastante o seu desenvolvimento, duas ferramentas que já criam o esqueleto completo para você: Vagrantfile + Box + Provisionamento! São o mundo perfeito para realmente começar um projeto do zero sem ter quase nenhum trabalho nesse nível:

http://rove.io/, dica do Elton Minetto, cria tudo para você baseado no provisionador Chef. Bom para projetos Ruby ou PHP/LAMP

https://puphpet.com/ , cria tudo para você, com muito mais opções de configuração, baseado no provisionador Puppet. Muito bom para projetos PHP, tanto sobre Apache como sobre Nginx.

Puphpet logo
Logo do Puphpet

É isso aí pessoal, material não falta, não é mesmo?!?!

Já tivemos até o primeiro evento de Vagrant no Brasil, fiquem atentos para os próximos.

Se quiser aproveitar para ajudar em um projeto que tem tudo a ver com o tema, e é feito em PHP, deêm uma olhada no Github do projeto Puphpet, vocês vão ajudar muita gente com isso, e se envolver em um projeto Open Source é sempre bacana.

Bom divertimento, e qualquer coisa, me procurem, estou em todo lugar como rogeriopradoj!

Como usar o Vagrant.has_plugin? no Vagrantfile

Olá, pessoal!

Esse artigo é uma continuação do Vagrant e seus plugins, de outubro de 2013, e, para falar a verdade, começou a ser escrito antes do original. É que percebi que, sem uma explicação mais básica do que eram os plugins, ia “faltar base” – como dizia um professor do cursinho!. Então, mais uma vez, se quiser primeiro saber o que são os plugins no Vagrant, leia o artigo original primeiro, ok?

vagrant-has-plugin

O que é o método Vagrant.has_plugin?

O has_plugin? é um método da API do Vagrant, para ser usado no seu Vagrantfile, que verifica se um plugin está disponível no sistema. Com o grande número de plugins disponíveis (confira os listados na wiki oficial), é importante ter uma forma de garantir que quem for usar seu projeto Vagrant tenha os plugins que você definiu/utilizou, e, se não tiver, fazer algo com essa informação.

Vamos ver um exemplo para deixar mais fácil o entendimento:

Nesse trecho acima vemos um Vagrantfile que utiliza o plugin vagrant-cachier para acelerar o vagrant up se o usuário tem o plugin instalado na máquina, e, caso não tenha, tudo continua funcionando, apenas sem a aceleração. Sem usar o has_plugin? o Vagrant interromperia o processo com uma mensagem de erro.

Parece bastante com o conceito de progressive enhancement/graceful degradation: forneça ao usuário que tem apenas o requisito básico uma versão funcional do seu projeto, sem traumas. E, para os que tem mais requisitos (no caso o plugin que definimos), entregue também as funções melhoradas (nesse caso, uma camada de cache que vai acelerar o provisionamento das máquinas virtuais. Se você ainda não conhece o vagrant-cachier, do brasileiro Fabio Rehm, ou @fgrehm, é uma boa hora de começar!).

Um outro exemplo segue abaixo:

Nesse caso, ao contrário do anterior, é feita uma ação quando um plugin não existe no sistema. E quando que isso é útil? Principalmente para os casos que onde precisamos avisar para o usuário que um plugin é necessário/recomendável para executar a aplicação, dando algum caminho para que ele possa resolver a situação. No exemplo acima, avisamos que o projeto está usando o plugin vagrant-bindler para fazer a gestão dos plugins e passamos um caminho para que o usuário faça a instalação do mesmo se ele ainda não tiver (plugin também criado pelo @fgrehm).

Há tempos… um problema!

A função Vagrant.has_plugin? foi introduzida no Vagrant na versão 1.3.0, com alguns problemas, e na versão 1.3.2 foi realmente consertada, isso tudo em setembro de 2013. Mas por que então, mesmo tendo uma certa idade, essa função ainda não é tão utilizada?

Isso acontece por uma pequena inconsistência na implementação dessa API, que faz com que o nome do plugin internamente para o Vagrant (que vai ser usada na chamada Vagrant.has_plugin?) seja diferente do nome do plugin que é usado na instalação via linha de comando $ vagrant plugin install ....

Antes de perceber isso acima, eu mesmo no começo não conseguia entender a lógica, que parecia ser tão simples: fazer uma condição ruby IF ou UNLESS, passando o nome do plugin. Por que não funcionava? Era essa bendita inconsistência de nomes. Ainda bem que não desisti de entender!

Para facilitar, vamos chamar esses nomes da seguinte forma:

  • nome de instalação do plugin: usado no comando $ vagrant plugin install ....
  • nome interno do plugin: usado no Vagrantfile, com o método has_plugin?

Com isso em mente, vamos para os  exemplos:

Quando acessamos a lista oficial dos plugins disponíveis para Vagrant lá não encontramos o nome interno (ainda, estou trabalhando nisso :-) ); apenas aparece o nome de instalação. Uma diferença que, às vezes, é apenas de maíusculas ou minúsculas entre os nomes das duas versões mas que já atrapalha tudo!

Peguemos o Bindler. Para instalá-lo no sistema, é usado o nome da Gem (em minúsculas):

$ vagrant plugin install bindler

Já para usar no seu Vagrantfile, com o has_plugin?, tem que ser o nome interno do plugin (começando com maíscula):

Vagrant.has_plugin?("Bindler")

É, realmente é complicado. Por não haver um padrão, é possível encontrar todos os tipos de combinações: nomes iguais, totalmente diferentes ou apenas a diferença de capitulares. Mas existe uma solução! Vamos vê-la?

A solução!

E a solução é: aprender a ler o repositório do plugin! Puxa, não é o que você estava esperando, não é mesmo… É, por enquanto (dezembro de 2013), não existe uma solução perfeita, por isso vamos aprender aqui a ler o repositório sempre que você precisar.

Arquivos importantes

O primeiro passo é saber localizar, dentro de um repositório, o nome de instalação do plugin e o nome interno do plugin:

  • /nome-de-instalação-do-plugin.gemspec: é nesse arquivo que temos o nome de instalação. O arquivo fica na pasta raiz do repositório do plugin. Exemplos: bindler.gemspec, vagrant-aws.gemspec, vagrant-cachier.gemspec etc.
  • /lib/nome-de-instalação-do-plugin/plugin.rb: é nesse arquivo que temos o nome interno. O arquivo fica no terceiro nível do repositório do plugin. Dentro desse arquivo, existe um atributo name, que é o nome interno que você vai usar. Exemplos para os mesmos plugins acima: BindlerAWSvagrant-cachier.

Achar o repositório do plugin

O segundo passo é saber onde está o repositório do plugin. Minha sugestão, comece pela lista oficial, e siga o link de lá. Na maioria das vezes, você vai cair num repositório no GitHub (ou em algum outro serviço de hospedagem de projetos open source).

A partir daí é só navegar buscando os arquivos mostrados ali em cima, que você já terá a informação necessária para trabalhar.

Considerações finais

Vimos que o Vagrant.has_plugin? é um método da API do Vagrant muito útil para utilizar nos seus projetos. Principalmente importante para os projetos compartilhados com muitas pessoas, verificando em tempo de execução a existência ou não de um plugin determinado, permitindo que quem tenha o plugin aproveite as funcionalidades, mas não impedindo que os usuários sem o plugin tenham uma experiência pelo menos básica.

Entendemos também que existem dois nomes para os plugins: o nome de instalação e o nome interno, e qual deles deve ser usado junto com o Vagrant.has_plugin?. Aprendemos quando usar cada um deles, e como descobrir o nome lendo o repositório do plugin (fique de olho na wiki da lista oficial de plugins, pois vou fazer um trabalho visando facilitar a pesquisa centralizada desses nomes, seria interessante, certo?).

Quer uma dica de plugins para começar a trabalhar? Dê uma olhada no meu artigo original, Vagrant e seus plugins, que tem algumas opções que já utilizo. Agora é sua vez de montar uma estratégia de uso dos plugins e do has_plugin? nos seus projetos Vagrant e

Fique à vontade para tirar suas dúvidas nos comentários (ou me procure, estou em quase todo lugar na internet como rogeriopradoj, é só chamar!)

Feliz vagrant up!

Referências:

[1] https://github.com/fgrehm/bindler/issues/22

[2] https://gist.github.com/rogeriopradoj/6954261

[3] https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins

 

Vagrant e seus plugins

E lá vamos nós falar de Vagrant!

vagrant-e-seus-plugins

Resumo da história dos plugins no Vagrant

Os plugins viraram cidadões de primeira classe na API v2 do Vagrant (antes eles até eram suportados com um pouco de mágica e um monte de requires no meio do seu Vagrantfile). Agora, como o Mitchell Hashimoto diz, o próprio Vagrant usa a API de plugins interna para boa parte de suas implementações, por isso, é possível ficar mais tranquilo de que as coisas funcionarão e que a interface é estável e bem suportada.

Não tenho nenhum plugin ainda desenvolvido, mas já utilizo vários para facilitar meu trabalho com o Vagrant. Então, vamos conhecer um pouco mais?

Como instalar plugins no Vagrant

A documentação do Vagrant sobre plugins está bem completa nesse ponto, e é bem fácil: nada mais do que rodar: $ vagrant plugin install NOME-DO-PLUGIN.

Exemplo para instalar o vagrant-aws:

$ vagrant plugin install vagrant-aws.

Os plugins são na maioria mantidos pela comunidade, e por isso não existe uma listagem oficial. No entanto, existe uma página na wiki do projeto com os plugins marcados pelos usuários, sugiro que visite para buscar os que sirvam para o seu caso de uso.

Quer uma dica de alguns para começar? Veja abaixo:

Plugins Vagrant que não podem faltar para mim

Bindler

Para quem conhece o Composer no mundo PHP, o Bundler no mundo Ruby ou o Bower no mundo FrontEnd, é fácil entender o que esse plugin faz e também a vantagem de usá-lo, o Bindler.

Ele permite que você crie um arquivo na raiz do seu projeto Vagrant (na mesma pasta onde você coloca o seu Vagrantfile) para distribuição, deixando claro para seus usuários que plugins são as suas dependências.

Quando alguém for usar o seu projeto, executará $ vagrant plugin bundle antes do $ vagrant up, e o Bindler se encarregará de instalar as dependências que faltarem. Se o usuário já tiver os plugins instalado globalmente, estes serão usados, senão, o Bindler instalará o que faltar localmente para o projeto apenas. E quando o usuário fizer o $ vagrant destroy tudo voltará ao que era antes.

Vagrant Cachier

O Cachier é aquele cara que faz você se perguntar: como conseguiu viver sem ele até agora! Ele faz o cache dos pacotes Apt que você instala na suas distribuições Debian-like (Ubuntu inclusive) entre todas os projetos que você tiver baseado em uma box.

Assim, ele acelera (e muito!!!) a instalação das suas dependências, pois, se um pacote já tiver sido baixado naquela versão específica em um outro projeto, será usado o cache em vez de ir até o repositório oficial do Ubuntu, por exemplo.

Vagrant HostManager

Vai chegar o momento em que apenas definir um IP na opção :private_network do Vagrantfile, ou mesmo a redirecionamento de porta via :forwarded_port, não será mais suficiente para testar seu projeto (por diversos motivos isso pode acontecer. Acredite, quando você chegar nesse nível você vai lembrar das minhas palavras ;-) ).

Nesse momento você vai procurar uma forma de configurar o seu arquivo HOSTS, /etc/hosts (nos sistemas *nix) ou %windir%\system32\drivers\etc\hosts (no Windows), para que endereço do seu Vhost do Apache fique disponível tanto internamente nas máquinas (Guests) quanto a partir do seu sistema principal (Host). Qual é o caminho normal para fazer isso? Sim, editar manualmente seu arquivo HOST em um monte de lugares.

Aí que entra o plugin HostManager: com base numa pequena configuração do seu Vagrantfile ele já configura tudo isso para você. Existem alguns outros que fazem o serviço de forma parecida, mas foi com ele que me adaptei mais.

Considerações finais

Os plugins foram uma inclusão importante no ecossistema do Vagrant, e como viram, não é difícil de usar os que já estão disponíveis. Esse artigo está longe de te dar o caminho completo para usar as ferramentas, mas já te inicia e mostra onde você pode conseguir mais informações. Procure conhecer e testar o máximo que você conseguir pois assim vai ser fácil de tomar a decisão de usar ou não um deles em seus futuros projetos.

E fique a vontade de usar os comentários se quiser ajuda!

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Build e Integração Contínua no PHP com Composer, Phing, Travis-CI e Scrutinizer-CI

Olá, pessoal,

Há tempos que não fazia uma limpeza no meu Github, seja para excluir projetos que não fazem mais sentido, forks que não ia mais utilizar, ou mesmo para atualizar algum repositório e me lembrar de tudo que venho estudando desde que conheci o Github (segundo o site dos caras, outubro de 2010).

  

E foi no meio dessa limpeza (na verdade bem no começo mesmo :-) ) que achei o https://github.com/rogeriopradoj/ManoWars, fork de um projeto criado pelo Rafael Dohms e pelo Augusto Pascutti há muito tempo para ensinar sobre Testes Unitários e Integração Contínua.

Foi aí que pensei: porque não dar uma relembrada no assunto, e também atualizar com coisas que tenha aprendido nesse período (poxa, são quase 3 anos!)?

Phing???

Logo Phing

Muita coisa ainda não havia tocado, caso do Phing, que o Hussani e o Duodraco já haviam apresentado mais de uma vez em palestras. Também não estava muito habituado com as ferramentas para geração de relatórios de métricas, como o PHPMD, ou o PDepend.

Mas aí estava a graça, um bom desafio! E com a ótima estrutura que o Dohms e o Pascutti haviam deixado, não foi tão difícil começar.

Composer

Composer logo

A primeira coisa que fiz foi usar o Composer para gerenciar as dependências do projeto.

Aqui uma decisão tinha que ser tomada: o projeto foi todo baseado em PHP 5.2+, e eu poderia continuar deixando essa versão como a mínima necessária. Só que muitas das ferramentas de métricas e o próprio PHPUnit que hoje está disponível via Composer é apenas 5.3+. Então decidi subir para 5.3 a dependência mínima.

Como o Composer além de gerenciar as dependências também gera um autoloader completo (tanto com o código do meu projeto quanto das dependências), pude retirar sem dó o Zend/Loader que estava no projeto, pois ele não era mais necessário.

E com um mágico $ composer install estava lá: todas as dependências na pasta vendor, um autoloader funcional completo, e o melhor, todas as ferramentas binárias (PHPUnit, PHPPdepend etc., e o próprio Phing) já disponíveis também na pasta vendor/bin.

É, o Composer é uma mão na roda!

E lógico, com o PHP 5.4+ com servidor web embutido, foi brincadeira de criança subir testar a aplicação rodando no navegador, só com um $ php -S localhost:8080 -t public.

Estrututura de pastas e arquivos

Como o Composer coloca todas as dependências dentro da pasta vendor na raiz, e é meio que padrão os projetos PHP que vejo deixarem uma estrutura baseada na raiz também, mudei um pouquinho as pastas de lugar. A maior mudança foi colocar as pastas que estavam dentro de ManoWars na raiz, assim a hierarquia ficou um pouco menor.

  • /libs: contém o código da aplicação
  • /public: o document root do servidor web
  • /tests: testes unitários
  • init.php: bootstrap da aplicação (usado tanto na aplicação web quanto nos testes)

phpunit.xml.dist

Já havia lido sobre a vantagem de usar o phpunit.xml.dist no artigo [Best practice] How to ship PHPUnit configuration do test.ical.ly, e até já mandei um Pull Request para o Ophportunidades sobre isso.

Então foi um passo para criar um arquivo de configuração para o PHPUnit, já desde o começo um .dist.

Vantagem: agora para rodar o phpunit não é preciso entrar na pasta tests, é só rodar a partir da raiz. Outro ponto, não é mais necessário o arquivo AllTests.php, pois a definição da suíte de testes é feita também nesse arquivo de configuração.

PHP CodeSniffer

Uma task do Phing que não estava sendo executada era a de verificação do padrão de codificação, com o phpcs. Pensei em colocar o padrão PSR2 logo de cara, mas como o projeto foi feito a muito tempo, muitos erros iriam aparecer. Preferi deixar com o padrão Zend que foi provavelmente o que o Dohms e o Pascutti usaram.

Na minha lista de tarefas está evoluir o padrão para PSR2.

Outras ferramentas

Todas as ferramentas que estão sendo usadas para métricas, testes e build estão no composer.json, dê uma olhada lá, ok?

README

E no LEIAME do projeto a principal mudança foi trocar o formato para Markdown (na verdade o GFM) que é uma beleza para escrever e o Github já faz a renderização muito bem para HTML.

Ferramentas de Integração Contínua Online (Travis e Scrutinizer)

Depois de todos os pequenos ajustes, era hora de mexer de verdade no projeto.

A primeira coisa que percebi é que tinham poucos testes falhando. Tinha a ver com a API do PHPUnit ter mudado, e com um teste que esperava nulo, mas na verdade o método retornava um inteiro. Fiz o ajuste nos testes e eles passaram a funcionar.

Agora era hora de resolver todos os outros problemas do código: padrão de codificação, aumentar cobertura de testes, complexidade, etc. etc., tudo relacionado a QA/Garantia de Qualidade. Também analisar os relatórios gerados, uma parte interessante que nunca tinha olhado mais de perto.

Mas por que não ser um pouco poser e colocar um monte de badges no projeto? Esses badges seriam para mostrar a evolução do projeto, e fui atrás das ferramentas online que me permitiriam isso

Travis

Logo do Travis

Comecei pela mais conhecida, o Travis-CI, que já tinha usado em outros projetos. Nele começei colocando o PHPUnit para rodar, nas 3 últimas grandes versões do PHP, 5.3, 5.4 e 5.5.

O Travis conta um conceito interessante de matriz de build, onde você cruza algumas configurações e o build é feito em todas as combinações dela. Isso me ajudou no passo seguinte.  O Travis já tem um executável do PHPUnit disponível para usarmos, mas eu gostaria de rodar o PHPUnit instalado pelo Composer também. Fácil: criei uma variável de ambiente RUN, que no primeiro momento era definida como phpunit, e no segundo momento como vendor/bin/phpunit. E o Travis se encarregou de rodar os builds 6 vezes (3 versões do PHP x 2 PHPUnit diferentes).

No fim, coloquei mais uma definição para a variável de ambiente RUN como vendor/bin/phing, e o Phing inteiro foi rodado lá no Travis, muito bacana!

Scrutinizer

Logo do scrutinizer

Só um problema: o Travis sozinho não avalia os relatórios gerados. Foi aí que peguei o Scrutinizer-CI, que já havia também usado anteriormente, mas quando o Alexandre Eher lembrou dele no PHPSPub de Agosto, vi que era uma boa ideia usá-lo de verdade.

Depois de bater um pouco de cabeça, consegui fazer a maioria das métricas serem executadas, e no fim, o que mais queria: os badges!!!

Travis
Scrutinizer – Quality
Scrutinizer – Coverage

E para renderizar o README um pouco melhor, e lógico que usando outra ferramenta online, fui de DocumentUp.

É isso aí, pessoal, escrevi bastante e tem bastante coisa para fazer ainda.

Se quiser acompanhar, lá no https://github.com/rogeriopradoj/ManoWars.

Até mais!

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

E o site do PHPSP voltou!

Olá, pessoal,

Voltar aqui para dizer que o site do PHPSP, http://www.phpsp.org.br, voltou ao ar e cheio de conteúdo!

O processo começou em março no Hackathon PHPSP que ocorreu no iMasters, e durante esses meses veio sendo feito a passos largos (mudança de hospedagem, criação do tema, novos colaboradores, etc etc.).

E na reunião de 08/08/2013 do grupo foram fechadas uma série de novidades!

Eventos, encontros, artigos novos, tudo beleza!

Tem até um artigo meu lá, http://phpsp.org.br/index.php/pra-nao-dizer-que-nao-falei-de-vagrant/, Pra não dizer que não falei de Vagrant.

É isso aí, como diz o Duodraco, We rock!!!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

CodeIgniter Skeleton para uso com Composer no Packagist

Olá, pessoal!

Alguém aí usando CodeIgniter e quer facilitar o gerenciamento das suas dependências usando o Composer?

Então vai aí uma dica de pacote no Packagist:

Packagist

https://packagist.org/packages/rogeriopradoj/codeigniter-skeleton

Se você já tem o Composer instalado, é só rodar:

$ composer create-project rogeriopradoj/codeigniter-skeleton /pasta/para/seu/projeto

E se não tem o Composer instalado, está esperando o quê?!?!?! Siga a documentação oficial, e instale agora!

É isso aí, pessoal, até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Plugin PHP Coding Standards Fixer (php-cs-fixer) para o PHP-Build

Olá, pessoal!

Depois do plugin do Composer para quem usa o php-build do CHH (já tinha falado dele aqui e aqui), consegui lançar mais um plugin: o Plugin do PHP Coding Standards Fixer (php-cs-fixer). Primeiro vamos contar a história do php-cs-fixer:

Logo do php-cs-fixer
Logo do php-cs-fixer

Criado pelo Fabien Potencier, chefe da Sensio Labs, o php-cs-fixer é uma ferramenta que corrige automaticamente um código fonte para seguir os padrões da PSR2. Ele foi criado com foco na correção automática do código do framework Symfony, do qual é o Fabien é mantenedor; e hoje a ferramenta está liberada com código aberto para a comunidade PHP.

Composer?

Sempre que possível, gosto de utilizar o Composer nos projetos para gerenciar minhas dependências. O php-cs-fixer está listado no Packagist, e pode ser instalado por lá, mas o que fazer nos casos que não vai usar o composer? Aí foi procurar qual a melhor forma de fazer isso: deixar a ferramenta instalada globalmente junto do meu PHP.

No próprio site oficial do php-cs-fixer eles sugerem que a forma de instalação é usando o arquivo PHAR que eles disponibilizam para download, e foi em cima desse arquivo PHAR que o plugin para o php-build foi desenvolvido.

Plugin

O que o php-build faz é o seguinte:

  • logo depois de compilar a versão sua do PHP, ele abre o plugin como um after_install
  • o plugin baixa o php-cs-fixer.phar mais recente
  • esse arquivo é renomeado para php-cs-fixer
  • ele é colocado numa pasta acessível ao PATH definido pelo php-build/phpenv nessa versão que você acabou de compilar
  • e no fim, é dada permissão de execução nesse script php-cs-fixer

Pronto! Agora, sempre que precisar rodar a ferramenta é só executar $ php-cs-fixer com os parâmetros desejados.

Considerações

Para facilitar:

– Github: https://github.com/rogeriopradoj/php-build-plugin-phpcsfixer

– DocumentUp: http://documentup.com/rogeriopradoj/php-build-plugin-phpcsfixer

Fiquem à vontade para tirar dúvidas e dizer o que acharam.

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Python e Virtualenv no Mac OS X Mountain Lion 10.8

Este artigo é uma tradução livre de Python and Virtualenv on Mac OS X Mountain Lion 10.8, do Justin Mayer, disponível em http://hackercodex.com/guide/python-virtualenv-on-mac-osx-mountain-lion-10.8/.

A instalação do Python e do Virtualenv no Mac OS X 10.8 Mountain Lion pode ser feita de muitas formas. Embora não exista uma configuração perfeita, esse tutorial te guiará no processo de configuração de uma instalação padrão do Mountain Lion num ótimo sistema para desenvolvimento Python.

Primeiros passos

Esse guia pressupõe que você já tenha instalado o Xcode e o Homebrew. Para detalhes, siga os passos do Mountain Lion Configuration Guide.

Python

Vamos instalar a última versão 2.7.x do Python pelo Homebrew. Para que fazer isso, você pode perguntar, quando a Apple já inclui o Python no Mountain Lion? Aqui temos algumas razões:

  • O Homebrew sempre fornece a versão mais recente (hoje 2.7.4). A versão embutida no OS X está parada no 2.7.2.
  • A Apple fez mudanças significativas no Python embutido, o que pode resultar em bugs escondidos.
  • O Python do Homebrew inclui as últimas ferramentas para gerenciamento de pacotes: o pip e o Distribute.

Seguindo pelo mesmo caminho, a versão do OpenSSL no Mountain Lion, a 0.9.8) é de fevereiro de 2011, por isso estamos dizendo ao Homebrew para baixar o OpenSSL mais recente e compilar o Python com ele.

Use o comando a seguir para instalar o Python via Homebrew:

Você já deve ter alterado seu PATH como mencionado no artigo acima, certo? Caso contrário, faça isso agora.

Também podemos instalar o Python 3.x junto com o Python 2.x:

… o que facilita para testar seu código tanto no Python 2.x quanto no Python 3.x.

Pip

Digamos que você quer instalar um pacote Python, como a fantástica ferramenta para isolamento de ambientes virtualenv. Quase todo artigo para Mac OS X relacionado ao  Python diz para o leitor instalá-lo assim:

Aqui estão os motivos porque eu não faço dessa forma:

  1. instalação com permissão root
  2. instalação é feita na sistema em /Library
  3. instalação é feita pelo obsoleto easy_install em vez de usar as ferramentas mais modernas como o pip ou o Distribute
  4. o uso das ferramentas fornecidas pelo Homebrew leva a um ambiente mais confiável

 

Como você deve ter percebido, estamos usando as ferramentas fornecidas pelo Homebrew para instalar os pacotes que você quiser que estão disponíveis globalmente. Quando fizer instalações usando o pip do Python do Homebrew, os pacotes serão postos em /usr/local/lib/python2.7/site-packages, com os binários sendo colocados em /usr/local/share/python.

Controle de versão (opcional)

A primeira coisa que eu instalo pelo pip é o Mercurial. Uma vez que eu tenho repositórios Mercurial para empurrar tanto para o Bitbucket quanto para o Github, eu instalo o Mercurial e o hg-git em todos meus sistemas:

Pelo menos, você terá que adicionar umas poucas linhas no seu arquivo .hgrc para utilizar o Mercurial:

As linhas a seguir devem te permitir começar; apenas garanta que tenha alterado os valores para seu nome e endereço e-mail respectivamente.

Para testar seu o Mercurial foi configurado e está pronto para ser usado, execute o comando a seguir:

Se a última linha da saída for “No problem detected”, então o Mercurial foi instalado e configurado adequadamente.

Virtualenv

Os pacotes Python instalados pelos passos acima são globais no sentido que eles ficam disponíveis em todos os seus projetos. Isso pode ser conveniente algumas vezes, mas também pode criar problemas. Por exemplo, as vezes um projeto precisa da última versão do Django, enquanto outro precisa do Django 1.3 para manter a compatibilidade com uma extensão crítica de terceiros. Esse é um dos muitos casos de uso que o virtualenv foi criado para solucionar. Nos meus sistemas, apenas um punhado de pacotes Python de uso geral (como o Mercurial e o próprio virtualenv) ficam disponíveis globalmente – qualquer outro pacote fica confinado em um ambiente virtual.

Com essa explicação, vamos instalar o virtualenv:

Crie alguns diretórios para armazenar seus projetos e os ambientes virtuais, respectivamente:

Depois vamos abrir o arquivo ~/.bashrc…

… e adicionar algumas linhas nele:

Vamos recarregar nosso ambiente bash:

Agora nós temos o virtualenv instalado e pronto para criar novos ambientes virtuais, que serão armazenados em ~/Virtualenvs. Novos ambientes virtuais podem ser criados assim:

Se você tiver tanto o Python 2.x quanto o 3.x e quiser criar um virtualenv do Python 3.x:

… o que facilita a troca entre os ambientes foobar do Python 2.x com o do Python 3.x.

Restringindo o pip aos ambientes virtuais

O que acontece se pensarmos que estamos trabalhando em uma ambiente virtual ativo, mas na verdade não existir nenhum ambiente virtual ativo e instalarmos algo via pip install foobar? Bem, nesse caso o pacote foobar é instalado no nosso site-packages global, estragando o propósito do isolamento do nosso ambiente virtual.

Na tentativa de evitar instalar por engano via pip um pacote específico de um projeto no meu site-packages global, anteriormente eu usava o easy_install para pacotes globais e o pip embutido no virtualevn para instalar pacotes dentro dos ambientes virtuais. Isso atingia o objetivo do isolamento, uma vez que o pip estava disponível apenas dentro dos ambientes virtuais, tornando impossível para mim rodar pip install foobar por engano no meu site-packages global. No entanto o easy_install tem algumas deficiências, como a impossibilidade de desinstalar um pacote, e me vi querendo usar o pip tanto para pacotes globais quanto nos virtualenvs.

Felizmente, o pip tem um configuração com documentação escassa que diz para ele falhar se não existir uma ambiente virtual ativo, que é exatamente o que eu quero. Na verdade, nós já fizemos essa configuração acima, pela diretiva PIP_REQUIRE_VIRTUALENV=true. Por exemplo, vamos ver o que acontece quando tentamos instalar um pacote quando não temos um ambiente virtual ativo:

Perfeito! Mas, agora que essa opção está definida, como instalamos ou configuramos um pacote global. Nós podemos temporariamente desligar essa restrição adicionando o seguinte no seu ~/.bashrc:

Se no futuro quisermos atualizar nossos pacotes globais, a função acima nos permite isso dessa forma:

É claro que você podia fazer o mesmo usando PIP_REQUIRE_VIRTUALENV="" pip install --upgrade foobar, mas isso é muito mais chato de digitar.

Criando ambientes virtuais

Vamos criar um ambiente virtual para o Pelican, um gerador de site estáticos baseado em Python:

Mude para o novo ambiente e ative-o assim:

Para instalar o Pelican no ambiente virtual, vamos usar o pip:

Para mais informações sobre ambientes virtuais, leia a documentação do virtualenv.

Dotfiles

Estes são obviamente apenas os passos básicos para se ter configurado um ambiente de desenvolvimento Python. Se tiver achado este artigo útil, você pode dar uma olhada no projeto Dotfiles do Justin Mayer no Bitbucket ou no Github, que ele recentemente começou a reconstruir do zero. Ele ainda está no começo do processo de ir adicionando seletivamente um pedaço de cada vez, e logo deve aumentar isso.

É isso aí pessoal, até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Plugin Composer para o PHP-Build

Olá, pessoal.

Logo do Composer
Logo do Composer

Para os que já utilizam o php-build, do CHH, foi lançado o plugin para já deixar disponível o Composer na linha de comando automaticamente a cada novo Build do PHP.

https://github.com/rogeriopradoj/php-build-plugin-composer

http://documentup.com/rogeriopradoj/php-build-plugin-composer

Eu já falei um pouco sobre o php-build nesse artigo sobre como eu atualizei a versão do meu PHP no meu Mac.

 

Feedback?

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Desenvolvimento e TI em geral

%d blogueiros gostam disto: