Como acompanhar as listas de discussão oficiais do PHP.net

Olá, pessoal,

Hoje vamos falar sobre as listas de discussões oficiais do PHP, as famosas mailing lists do PHP.net (só como adendo, PHP.net é o site da linguagem que hospeda também muitos projetos relacionados, como os conhecidos PEAR.php.net e PECL.php.net, o repositório GIT.php.net, até o muitas vezes desconhecido PEOPLE.php.net. Para conhecer mais, use a WIKI.php.net).

Para que servem as mailing lists?

As listas de discussão são onde conseguimos ter as informações mais recentes, interessantes muitas vezes, e provavelmente inéditas sobre vários assuntos.

É bem possível se manter bem informado sobre o andamento do ecossistema PHP por uma série de lugares: sites e blogs especializados, livros, encontros de comunidades (já conhece o PHPSP? :-) :-) :-) )…  O próprio GitHub (php/php-src) é uma ótima fonte de informação hoje em dia. Mas, sem  acompanhar as listas de discussão, perde-se um pouco do potencial que temos à nossa disposição.

Você já deve ter escutado algo do tipo:

…O pessoal no Internals está discutindo chamar a próxima versão da linguagem de XYZ, mas Joãozinho não aceitou por causa disso e daquilo outro…

No começo deve ter ficado “boiando”, e perguntou o que era aquele Internals, descobrindo que era uma mailing list/lista de discussão. Mas só saber o nome da lista não adianta muito, se você não conseguir assiná-la, não é mesmo?

Eu tive problema parecido. Foi quando estava começando a buscar mais informações sobre como trabalhar na tradução do manual do PHP para pt-BR, no PHPSP+Docs #1 de 11/2013. O fera Klaus Silveira me indicou o caminho descrito na wiki dos esforços da tradução, que era assim:

…Toda a comunicação entre os tradutores deve ser feita através da lista de email oficial… (doc-pt-br@lists.php.net)

Ok, já tinha até o “nome completo” da lista, mas ainda não sabia como assiná-la! Por que será que era tão difícil?!?!

Um pouco diferente do que fazemos Yahoo e Google Groups

Lembro que na época da faculdade era comum participar de listas de distribuição internas dos grupos da sala. As primeiras, feitas no Yahoo Grupos, e com o tempo, as coisas começando a migrar para o Google Groups. Hoje ainda participo de uma série por lá, como o PHP Brasil Comunidades e o php-build developers, e nunca tive dificuldade para assinar nenhuma das listas. O passo era:

  • criar uma conta Yahoo/Google
  • acessar o site do grupo
  • clicar no botão registrar/assinar/entrar
  • e ser feliz!

Além do mais a lista nesses casos sempre tinha uma página web específica, onde quem não tinha assinado podia ver online as discussões, e quem já estava cadastrado podia editar suas opções de recebimento (quantidade de e-mails diários a receber, descadastramento etc.). E o pior que esse fluxo funcionava para qualquer lista! E, com certeza, esse foi o problema!

Numa palestra que assisti sobre Agile, ministrada pelo Juan Bernabó, da Germinadora, ele dizia que aprender era fácil quando conseguimos desaprender antes, o que é difícil. Eu demorei muito mais para achar o formato de assinatura para as mailing lists do PHP.net porque eu demorei para “desaprender” o jeito Yahoo/Google. E não é que o jeito PHP.net é fácil também! Só é diferente! Vamos lá então ver como fazer.

Interface web das listas de discussão

Primeiro você tem que achar qual é a lista de seu interesse. Em http://news.php.net/ estão listadas todas as opções. É só clicar sobre o link referente à lista que você escolher e navegar por ela. Bem simples.

PHP mailing lists news.php.net

Quer umas dicas para começar?

Passos para assinar uma lista de discussão PHP.net

Assinar listas principais com botão Subscribe

Você pode acessar a página http://php.net/mailing-lists.php que te dá uma introdução sobre o funcionamento das listas, mostra as principais delas (o índice completo está em http://news.php.net/), e permite que se assine por lá.

http://php.net/mailing-lists.php

 

Exemplo de assinatura da lista Internals:

http://php.net/mailing-lists.php

  1. acesse http://php.net/mailing-lists.php
  2. selecione/marque o radio button Normal em Internal List
  3. digite seu e-mail no campo Email
  4. clique no botão Subscribe

Pronto. No fim, você vai receber um e-mail automático, para confirmar a assinatura é só responder a mensagem.

confirm_subscribe_to_internals_lists_php_net

 

Assinar listas sem botão de Subscribe

Infelizmente, nem todas as listas estão lá naquele endereço, e é necessário trabalhar um pouquinho mais para começar a receber as discussões em sua caixa postal. Mas não é nada impossível, existem comandos que permitem gerenciar suas assinaturas sem nem precisar de interface web. E, o melhor, funcionam para qualquer tipo, tanto as principais quanto as outras.

O sistema de listas de distribuição que o PHP.net utiliza é o ezmlm-idx, cujo manual de utilização está disponível no endereço http://untroubled.org/ezmlm/ezman/ezman1.html. Então, se quiser ir mais a fundo, é só RTFM! Mas é lógico que vou colocar aqui os comandos mais básicos e úteis para o nosso caso.

Para ver todos os possíveis comandos sobre uma lista, é só mandar um e-mail para:

nomedalista-help@lists.php.net

Percebeu ali o -help (hífen help) antes da arroba (@)? Se você souber o nome da lista (sugiro usar como base o http://news.php.net/ para pegar o nome), é só mandar um email para lá (não precisa ter assunto nem corpo de texto) que você receberá de volta as instruções.

Agora, para assinar uma lista, é o -subscribe (hífen subscribe) que você usará:

nomedalista-subscribe@lists.php.net

E, para cancelar a assinatura, -unsubscribe (hífen unsubscribe):

nomedalista-unsubscribe@lists.php.net

Como nos inscreveríamos então na lista doc-pt-br, onde rolam as discussões sobre a tradução para português (pt-BR) do manual da linguagem?

É só mandar um e-mail para:

doc-pt-br-subscribe@lists.php.net

E se quisesse cancelar a assinatura?

E-mail para doc-pt-br-unsubscribe@lists.php.net.

Quer mais informações: http://php.net/manual/en/faq.mailinglist.php

Considerações finais

As listas de discussão oficiais, as famosas mailing lists do PHP.net são um ótimo lugar para acompanhar informação privilegiada e muitas vezes passam despercebidas por muitos desenvolvedores. Nesse artigo aprendemos a localizá-las, acessá-las via interface web, e também a como assiná-las para recebimento no seu próprio e-mail.

Foquei bastante na lista doc-pt-br, pois a tradução de documentações é um dos meus maiores focos no mundo open source. A tradução do manual do PHP para português é um projeto que estou bastante envolvido no momento, que precisa de bastante ajuda da comunidade.

Se quiser saber mais, pode acessar a lista, a wiki e também ficar de olho em #PHPTranslationFestBrasil2014 no Twitter e nesta issue do PHPSP, que mais novidades serão divulgadas por lá!

Como sempre, fiquem à  vontade para perguntar e discutir nos comentários, ou em qualquer lugar da internet, sou o @RogerioPradoJ.

Até mais!

Referências

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.

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.

Como atualizar a versão do PHP no Mac OSX Mountain Lion

Olá, pessoal Venho usando o Vagrant (oficial, tradução e meu github) faz um tempo, para diminuir o número de coisas instaladas no meu notebook[bb], mas precisava atualizar a versão do PHP que tinha instalado por padrão no meu Mac OSX.

Participando do projeto do iMasters, oPHPortunidades (veja os hangouts), precisei rodar alguns comandos básicos no console, usando o excelente Composer, mas por não ter a última versão do PHP ficava difícil acompanhar o pessoal. Principalmente pela funcionalidade do servidor web embutido no PHP 5.4, que economiza bastante tempo para não precisar de configurar um Apache apenas para teste de uma aplicação.

É fato que usando o Vagrant poderíamos deixar preparado algumas receitas básicas, Puppet ou Chef, para deixar subir uma máquina com a última versão do PHP, mas a possibilidade abrir um terminal em um diretório com um projeto mínimo rodando apenas um php -S localhost:8080 em vez de um vagrant init, subl Vagrantfile, vagrant up, vagrant ssh etc etc era interessante.

Foi nesse momento que fui procurar uma opção de atualizar a minha versão global do PHP, do 5.3.15 que é a que vem instalada no Mac OSX Mountain Lion, para a versão mais nova estável, 5.4.8 quando esse artigo foi escrito. Quando comecei a usar o Mac, em agosto 2011, procurei uma solução parecida com a que usava no Windows, o XAMPP, e tinha encontrado o MAMP e o próprio XAMPP (que eu tinha usado no meu tempo de Ubuntu também também tem versão Mac). Mas não queria mais utilizar uma opção desse tipo. Queria ter a última versão realmente instalada e acessível a partir da linha de comando.

O primeiro lugar onde fui olhar foi o manual do PHP, que agora está um pouco mais atualizado, mas até quando eu vi (setembro 2012) só tinha uma sugestão: compile o PHP usando as instruções para UNIX. Escolhi não usar essa opção.

Um tempo atrás o Fábio Ribeiro perguntou no Twitter como o pessoal estava montando o ambiente PHP no OSX, e na época ele recebeu a indicação do Homebrew. Essa seria uma opção interessante.

Enquanto estava ajudando na tradução do PHP The Right Way, o PHP Do Jeito Certo, verifiquei que já existia uma pacote binário da versão mais nova do PHP 5.4, a http://php-osx.liip.ch/, que era até a versão recomendada pelos criadores do site. Mais uma boa opção para escolher.

Enfim, fui procurar um maior embasamento para minha escolha final: perguntar no Facebook, no grupo PHP Brasil. Lá vários caras que entendem do assunto deram suas opiniões e o mais legal: me deixaram com mais dúvidas ainda!!! Isso porque surgiram mais umas opções lá ainda não conhecia: o php-build e o phpenv.

O php-build é uma cara para compilar o php automaticamente a partir do repositório oficial do PHP, e o phpenv é uma ferramenta para definir qual versão do PHP você irá utilizar no caso de você ter instalado várias opções paralelamente. No fim, foi essas duas opções juntas que escolhi usar e vou mostrar aqui como fiz:

  1. Instalar o wget, usando o homebrew (ele é usado pelo php-build, mas você pode escolher outra forma de instalar o wget)
  2. Executar o brew install pkg-config curl freetype gettext jpeg libpng mcrypt zlib re2c tidy openssl pcre libxslt xmlrpc-c regex-opt exif json-c gd libiconv base64 icu4c lemon gmp t1utils mhash expat, usando o homebrew (pelo menos na versão do PHP 5.4.8 pelo php-build ele pediu algumas dependências, depois que instalei esses pacotes o problema parou de acontecer aqui)
  3. Instalar o php-build (usando a instalação padrão com o git, http://chh.github.com/php-build/)
  4. Instalar o phpenv (seguir o caminho que foi feito para instalar o php-build, depois na pasta bin, executar o phpenv-install.sh)
  5. Atualizar o seu PATH seguindo as orientações da saída do comando phpenv
  6. Instalar a versão que você quer do PHP, seguindo a instrução daqui: https://github.com/CHH/phpenv#description
  7. Rodar o phpenv rehash, o phpenv global com a versão escolhida e pronto!

Se você executar um php -v antes de fazer todos os comandos, você deve ver a sua versão do PHP como 5.3.15. Depois dos comandos acima, se executar um php -v deve ver a versão do PHP mais nova que você instalou (no meu caso ficou o PHP 5.4.8).

É isso aí pessoal, quem ficar com dúvidas pode perguntar nos comentários.

Até a próxima.

Este artigo foi publicado originalmente em RogerioPradoJ.com.