#30contribs – Cheguei nos 30! E quero de presente Pull Requests e contribuições para projetos open source e da comunidade!

Olá!

Hoje, dia 24 de junho de 2015 é um dia especial, pelo menos para mim :-) : cheguei nos 30! E como é meu aniversário, quero pedir um presente. Na verdade, um monte de presentes!!!

#30contribs 

Eu quero ver muitos Pull Requests e contribuições para projetos open source e da comunidade!

#30contribs

Minha ideia surgiu do projeto http://24pullrequests.com/ que, sempre no fim de cada ano, incentiva a ajuda para projetos open source. E também do saudoso Sou PHPSP e Contribuo, que em 2011 fez bastante gente começar nesse mundo das contribuições! E também de uma ideia que eu tive (mas não tinha colocado em prática) na apresentação que fiz no TDC 2014: Becoming a Contributor, Open Sourcer and Beyond.

O #30contribs não tem um site específico (ainda 😉 ) e nem a ideia de distribuir prêmios com base nas contribuições. É só contribuir! E colocar a hashtag #30contribs !

Mande o máximo que você puder! Só consegue uma contribuição? Tudo bem! Consegue várias? Melhor ainda! Não consegue nenhuma, mas vai correr atrás para conseguir daqui a pouco? Maravilha!

Ah, se quiser me mencionar (não precisa, mas ia ser bem legal), sou o @rogeriopradoj em quase todo lugar. Então, é só escrever, depois do texto do seu commit (ou pull request, ou issue, ou mensagem no Twitter, ou no Facebook etc):

“Essa contribuição é um presente #30contribs para o @rogeriopradoj”.

Ou algo assim!

E onde eu posso contribuir?

Se você já costuma contribuir para algum projeto, continue! Mantenha essa boa prática!

Se você tem algum projeto que sempre quis contribuir, mas ainda não tinha dado o primeiro passo, que tal começar agora com esse empurrãozinho?

Ou se você ainda não tem ideia nenhuma, não deixe que algum medo ou “vergonha” do seu código te impeça de começar! Tenho certeza que você se surpreenderá quando começar a contribuir. Tem sempre espaço para mais ajuda, mesmo pequenas contribuições são válidas! Além disso, a maioria do pessoal está disposta a ajudar quem está começando!

Quero sugestões de onde posso começar a contribuir!

Quer ajuda para saber por onde começar? Posso sugerir alguns lugares que conheço!

Que tal os projetos do PHPSP? Hoje, sou um dos evangelistas desse grupo e ajudo a organizar alguns eventos da comunidade. Tem uma série de projetos que precisam de ajuda sob o chapéu do grupo, então acesse lá: https://github.com/PHPSP. Ah, todos são bem-vindos a fazer parte do PHPSP!

E que tal o Saia de Casa!? Projeto que comecei com o William Espindola há alguns anos, o Saia de Casa! é uma agenda colaborativa de eventos para desenvolvedores mantida por desenvolvedores! Acesse lá: https://github.com/saiadecasa/saiadecasa.github.io

E que tal o #VagrantSP ou o https://github.com/FriendsOfVagrant? Muitos sabem que sou um entusiasta da ferramenta Vagrant já faz tempo!. O FriendsOfVagrant foi onde comecei a contribuir com a documentação em português no passado. Agitar um grupo de usuários em São Paulo era questão de tempo, foi aí que foi criado o Meetup Vagrant-Sao-Paulo (valeu Paulo Rezende por me apoiar também nessa empreitada)! Quer ajudar no GitHub: https://github.com/FriendsOfVagranthttps://github.com/vagrantsp/

E que tal o PHP-Build? Um projeto muito bacana de um austríaco (o Christoph Hochstrasser, @CHH), que serve para compilar o PHP em várias versões diferentes, em paralelo, na mesma máquina! Funciona muito bem em Linux, e também no Mac OS X. E até no Windows, se você usar algo como Vagrant ou Docker! Não conhece o PHP-Build e quer usar? Sugiro: https://php-build.github.io/https://github.com/rogeriopradoj/phpenv-installer http://rogeriopradoj.com/2012/11/20/como-atualizar-a-versao-do-php-no-mac-osx-mountain-lion/. Para ajudar nos repositórios: https://github.com/php-buildhttps://github.com/php-build/php-build/wiki/phpenv%20tools.

E que tal me ajudar em alguns pacotes PHP e FrontEnd/JavaScript que estão disponíveis no Packagist e no Bower? Acessa lá: https://packagist.org/packages/rogeriopradoj/http://bower.io/search/?q=rogeriopradoj.

Caramba, já sugeri aí em cima um monte de projetos, e tem mais um monte que gostaria de colocar! Se quiser mais ideias, dêem uma olhada no meu GitHub: https://github.com/rogeriopradoj.

Mas, de novo, essas são apenas sugestões, então, não importa para onde: o mais importante é que você faça mais contribuições!

Para não esquecer, #30contribs 

É isso aí, #30contribs ! Precisando de ajuda, é só chamar!

E feliz aniversário! :-)

Este artigo foi publicado originalmente em RogerioPradoJ.com.

 

 

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

Olá, pessoal!

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

Vagrant

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

Phpagrant_github_io_by_PHPagrant

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

Docker

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

Docker_-_Build__Ship__and_Run_Any_App__Anywhere

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

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

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

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

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

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

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

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

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

$ cd /Users/eu/projetos/php123/

  • De lá, rodo o seguinte comando:

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

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

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

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

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

É isso!

Quando precisar desligar o container, fazer os seguintes comandos:

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

  • $ docker rm CONTAINER_ID_QUE_VOCÊ_ACHOU_NO_COMANDO_ANTERIOR

Servidor embutido

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

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

PHP__Built-in_web_server_-_Manual

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

$ php -S localhost:8899

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

Considerações finais

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

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

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

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

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Vagrant e seus plugins

E lá vamos nós falar de Vagrant!

vagrant-e-seus-plugins

Resumo da história dos plugins no Vagrant

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

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

Como instalar plugins no Vagrant

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

Exemplo para instalar o vagrant-aws:

$ vagrant plugin install vagrant-aws.

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

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

Plugins Vagrant que não podem faltar para mim

Bindler

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

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

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

Vagrant Cachier

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

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

Vagrant HostManager

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

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

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

Considerações finais

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

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

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

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

Olá, pessoal,

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

  

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

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

Phing???

Logo Phing

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

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

Composer

Composer logo

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

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

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

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

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

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

Estrututura de pastas e arquivos

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

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

phpunit.xml.dist

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

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

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

PHP CodeSniffer

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

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

Outras ferramentas

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

README

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

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

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

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

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

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

Travis

Logo do Travis

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

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

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

Scrutinizer

Logo do scrutinizer

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

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

Travis
Scrutinizer – Quality
Scrutinizer – Coverage

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

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

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

Até mais!

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

E o site do PHPSP voltou!

Olá, pessoal,

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

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

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

Eventos, encontros, artigos novos, tudo beleza!

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

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

Este artigo foi publicado originalmente em RogerioPradoJ.com.

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.