Arquivo da categoria: PHP

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.

[atualizado8x] Promoção Entrada VIP – PHP Conference Brasil 2012 – Vou palestrar 2x

Olá, pessoal.

PHP Conference Brasil 2012 - 7 anos

Estou feliz e ansioso pois esse ano vou ser palestrante duas vezes na PHP Conference Brasil 2o12, a sétima edição do “O principal evento de PHP da América Latina” or “The main PHP event in Latin America” :-).

As palestras são as seguintes;

Vou palestrar na PHP Conference Brasil 2012

Agora chega de propaganda, e vamos ao que todo mundo está esperando: entrada VIP de graça d’grátis na faixa sem custo algum.

Promoção-relâmpago

Tenho uma (ou duas) entradas vip, modalidade SILVER (que permite assistir todas as palestras do evento), válidas para uso até hoje, 25/10/2012.

Se você estiver interessado em ganhar uma dessas inscrições de graça, vou fazer o sorteio lá no meu Twitter, o @rogeriopradoj (você não precisa estar me seguindo para concorrer, mas se quiser aproveitar :-) ).

Primeira coisa: se você não tem uma conta lá no Twitter, crie uma gratuitamente.

Para participar, basta postar o tweet abaixo no seu perfil (ou retuitar) até as 13-14 horas (pelo horário de Brasília) de hoje, quinta-feira, 25 de outubro de 2012. Atenção: o tweet deve ficar exatamente desta forma (com a mesma URL!):

Estou concorrendo a entradas VIP – SILVER para a @phpconferencebr, sorteadas pelo @rogeriopradoj! http://migre.me/bjExt

Após a data e horário limites (hoje, 25/10/2012, até as 13-14), vai ser feito o sorteio entre os participantes.

Algumas regras:

  • Utilizarei o sistema Sorteios.org ou o Sorteie.me, e vou colocar o resultado final aqui depois.
  • Para ter a sua participação validada, siga à risca as instruções acima. Você precisa ter postado o tweet ou dado RT na mensagem (tanto de forma nativa quanto no método antigo) como apresentado acima, incluindo a URL Migre.me — e não se preocupe se o Twitter alterá-la para T.CO automaticamente.
  • Quem não tem conta no Twitter, não gosta da (ou tem pouco tempo para a) rede social ou coisa do tipo também pode participar. Basta se registrar lá e seguir as instruções conforme apresentamos aqui, associando a sua conta a um cadastro no nosso banco de dados.
  • Você pode postar quantos tweets quiser em sua conta, mas apenas um será contabilizado pelo sistema. Você *não* ampliará suas chances de ganhar fazendo isso.
  • Como o VIP só vale até hoje, 25/10/2012, o(s) ganhadores terão que responder em até 30 minutos com os dados para que eu possa enviar as informações para utilização do prêmio. Caso não conseguir, o prêmio será passado para um próximo sorteado.

Boa sorte, pessoal, e boa PHP Conference para todos!

ATUALIZAÇÃO – 15h30

Saiu o resultado:

@willmendesneto e @dannjesus foram os vencedores, link do sorteio.

Os ganhadores tem até as 16 horas para me mandar o e-mail de contato para que eu encaminhe as cortesias. Se algum deles não conseguir, novo sorteio para conseguir enviar o código para utilização do prêmio.

Lembrar que a mensagem com o e-mail tem que vir do Twitter (para confirmar que é a mesma pessoa)!!!

ATUALIZAÇÃO – 16h30

Como os primeiros não responderam no Twitter, conforme regra, saiu o novo sorteio.

Ganhadores:

@WesleyRib e @MayogaX foram os vencedores dessa vez!

Link do sorteio: http://sorteios.org/resultado/twitter/en

Pessoal, percebam que esse link do sorteio eu listei todo mundo por ordem. Fica assim:

  • Quem já ganhou e não respondeu, fica fora.
  • Quem ganhou, na ordem, será avisado via Twitter e terá 30 minutos para responder.
  • A resposta tem que ser via Twitter me informando o e-mail (mande por DM ou mention mesmo)
  • Se algum não responder, passa para o próximo da lista que terá os mesmo 30 minutos para responder a partir do meu contato no Twitter da pessoa.
  • Vou atualizando esse post com os resultados.
Parabéns a todos!

 ATUALIZAÇÃO – 17H43

@WesleyRib não respondeu, próximo da lista é o @adanfm.

Boa sorte!

ATUALIZAÇÃO – 18H35

@adanfm não respondeu, próximo da lista é o @rudwolf.

Boa sorte!

ATUALIZAÇÃO – 19H28

@rudwolf não respondeu, próximo da lista é o @rafael_mussi.

ATUALIZAÇÃO  – 19H48

@rafael_mussi ainda está em tempo, mas já está quase no fim da linha.

Se ele não conseguir confirmar, fiquem de olho quem ainda está na lista, a ordem será a seguinte:

@ifranca

@jstecladista

@easakira

@xDuh

@dannjesus (obs.: está no fim desta lista pois não conseguiu responder no prazo no primeiro sorteio)

@willmendesneto (obs.: está no fim desta lista pois não conseguiu responder no prazo no primeiro sorteio)

 ATUALIZAÇÃO – 20H00

@rafael_mussi não respondeu, próximo da lista é o @ifranca.

Boa sorte!

ATUALIZAÇÃO – 21H47

@ifranca não respondeu, próximo da lista foi o @jstecladista.

Ele respondeu com o e-mail dentro do prazo e já recebeu o código.

Obrigado a todos que participaram, e parabéns aos que ganharam no fim (@MayogaX e @jstecladista).

E para quem não ganhou, não desanime. Corre lá para fazer sua inscrição com desconto especial até dia 14/11/2012. Lembre que, investir em você mesmo, não tem preço ;-).

Vagrant: O que, Por que e Como

Tradução livre de Vagrant: What, Why, and How, disponível em http://net.tutsplus.com/tutorials/php/vagrant-what-why-and-how/.

Este artigo te ajudará a usar o Vagrant para administrar suas instâncias de máquinas virtuais e explicará como se beneficiar do Puppet para fazer a provisão de vários recursos como o PHP e o PostgreSQL.

garoto propaganda do vagrant
Garoto propaganda :-) da ferramenta Vagrant – http://vagrantup.com

Introdução

Os desenvolvedores tem à disposição um grande número de maneiras de construir seu ambiente de desenvolvimento web. Podem ser usadas opções “locais”, do tipo dos servidores “tudo em um”como o Zend Server, XAMPP, MAMP, WAMP etc; ou ainda como você instalando os componentes a partir dos fontes ou via um sistema de gerenciamento de pacotes, como o Homebrew, o Apt ou o Yum.

Isso vai se acumulando a medida que você trabalha em vários projetos diferentes: PHP 5.3 e PHP 5.4, MySQL, SQLite, MongoDB, Postgres, PEAR, PHPUnit, Rails 3.1, Memcached, Redis, Gearman, NodeJS etc. E se você precisar  atualizar seu computador se ele pifar, você terá que começar tudo de novo.

Pode ser usada uma configuração “remota”, com um servidor com compartilhamentos “Samba” ou um servidor SSH montado com uma ferramenta como o ExpanDrive. A última opção esbarra na latência de leitura e escrita dos arquivos, que é extremamente chata. É possível usar o SSH com o Vim para tudo, o que é rápido, mas só funciona se você quiser usar o Vim para tudo também.

Desenvolvimento vs Produção

Mesmo que você esteja feliz com a forma que vem fazendo as coisas até agora, quantas vezes você já ouviu (ou disse) “Bem, está funcionando no meu computador”?

Isso é terrivelmente comum e acontece quando os ambientes diferem até mesmo nos detalhes mais triviais.

É extremamente importante garantir que seu ambiente de desenvolvimento seja idêntico ao ambiente de produção, e que ele também corresponda ao servidores de staging e de teste se esses existirem.

Isso pode parecer fácil se você pensar apenas na instalação do Apache, do PHP de alguma cópia do MySQL, porém existem milhões de fatores para avaliar. Se você estiver desenvolvendo no OSX e fazendo deploy num sistema Ubuntu, então você deve se deparar com problemas estranhos relacionados a maiúsculas. Isso é comum no CodeIgniter, quando alguém cria uma biblioteca com a primeira letra minúscula. Ela irá carregar corretamente no OSX, mas irá quebrar quando for implementada na produção. Seu processo de desenvolvimento pode ter feito você perder alguns contratos só por causa de algumas diferenças triviais entre sistemas operacionais que ninguém notou até ser muito tarde.

Desenvolvimento = Produção

Então qual é a solução? Forçar que todos os desenvolvedores joguem fora suas ferramentas e trabalhem todos no mesmo modelo de laptop? Se os seus colegas ganharem Macbooks novinhos em folha talvez você não ouça muitas reclamações, mas você teria que usar o OSX Server para tudo.

Você poderia usar o Linux para tudo, mas entraria numa briga para decidir qual distribuição utilizar. Forçar os desenvolvedores para usar o mesmo sistema operacional gera problemas, reduz a produtividade e promove lutas de nerds.

A virtualização é a resposta e isto não é nada novo, mas geralmente quando pensamos em virtualização pensamos nos problemas de performance e nas ventoinhas girando que nem malucas enquanto o sistema tenta rodar dois sistemas operacionais ao mesmo tempo.

Essa situação pode ser verdade quando tentamos rodar o Windows em uma máquina não muito potente mas, hoje em dia, um Mac mediano com 4 GB de RAM de fábrica é mais do que suficiente para rodar uma instalação de um servidor Ubuntu em modo de linha de comando com todas ferramentas habituais (IDE, browser, ferramentas de depuração etc.). Existem diferentes versões de virtualização, mas eu prefiro o VirtualBox da Oracle (que é grátis). Esse programa faz o “trabalho pesado” da virtualização, enquanto a ferramenta Vagrant serve para gerenciar as instâncias.

Passo 1 – Instalando o VirtualBox

Primeiro, baixe e instale o VirtualBox. Nos sistemas *nix (Mac OSX, Linux etc.) você precisará alterar seu .bash_profile (ou .zsh_profile) para estender a variável $PATH:

Isso permitirá que o Vagrant saiba onde o VirtualBox está instalado e, é claro, será diferente em cada sistema operacional.

Passo 2 – Instalando o Vagrant

Você pode baixar um binário do vagrant para o seu sistema operacional, ou instalar ele como uma gem se não houver um binário disponível:

Passo 3 – Criando uma Instância

Crie um lugar para suas configurações ficarem:

Iremos usar o Ubuntu 12.04 LTS (Precise Pangolin), o qual já tem uma “box” configurada.

Aqui você enxerga o argumento “precise32″, que é o apelido da URL. Agora você pode criar a instância que irá baixar o arquivo .box.

Agora ela estará rodando. Fácil! Se você quiser acessar a instância via SSH, use este comando:

Passo 4 – Configuração

Você terá um arquivo, chamado Vagrantfile, que conterá a configuração dessa instância:

Essa é, se você ainda não notou, sintaxe Ruby; por isso você pode ser bem criativo com o arquivo, apesar de aqui só termos o básico.

Ele mostra qual apelido usar, e tem a URL para o caso do apelido não estar definido localmente (útil para casos de compartilhamento).

As linhas share_folder são bem úteis para mapear pastas da instância com pastas locais. Usando nfs => true a instância será capaz de escrever e alterar permissões dos arquivos, o que é útil se você estiver, por exemplo, tentando instalar um CMS ali.

O redirecionamento de portas permite que você acesse sua instância em http://localhost:8080 e, é claro, faça alterações para diferentes portas em caso de conflito.

Esse arquivo de configuração também define o fuso horário para Europe/London, depois executa o apt-get update, que força seu sistema para se atualizar toda vez que ele é iniciado. Se você pular esse item da configuração, pode encontrar vários pacotes se recusando a instalar pois as referências estão desatualizadas.

Quando você alterar a configuração, pode recarregar a instância para utilizá-la:

Agora que nossos servidores estão no ar e prontos para continuar, precisamos instalar neles alguns softwares. Não vamos só rodar o apt-get install em um monte de pacotes na linha de comando, vamos “provisionar” nossos servidores.

Passo 5 – Provisionamento

O provisionamento ou configuração do servidor não é algo que a maioria dos desenvolvedores pensam a respeito pois isso é feito normalmente pelos sysadmins. A ideia é criar algum registro do que software e configurações foram postas em um servidor assim você poderia criar novos ambientes de desenvolvimento, novos servidores staging que replicam os servidores de produção ou então criar outro servidor de produção para fazer balanceamento de carga entre eles.

Provisionamento das antigas

Como os sysadmins lidam com isso varia, mas no passado foram usados todos os tipos de solução – desde manter uma wiki dos comandos que foram executados (o que pode ficar grande e obsoleto rapidamente) e o maravilhoso método de manter um “multi-terminal”, onde você digita os comandos em uma janela e ele replica os mesmos comandos para outros 7 servidores ao mesmo tempo. Todos esses métodos são terríveis.

Uma solução seria criar o seu próprio arquivo .box ou criar um backups .iso assim novos servidores poderiam ser baseados neles; no entanto manter essas imagens gera um monte de trabalho extra e não importa o quanto você tente, essas máquinas de desenvolvimento se tornarão obsoletas com o tempo.

Provisionamento moderno

Existem atualmente dois sistemas populares, o Puppet e o Chef. Ambos existem há anos, mas começaram a se tornar bem populares com o aumento do uso método de desenvolvimento DevOps. As ideias dos dois são parecidas e você deveria estudar os dois sistemas, mas aqui no tutorial iremos nos focar exclusivamente no Puppet.

Basicamente, em vez de rodar um série de comandos e torcer para que tudo dê certo, você criará um manifesto para o Puppet explicando tudo o que você precisar garantir que tenha sido feito. Quando você roda um comando no terminal, você está basicamente dizendo ao computador:

“Instale o Apache”

Com o Puppet você diria:

“Garanta que o Apache está instalado”

Ou, em vez de:

“Crie uma nova pasta, chame-a de /var/www e defina a permissão para www-data:www-data”

Com o Puppet diríamos:

“Garanta que exista /var/www e que tenha permissões que correspondam com www-data:www-data”

A diferença aqui é que esses manifestos podem ser executados múltiplas vezes (em um cron job a cada hora ou diariamente) para deixar tudo atualizado, e não haverá resultados inesperados de algo tentando ser instalado duas vezes.

Ele também irá testar se tudo está rodando como esperado, pois se alguma dessas regras falhar serão emitidos erros que são mais fáceis de rastrear do que rodar o grep numa grande quantidade de resultados de comandos bash. O Puppet irá mostrar erros grandes e vermelhos que deixarão você saber se o PHP não foi instalado ou um módulo específico não puder ser configurado.

Manifestos e Módulos

Os manifestos são um pouco confusos no início, mas depois de um tempo, eles começam a fazer sentido.

Para revisar um exemplo básico:

Não é preciso explicar o que está acontecendo aqui, certo?

Esse arquivo pode ser referenciado mais para a frente no seu manifesto como “testfile”, o que indica que ele pode ser listado como uma dependência para outras ações.

Para exemplos mais complexos, vamos referenciar o os manifestos Puppet do PyroCMS no GitHub.

Ele inclui o módulo “apache”, define algumas variáveis, executa o manifesto extra “apache:php” no módulo apache, cria um virtual host e garante que o “mod_rewrite” está habilitado.

Todas essas classes são definidas no módulo Apache que incluímos.

Continuando, também queremos instalar o PHP:

Esse trecho do manifesto irá instalar as extensões PHP que precisamos e depois a opção notify informará ao Apache que você instalou novas configurações, indicando que ele deve reiniciar.

Aqui será configurado um servidor postgres, criado um banco de dados chamado “pyrocms” e garantir que exista um usuário “pyrocms” com a senha informada.

Perto do fim! O último passo é garantir que você tenha arquivos e pastas com permissões de escrita definidos corretamente:

Isso irá garantir que exista um document root do Apache, que o arquivo de configuração esteja configurado como 0666 e que algumas pastas estejam como 777.

E aí temos tudo!

Se tudo funcionou corretamente, você deve estar vendo vários linhas de texto azul sinalizando cada coisa que está sendo instalada mas, se algo der errado, verá linhas vermelhas. Pesquise no Google sobre esses erros e tente novamente.

Os módulos usados aqui são: Apache, Postgres e PHP, e você pode ver tudo em ação clonando o repositório Vagrant do PyroCMS:

Aponte seu navegador para http://localhost:8089/ e você deve enxergar o instalador. Bem fácil, não?

Nota: Será instalado o MySQL pois o suporte ao Postgres e ao SQLite no PyroCMS ainda está em desenvolvimento, esperando algumas funcionalidades PDO ficarem prontas no CodeIgniter. Se você estiver interessado, pode experimentar alterar o Vagrantfile para usar o manifesto ubuntu-apache2-pgsql-php5.pp, destruir a instância e em seguida iniciá-la novamente. O submódulo pyrocms também precisará de um checkout do git em feature/pdo.

Sumário

Nesse artigo, usamos o Vagrant, o VirtualBox e o Puppet para, não apenas configurar uma instância de um servidor para trabalharmos, mas criarmos um suite de testes para nosso servidor garantir que tudo esteja corretamente executando, instalado e configurado.

Também criamos um checklist para os requisitos e, no futuro, poderemos criar qualquer número de servidores iguais a esse em minutos, e não em horas!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Vou palestrar na TDC 2012, Desenvolvimento PHP com Vagrant

Olá, pessoal,

TDC 2012 - Logo

Já está em cima da hora, mas nesse sábado, 07/07/2012, vou ser palestrante no evento TDC – The Developer’s Conference.

TDC São Paulo 2012 - Trilha PHP - Logo

Minha palestra, será dentro da Trilha PHP e abordará como utilizar a ferramenta Vagrant para criar uma ambiente de desenvolvimento PHP com máquinas virtuais de forma fácil.

PHP - Logo + Vagrant Logo

Aproveito para agradecer ao Grupo de Usuários PHPSP, tanto à coordenação que acreditou na palestra e aceitou que eu palestrasse, quanto à própria comunidade que têm tantos profissionais brilhantes que me motivam sempre a buscar aperfeiçoamento.

Diga nos comentários se você já usa ambientes de desenvolvimento virtualizados no seu dia a dia, e se já conhece a ferramenta Vagrant.

Até mais!