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 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!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

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

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

 —

Valeu, pessoal!

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

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

 

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.

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!

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!

3 excelentes ferramentas para organização

Você já teve aquela sensação de que, apesar de estar fazer um grande número de coisas, está entregando pouco?

Talvez seja falta de organização!

Essas 3 ferramentas abaixo devem te ajudar a melhorar nesse quesito, e fazer você se sentir mais realizado:

Tomatoes (tracker online para técnica Pomodoro)
Trello (kanban online multi-usuário)
Workflowy (gerenciamento de listas online)

Para quem já leu algo sobre desenvolvimento ágil, GTD e assuntos relacionados (e sabe um mínimo de inglês), as ferramentas acima são bem fáceis de utilizar.

Deixe sua opinião nos comentários.

[edit] 25/09/2012 – Atualização do link do Tomatoes e do Workflowy.

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Desenvolvimento e TI em geral

%d blogueiros gostam disto: