KISS - Keep it simple, stupid!

Deploy é sempre um problema sério. Estamos sempre buscando soluções que minimizem o trabalho manual na hora de subir os arquivos para o servidor e deixá-los prontos para produção.

Em um projeto que temos, utilizamos o próprio Git para fazer esta tarefa, afinal o repositório central já fica lá no servidor mesmo, nada mais óbvio.

Então sempre que temos uma versão que está estável para produção, nos logamos por ssh e mandamos um git pull no diretório onde fica o site. Geralmente o merge ocorre sem problemas e fica tudo atualizado. Mas o problema é que os arquivos de configuração sempre são substituidos, e toda vez o trabalho de consertar as configurações de banco, colocar o debug pra 0, entre outras coisinhas (que sempre passam desapercebidas) é feito à mão.

Hoje, depois de fazer isso pelo menos umas 3 vezes, me lembrei que o Git tem um comando que poderia servir perfeitamente pra evitar toda essa edição manual na hora do deploy. É o git stash.

Agora, antes de executar o git pull, eu digito git stash save “Salvando configurações de produção”; com isso o git guarda os arquivos modificados em um local “invisível”, e executa um git reset –hard, que retorna todos os arquivos à versão HEAD. Aí o diretório fica limpo para receber o merge sem problemas.

Depois que o git pull for completo, é só digitar git stash apply que ele retorna todas as mudanças que você tinha guardado, e sua aplicação está pronta pra receber visitas.

Update: eu não havia dito pois não tinha certeza, mas acabei de verificar que o git stash apply não simplesmente recupera o arquivo “stashado”, mas aplica somente as mudanças que você havia guardado, preservando o que mudar com o git pull. Nice!

Sempre tive dificuldade de utilizar o GitHub aqui na faculdade, infelizmente aqui tem um proxy filho da pu.. que, além de bloquear alguns sites “legais”, desabilita quase todos os protocolos que não sejam HTTP, HTTPS e FTP. E adivinha? Nada de GitHub pro papai aqui.

Bem, meu problema acabou! Buscando algumas informações sobre como utilizar GitHub dentro de proxy, encontrei este artigo do tycho. O método dele é simples, ele utiliza uma facilidade do GIT que permite você indique um comando para tunelar o protocolo git://, que geralmente é trafegado pela porta 9418 (by thyco), isto dá a possibilidade de utilizar algum programa ‘burlador’ de proxys, como Your Freedom, para transitar suas requisições GIT.

O procedimento é um pouco complexo (pelo menos para mim, acho que foi a primeira vez que dei um make sozinho) e eu não faço a mínima idéia de como realizar isto no Windows, mesmo assim tentarei explicar. Faça o download do repositório tycho/connect (não dê ‘git clone’ pois, se está lendo este artigo, você não pode dar um ‘git clone’). Descompacte os arquivos numa pasta e dê um make dentro do diretório. Isto criará um comando chamando ‘connect‘, você pode colocar esse comando em alguma pasta que esteja referenciado no seu PATH ou deixá-lo onde quiser para acessá-lo diretamente.

A segunda parte é a configuração do GIT. Edite o arquivo gitproxy que veio junto com o repositório do thyco e certifique-se que o comando connect será executado em qualquer lugar. O que isto quer dizer? Se você colocou no PATH, você não faça nada, se você quis acessar diretamente, coloque o caminho completo do connect. Agora, você deve indicar qual o comando o GIT deve utilizar para tunelar o protocolo git://, veja abaixo como proceder:

git config --global core.gitproxy PATH/gitproxy

Novamente temos a situação onde podemos colocar o comando gitproxy em algum PATH ou indicá-lo diretamente, vocês já devem estar entendendo =D. O –global é opcional, mas acho que todos deixarão para não ter que configurar cada repositório manualmente, certo?. Bem, por último coloque o YourFreedom para rodar, certifique-se que o SOCK está rodando na porta 1080 (se não tiver, modifique o gitproxy) e voy lá, agora você pode mandar o proxy catar coquinho!

Sem dúvidas isto foi um life-changer para mim, fazia tempo que estava tendo problemas com este proxy. Acredito que esta dica ajudará muita gente, pois tenho certeza que aqui na empresa irá beneficiar uns 5!

Acredito que estou completando mais de 1 ano e meio de desenvolvimento com CakePHP e neste período quebrei muito a cabeça, entreguei vários projetos e, com certeza, aprendi bastante. Por isso, queria compartilhar com vocês algumas práticas que aprendi que me permitiram chegar ao conhecimento que cheguei. Por enquanto colocarei “somente” 13 práticas e não me aprofundarei em cada tópico, em outros posts explicarei mais cada prática.

1 º – Linux

As práticas não estão em ordem de importância, mesmo porque eu não sou um grande fã do Linux. Mas tenho que reconhecer que ele é um grande ambiente de desenvolvimento. Lógico, quando você não sabe mexer com Linux e não está acostumado com linha de comando, tudo será odioso. Mas digo a vocês, mesmo eu sendo um windeiro de carteirinha, minhas habilidades de desenvolvimento melhoraram bastante depois que comecei a usar o Linux. Hoje, não consigo desenvolver uma linha de código no Windows. Recomendo a todos a tentarem ficar um mês programando só no Linux, tenho certeza que não voltarão para o Window. Para aqueles que não sabem utilizar Linux, dou uma dica: tentem pedir para algum amigo linuxzeiro para ser seu tutor, isto economiza muitas horas de procura no Google!

2º – Utilizar VirtualHosts para configurar ambientes de desenvolvimento

VirtualHosts é um recurso do Apache que permite criar vários Hosts em uma única instância do servidor HTTP. A muito tempo quero falar sobre VirtualHost e configuração de ambientes de desenvolvimento para CakePHP, mas sempre deixo pra lá, infelizmente não será neste post que falarei =). Esta prática não muda muito sua rotina de programação, mas pode melhorar em muito sua organização.

3º – Sistema de versionamento, GIT

Bem, sistema de versionamento é crucial para qualquer desenvolvimento com mais de 1 pessoa, mas sinceramente eu recomendaria você versionar mesmo que esteja sozinho. É incrível a capacidade que os SCM (source code management) possui de salvar nossas vidas! Esquecer o que você fez a uma semana atrás, nunca mais! Recentemente conheci o GIT, no começo não entendi muito o conceito dele, mas depois que começamos a utilizar aqui na empresa, vejo o GIT com outros olhos. Este sem dúvida foi um dos meus maiores crescimento como desenvolver nos últimos anos. Com certeza falarei mais sobre ele.

4º – Desenvolvimento orientado a Testes

Já falei sobre TDD em algumas oportunidades aqui no blog e no grupo CakePHP-Tuga, mas nunca será o bastante para falar sobre essa impressionante técnica. Sabe quando você faz um investimento grande que no começo só te trás prejuízo? Aqueles investimentos que você se pergunta se realmente valerá a pena? E no final você recebe muito mais do que tinha previsto? Eu vejo TDD desta forma. TDD é um investimento de longo prazo, que necessita dedicação e comprometimento, mas rende muito mais que simplesmente uma aplicação testada. Eu gosto muito de TDD, ainda não me comprometo nem me dedico o suficiente, mas nas vezes que pratiquei fui muito bem recompensado. Sempre estou tentando falar sobre testes automatizados aqui no blog pois acredito que todos os desenvolvedores deveriam aderir a essa idéia.

5º – Extensões do CakePHP

Utilizar um framework e não aproveitar a organização que ele proporciona é quase uma burrice. No CakePHP temos 5 possibilidades de extensões: Component, Behavior, Helper, DataSource e Plugin, sem contar as classes de Shell. Estas extensões, quando bem utilizadas, permitem você reaproveitar muito seus códigos. Eu costumo falar nas minhas apresentações que Component, Behavior e Helper é o meio que o core team do CakePHP deu aos desenvolvedores para programarmos do jeito “orientado a objeto de ser”. Portanto, utilizem sempre que possível! Recentemente tive um contato maior com Plugins e gostei muito do que eu vi, vou pesquisar mais e tentar falar alguma coisa aqui.

O bom das extensões são as possibilidades de troca de conhecimento. Ser um melhor desenvolvedor também é saber utilizar bons códigos. Além do Bakery, sempre acompanho bastante o movimento dos desenvolvedores CakePHP no GitHub, vocês podem procurar por CakePHP ou mesmo ver alguns dos repositórios e usuários que estou seguindo.

6º – Participar da comunidade

Entrar no grupo de discussão, fazer, comentar ou acompanhar blogs, freqüentar o canal do IRC, publicar extensões, traduzir documentação, reportar bugs,  etc! O importante é participar! Eu, ainda, não faço tudo isto mas faço o possível. Acredito que o contato com pessoas é melhor forma de se melhorar, participar da comunidade é a melhor forma de se manter em contato com as pessoas, portanto, participar da comunidade é a melhor forma de crescer. Tenho certeza que você aprenderá todos os dias participar de metade do que estou dizendo. Eu particularmente tenho inveja da comunidade Rails brasileira, a comunidade Rails é tão importante que determina tendências. Eu participei do RailsSummit e vi isso na pele.

7º – IDE

Eu sei que irei entrar num ponto polêmico mas eu sou um defensor das IDE’s. Eu particularmente acredito que tenho muitos ganhos utilizando IDE. Se sua máquina possibilita utilizar, utilize. Aqui no blog já falei sobre o Komodo, que é minha IDE, até existe uma extensão do CakePHP para ele, vale a pena experimentar.

8º Implantação automatizada

Eu ainda não faço meus deploys automaticamente, mas estou estudando muito sobre. Não existe nada mais chato que enviar site para o servidor… SEMPRE esqueço alguma coisa. Automatizar a implantação é a maneira mais prática e rápida de colocar seus sistemas no ar, sem contar que você poderá criar diversas rotinas de segurança que manualmente seria um “pé no saco”. Para aqueles que querem pesquisar um pouco, recomendo ler sobre Capistrano.

9º Linha de Comando

Para quem é linuxzeiro sabe o que eu estou dizendo. É impressionante a capacidade que tem uma única linha de comando. Quando comecei a utilizar o linux odiava ficar abrando o Bash para poder fazer o que eu queria, agora, eu faço quase tudo com linha de comando. O problema agora que estou tão acostumado que aperto F12 até quando quero ir no banheiro =/.

10º Debug

Eu queria não ter que debugar, mas infelizmente nada é como queremos. Então, ter a prática de debugar é primordial. Em framework debugar é ainda mais interessante, pois são poucos os desenvolvedores que se preocupam em saber “de onde” vem a mágica dos framework. Debugando você pode ver cada pulo que suas requisição dão.  Já expliquei aqui como se faz para debugar aplicações CakePHP com Komodo.

11º Cache

Técnicas de cacheamento são importantíssimas hoje em dia, ainda mais com o efeito Digg a solta.  Eu vi o poder dos caches em um dos meus sites com CakePHP, no caso foi necessário cachear a página inicial, sem isso não conseguia responder nem 1 req/s.

12º Ler código

Sempre é bom ler um código, sempre se aprende uma técnica nova, um algoritmo novo, uma função diferente, etc. Recentemente tenho lido bastante o código do CakePHP e tenho aprendido bastante. Lendo código não fico preso à boa vontade dos programadores para documentar uma determinada funcionalidade, sempre estou a frente das novidades. E ler os testes é ainda mais vantajoso, desafio a todos, antes de perguntar como se utiliza uma determinada função do Cake, dar uma olhada nos testes.

13º Desenvolvimento Ágil

A última mas não menos importante: desenvolvimento ágil. Acho que tudo que falei até agora pode ser resumido em desenvolvimento ágil. Acho que depois que descobri o D.A. minha vida mudou, juro! Melhorei muito como programador e estou sempre melhorando. Mudei até mesmo o meu jeito de pensar. Aqui na empresa utilizamos XP em tudo que podemos, na verdade é a filosofia da empresa. Gostaria que mais pessoas entendessem sobre metodologia ágil.

Bem pessoal, acho que é isso, vou tentar escrever melhor sobre cada assunto desse. Espero que vocês utilizem estas práticas, não que esse seja o melhor caminho, mas acho que pode ajudar. Boa sorte aos programadores e aquele abraço!

Recentemente houve uma discussão no grupo de CakePHP para definirmos um repositório de projetos, extensões e mini-aplicativos do grupo brasileiro. Houve bastante discussão e eu acabei falando um pouco sobre Git e conseqüentemente de GitHub.

Pois bem, estava lendo meus feeds e li a notícia de uma super tradução do Fábio Akita (para falar a verdade, eu recomendo todos a lerem o blog AkitaOnRails!). Recentemente o Scott Chacon lançou um artigo/site (Why Git is Better than X) explicando, de acordo com sua opinião, os pontos positivos do Git perante os outros sistemas de controle de versão. Parabéns e obrigado Fábio Akita!

A versão em português pode ser encontrada em http://pt.whygitisbetterthanx.com/.