Arquivo da tag: symfony

Plugin PHP Coding Standards Fixer (php-cs-fixer) para o PHP-Build

Olá, pessoal!

Depois do plugin do Composer para quem usa o php-build do CHH (já tinha falado dele aqui e aqui), consegui lançar mais um plugin: o Plugin do PHP Coding Standards Fixer (php-cs-fixer). Primeiro vamos contar a história do php-cs-fixer:

Logo do php-cs-fixer

Logo do php-cs-fixer

Criado pelo Fabien Potencier, chefe da Sensio Labs, o php-cs-fixer é uma ferramenta que corrige automaticamente um código fonte para seguir os padrões da PSR2. Ele foi criado com foco na correção automática do código do framework Symfony, do qual é o Fabien é mantenedor; e hoje a ferramenta está liberada com código aberto para a comunidade PHP.

Composer?

Sempre que possível, gosto de utilizar o Composer nos projetos para gerenciar minhas dependências. O php-cs-fixer está listado no Packagist, e pode ser instalado por lá, mas o que fazer nos casos que não vai usar o composer? Aí foi procurar qual a melhor forma de fazer isso: deixar a ferramenta instalada globalmente junto do meu PHP.

No próprio site oficial do php-cs-fixer eles sugerem que a forma de instalação é usando o arquivo PHAR que eles disponibilizam para download, e foi em cima desse arquivo PHAR que o plugin para o php-build foi desenvolvido.

Plugin

O que o php-build faz é o seguinte:

  • logo depois de compilar a versão sua do PHP, ele abre o plugin como um after_install
  • o plugin baixa o php-cs-fixer.phar mais recente
  • esse arquivo é renomeado para php-cs-fixer
  • ele é colocado numa pasta acessível ao PATH definido pelo php-build/phpenv nessa versão que você acabou de compilar
  • e no fim, é dada permissão de execução nesse script php-cs-fixer

Pronto! Agora, sempre que precisar rodar a ferramenta é só executar $ php-cs-fixer com os parâmetros desejados.

Considerações

Para facilitar:

- Github: https://github.com/rogeriopradoj/php-build-plugin-phpcsfixer

- DocumentUp: http://documentup.com/rogeriopradoj/php-build-plugin-phpcsfixer

Fiquem à vontade para tirar dúvidas e dizer o que acharam.

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Sou PHPSP e Contribuo com projetos Open Source

Olá, pessoal.

A coordenação do grupo de usuários PHPSP está com uma ação super bacana, que incentiva todo mundo a contribuir para projetos de código aberto relacionados com a linguagem PHP.

O endereço para acessar o projeto é http://sou.phpsp.org.br/. Eles tem um regulamento a seguir, mas você pode contribuir (e concorrer a prêmios) de muitas formas: tradução, testes, bugs, patch, novos projetos…, dê uma olhada lá.

Não tem mais desculpa para não ajudar a comunidade e devolver um pouco do conhecimento que você recebe dela.

Estou participando

Aproveito para falar de dois projetos onde estou contribuindo, referentes a traduções de documentações:

- Tradução do livro Jobeet do symfony1 para pt_BR, GitHub: esse comecei por mim mesmo, pois acho uma documentação muito interessante sobre como desenvolver uma aplicação web com o uso de um framework. Ele dá todos aqueles toques iniciais relacionados a boas práticas, requisitos, MVC etc. Nesse ponto estou sendo ajudado na revisão pelo Kleber Sato.

- Tradução da documentação oficial do symfony2 para pt_BR, GitHub: esse comecei por causa do desafio especial do PHPSP. A pessoa que está tocando o projeto é a Andreia Bohner, Twitter e GitHub.

Arregace as mangas, e mãos à obra

Vá lá, de uma olhada nas opções de projetos já listados que ajudam bastante se você não tem ideia de por onde começar.

E boa sorte com as premiações!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Versionamento – SVN e GIT

Meu contato com  controle de versões se deu por causa do framework Symfony, e o seu projeto Jobeet, em meados de 2009.

A ideia de “tirar fotos” do seu projeto em dado momento e ter opção de voltar para ele em algum momento se mostrou muito interessante para mim.

Assim eu não precisaria ter medo de implementar uma nova funcionalidade, ou refatorar  o código de forma alguma: sempre teria como “pegar as fotos” e colocar no lugar do que deu errado.

Por causa do Symfony comecei direto pelo Subversion Version Control (SVN), o que lia na época é que era o mais usado, e que tinha deixado o Control Version System (CVS) para trás. Era comum ver alguns blogs falando já sobre o Git, mas parecia algo muito avançado e mais voltado para o pessoal que desenvolvia em Ruby e Ruby On Rails: como meu foco era PHP, não fui procurar mais nada sobre Git.

Versões/releases no versionamento

O que mais achei interessante da divisão básica entre versões (releases) foi o uso que é feito do Trunk, Branches e Tags.

Para não confundir muito, a partir de agora vou chamar apenas de release essas versões de software.

É comum vermos os softwares com a informação de release dessa forma:

  1. v1, v2, v7
  2. v1.0, v1.3, v5.2
  3. v1.0.3, v1.3.29, v5.6.7

No primeiro item vemos o release principal do programa. Ele geralmente é incrementado quando acontece uma alteração muito grande no software, e não apenas de poucas funções. Um exemplo poderia ser a mudança do Windows XP para o Windows Vista (5 para 6 – fonte).

No segundo item vemos o release de segundo nível. Seu incremento ocorre quando acontece um acréscimo de funcionalidade que não cause uma mudança tão drástica. Exemplo ainda no mundo do Windows, Windows Vista para Windows 7 (6.0 para 6.1 – fonte).

No terceiro item, release de terceiro nível, geralmente usado quando é corrigido um bug num release de segundo nível, ou, nos casos das numerações x.x.0 o release inicial. Esse release é o que costuma ser utilizado pelos clientes.

O Trunk seria para manter a versão de desenvolvimento atual, ou seja, não estaria vinculada diretamente a nenhum dos releases de software acima. Sua tradução literal seria tronco, nesse caso tronco principal. Pensando no controlador de versão como uma árvore essa denominação faz todo o sentido.

Os Branches começam a ter uma maior ligação com releases em si. Sua tradução poderia ser galhos ou ramos, dessa forma cada branch/galho ficaria responsável por um release (geralmente de segundo nível). É comum fazer um branch a partir de um release da seguinte forma:

  • Trunk já está com uma versão suficientemente boa, é feita uma cópia para o Branch v1.0 (release 1.0)
  • Desenvolvedores principais continuam commitando no Trunk, caminhando para o release 2.0
  • Uma funcionalidade nova é criada no Trunk, pensando no release 2.0, mas já querem que seja implementado no versão 1 que está rodando, para isso é criado um novo Branch, agora v1.1 (release 1.1).
  • O trunk continua seu caminho.

As Tags tem mais a ver com o que realmente é distribuído de software para o ambiente de produção. Sua tradução literal seria rótulo ou etiqueta, e é realmente isso que é feito a partir do Branch em determinado momento.

Usando o exemplo acima:

  • O Branch v1.0 será disponibilizado para uso, então ele é etiquetado como Tag v1.0.0
  • A equipe de testes achou uma série de bugs no Branch v1.0, que a equipe de desenvolvimento principal já corrigiu no Trunk.
  • Eles copiam essa correção no Branch v1.0, e etiquetam ele como Tag v1.0.1
  • A nova funcionalidade foi criada e eles querem disponibilizar para uso, é criado o Branch v1.1.
  • Logo após esse Branch é etiquetado como Tag v1.1.0.
  • A equipe de testes agora acha um bug no Branch v1.1, a equipe de desenvolvimento já corrigiu no Trunk.
  • É copiada a correção para o Branch v1.1, e etiquetada nesse momento como Tag v1.1.1.
  • Outro bug é achado no Branch v1.1, é copiada a correção do Trunk para esse Branch e é etiquetada como Tag v1.1.2.

SVN

Como na minha empresa o SVN era um software homologado, foi mais fácil também aplica-lo lá, o que facilitou meu aprendizado.

Em vez de ir direto para a linha de comando, preferi utilizar o TortoiseSVN. Ele tem integração com o Windows Explorer e facilita muito o trabalho de criação de repositórios, checkouts, updates e commits.

Minha fonte de informação inicial, depois do Symfony – Jobeet, foi o livro do SVN em inglês, no endereço http://svnbook.red-bean.com/

Depois de muita procurar em blogs em português, consegui a versão do livro em português pt-br, endereço: https://code.google.com/p/svnbook-pt-br/

Quando fiquei mais natural no uso do SVN, arriscando quase nada um pouco na linha de comando e migrando 99% para o Ubuntu Linux, comecei a procurar outras opções que não fossem o Tortoise.

No Ubuntu a primeira ferramenta que achei que fazia um pouco o que o Tortoise oferecia no Windows foi o RapidSVN. Só que ele não tinha integração com o Nautilus Mais tarde meu irmão @royopa me mostrou o RabbitVCS, que já se integrava bem naturalmente com meu gerenciador de arquivos. Posso afirmar: é o TortoiseSVN para Linux.

Como todas essas ferramentas, funcionalidades e entendimento que passei a ter do SVN pensei: acho que agora é hora de aprender algo novo.

Git

Comecei a ver que muitos projetos PHP e outros de meu interesse já estavam passando para o GitHub (CakePHP, Symfony2, jQuery…).

Era tempo de começar a me arriscar nesse mundo também.

Seguindo uma dica de a lista de PHP do Twitter do @rogeriomaxmax consegui o livro http://net.tutsplus.com/freebies/books/getting-good-with-git-free-ebook/

Estou bem no início, mas enquanto vou caminhando, irei postando o que vou conseguindo.

Até mais,

—–

Atualizado em 19/10/2010 as 00h43: Terminei o livro de Git.

Minha página no GitHub é: http://rogeriopradoj.github.com.

Vamos caminhando…

Este artigo foi publicado originalmente em RogerioPradoJ.com.