mai 13 2013
Leave a comment
PHP

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!

Tagged , , , , ,
mai 02 2013
Leave a comment
Mac

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!

Tagged , , , ,
mar 18 2013
1 Comment
PHP

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?

 

Tagged , ,
mar 10 2013
Leave a comment
Mac

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

Olá, pessoal,

Vou mostrar aqui como fiz para atualizar a versão do Openssl no meu Mac OSX Mountain Lion.

O Openssl atualizado é uma das dependências para compilar o PHP com a extensão Openssl.

Esse artigo ainda está relacionado com a atualização do PHP na minha máquina usando o php-build e o phpenv do CHH.

Então vamos lá, e só para não esquecer, este artigo foi baseado nessa resposta do stack overflow e nesse outro artigo aqui.

—

Para começar, abra seu terminal para verificar qual a versão do Openssl que você tem instalada:

$ openssl version

Aqui, aparecia a versão OpenSSL 0.9.8r 8 Feb 2011.

No momento da escrita, março de 2013, a última versão disponível no site oficial era a openssl 1.0.1e, vamos então atualizar o nosso sistema.

No início, tentei utilizar a versão disponibilizada pelo Homebrew, mas, mesmo após usar o brew install openssl e o brew link openssl --force (comandos que instalariam o Openssl e depois o registrariam como o Openssl padrão do sistema), a versão disponível no meu terminal continuava desatualizada.

Foi aí que decidi compilar eu mesmo a versão mais nova, fazendo o seguinte:

  • descobrir se o seu sistema operacional é 64bit ou 32bit, você vai precisar dessa informação mais à frente. Para isso, executar: $ uname -m. Se aparecer x86_64 seu computador é 64bit, se aparecer i386 ele é 32bit (estou supondo que o processador do seu Mac seja Intel, e não seja PowerPC. Ele já é Intel, certo? Se não for, melhor parar por aqui…)
  • baixar o fonte do Openssl, última versão, no site  http://www.openssl.org/source/ (geralmente é o primeiro link dessa página, marcado em vermelho como [LATEST]), no meu caso foi o openssl-1.0.1e.tar.gz
  • entrar pelo seu terminal onde você baixou o arquivo (padrão no Mac e na pasta Downloads dentro da sua pasta de usuário, exemplo: $ cd ~/Downloads
  • descompactar o arquivo openssl-1.0.1e.tar.gz, exemplo: $ tar -zxvf openssl-1.0.1e.tar.gz
  • entrar na pasta que acabou de ser criada com a descompactação, exemplo: $ cd openssl-1.0.1e
  • Configurar o fonte, exemplo para 64bit: $ ./Configure darwin64-x86_64-cc --prefix=/usr no-threads shared. Exemplo para 32bit: $ ./Configure darwin-i386-cc --prefix=/usr no-threads shared
  • Rodar o make, tente primeiro sem usar o sudo, e, apenas se der erro, rode com o sudo. Exemplo: $ make. Apenas se tiver dado algum erro de permissão: $ sudo make
  • Rodar o make install, mesma orientação acima. Exemplo: $ make install. Se tiver dado algum erro de permissão: $ sudo make install.
  • Feche o terminal.

Pronto, agora você já deve ter instalada a última versão do Openssl, baixada diretamente do site oficial e compilada para o seu sistema.

Para confirmar que deu tudo certo, execute:

$ openssl version

Aqui para mim apareceu OpenSSL 1.0.1e 11 Feb 2013, e para você?

Deixe seus apontamentos aí nos comentários, ou entre em contato, ok?

Até mais!

Tagged , , , , , , ,
fev 03 2013
Leave a comment
Geral

Introdução do MongoClient

Estou fazendo o curso de MongoDb oficial da 10gen. A ideia da tradução desse artigo saiu de lá.

Tradução livre do Introducing MongoClient, disponível em http://blog.mongodb.org/post/36666163412/introducing-mongoclient

—

Em 27 de novembro de 2012 foram disponibilizadas pela 10gen versões atualizadas da maioria dos drivers para MongoDB mantidos oficialmente, com novos padrões para verificação e reportagem de erros. Veja abaixo mais informações sobre as mudanças, e consulte a documentação dos drivers para mais detalhes.

Nos últimos anos, tornou-se evidente que os padrões anteriores no comportamento do MongoDB (onde por padrão as mensagens de escrita não esperavam  um código de retorno do servidor) não eram intuitivos e causavam confusão com os usuários do MongoDB. A 10gen queria melhorar isso com o mínimo de problemas para as aplicações MongoDB que já estivessem em produção.

História

Primeiro, seria interessante compartilhar a história por trás do comportamento padrão anterior, e por que e como ele foi alterado.

O comportamento antigo está ligado ao início da 10gen, antes dos fundadores terem imaginado o MongoDB como uma base autônoma. Quando a 10gen começou, no outono de 2007, eles se propuserem a construir uma plataforma completa como uma pilha de serviços, com o MongoDB como a camada de dados. Era um sistema totalmente hospedado (continua sendo de código aberto), que englobava um load balancer, uma aplicação auto-escalável e uma camada de dados. A parte da aplicação era um ambiente completo em JavaScript do lado servidor.

Toda requisição na 10gen era uma requisição http. Você poderia imaginar um controller para fazer alguma análise de usuários funcionando assim:

URL:  http://foo.10gen.com/show?sect=sports&page=blog1

CODE:

db.sect_views.update(
{ _id : db.getParameter( “sect” ) } ,
{ $inc : { count : 1 } } , /*upsert*/true );
db.page_views.update(
{ _id : db.getParameter( “page” ) } ,
{ $inc : { count : 1 } } , true );

As escritas naquela sistema não esperavam individualmente por uma resposta do banco de dados. No entanto, o próprio servidor da aplicação verificava sempre o banco de dados por algum erro que ocorresse durante todo o carregamento da página (usando getLastError e getPrevError), assim o usuário/sistema poderia ser notificado sobre algum problema. É claro que os desenvolvedores também poderiam chamar a função getLastError sempre que quisessem. Isso funcionava muito bem na plataforma, pois a 10gen era capaz de controlar completamente o padrão de acesso.

Em janeiro de 2009, eles decidiram, por um série de razões, apenas focar na camada de dados (MongoDB). Naquela época, um certo número de pessoas vinha usando o MongoDB em produção por quase um ano como parte do projeto completo, e muito mais pessoas estavam bem interessadas em usá-lo de forma independente.

Durante os meses seguintes, eles escreveram as implementações iniciais dos drivers Java, Python, Ruby e PHP. Todos esses drivers usavam o mesmo protocolo de rede que o servidor da aplicação original, com operações de escritas não síncronas. Isso parecia natural para eles devido ao tempo passado no background, mas claramente não era tão intuitivo para novos usuários do MongoDB que nunca haviam usado o pacote completo.

Novo Comportamento

Avançando, o padrão claramente tinha que ser: esperar o banco de dados acusar todas as escritas, o que é muito mais intuitivo. No entanto, apenas mudar o padrão, levaria à quebra da compatibilidade com os aplicativos em produção.

A mudança que eles fizeram foi adicionar uma nova classe de conexão, de nível superior, em cada um dos drivers. Por exemplo, no Java, anteriormente se fazia assim:

Mongo mongo = new Mongo( “mongoserver” );

Aquela classe, Mongo, será mantida como o padrão antigo, e se torna obsoleta/deprecated.

Para novos códigos, você fará:

MongoClient mongo = new MongoClient( “mongoserver” );

que terá como padrão 1 no WriteConcern. Todo o resto será do mesmo jeito.

A classe antiga será mantida por um tempo (mas não para sempre), para que não seja quebrado agora o código antigo. Um outro benefício, todo driver usará o MongoClient, assim pela primeira vez ao menos no nível superior das classes se terá o mesmo nome sendo compartilhado. Toda a documentação, tutoriais e códigos de exemplo foram alterados apropriadamente.

Mais informações

  • Para baixar os drivers, documentações e tutoriais, visite a página de drivers na wiki do MongoDB.
  • Para reportar bugs e para pedidos de funcionalidades, visite jira.mongodb.org.
  • Para qualquer outro feedback, deixe um comentário no post no forum de usuários

O Eliot e a Equipe MongoDB agradecem o suporte contínuo e feedback da comunidade sobre o MongoDB.

 —

Valeu, pessoal!

 

jan 06 2013
1 Comment
Geral

Screencast – Contribuindo para um projeto open source no Github

Olá, pessoal!

Primeiramente, feliz 2013, e vamos começar esse ano com um screencast, meu primeiro!

Será que todo mundo da comunidade  já contribui ou contribui para um projeto Open Source (seja um já existente, ou criando um)?

Eu só comecei a ajudar depois do projeto/promoção http://sou.phpsp.org.br/ do PHPSP, que infelizmente já acabou.

Mesmo assim continuei me envolver nos projetos e, posso dizer: você EVOLUI MUITO dessa forma!

Esse meu primeiro screencast (já me desculpando antecipadamente pela qualidade, hehehe) mostra o processo de contribuição para incluir a integração ao http://travis-ci.org/ no projeto do João Batista Neto, o https://github.com/netojoaobatista/maestro.

Quis montar ele para ajudar o pessoal que ainda não começou a contribuir talvez por achar que é muito difícil, ou por não ter uma ideia de como começar. Com certeza a inspiração veio do projeto iMasters + Comunidade PHP que fez o Hangout de uma aplicação sendo desenvolvida ao vivo!

Digam o que acharam, ok?

Até mais!

 

Link para o vídeo: http://www.youtube.com/watch?v=CVXhZIIg3zU

 

nov 20 2012
8 Comments
Geral, Mac, PHP

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.

Tagged , , , , , , ,
out 25 2012
1 Comment
Geral, PHP

[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

O @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 ;-) .

Tagged ,
set 23 2012
Leave a comment
Geral, PHP

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!

Tagged , ,
jul 05 2012
3 Comments
Geral

Documentação em português do Brasil (pt_BR) do Vagrant

Olá, pessoal.

Até para ajudar na minha palestra no TDC2012, comecei o projeto de tradução da documentação do Vagrant para português do Brasil (pt_BR, pt-BR, pt-br etc etc etc).

Seguem links:

garoto propaganda do vagrant

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

Até mais!

Tagged
← Older posts