Arquivo da tag: github

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.

Migração do SVN para GIT em Windows no escritório

Olá, pessoal.

Estava devendo uma nova abordagem sobre versionamento aqui, depois de começar o assunto nesse post anterior.

Agora vou mostrar como fiz para implementar a utilização do GIT lá no escritório.

Motivação

Já venho estudando a utilização do GIT faz tempo, desde meados de 2010. Mas ainda não havia me sentido a vontade para começar a implementar nos projetos do escritório que são compartilhados com a equipe.

Mas em casa, nos projetos particulares, e em alguns que não eram utilizados por mais ninguém, comecei a fazer os “git inits”.

Após a ideia da criação do meu domínio na internet (Blog e Empresa), apostei que o desenvolvimento de web apps com a disponibilização de seus código-fonte seria uma ótima forma de treinar a utilização do GIT, e foi mesmo.

No entanto, o que me fez tomar a iniciativa de migrar totalmente nossos repositórios no escritório para GIT foram os constantes problemas no computador que servia para armazenar nossos repositórios SVN.

A cada momento que ele precisava ser levada para manutenção aconteciam esses problemas:

- os colegas paravam de colaborar de forma estruturada: pois o servidor central estava indisponível, não se permitia commits nem updates

- perdia-se o histórico de versionamento do código novo, pois eles começavam a trocar arquivos de um lado para outro (como fazíamos antes de implantar o SVN), sem nenhum método

- eu gastava um tempo muito grande migrando o diretório de repositórios para um novo lugar, e tendo que ensinar o pessoal, mais uma vez, a fazer o svn relocate nas suas cópias locais, além de fazer o mesmo em todos os diretórios de produção manualmente (eu sei, deveria usar alguma ferramenta de deploy, build, integração contínua etc., deixem sugestões nos comentários).

git logo 2

Fonte: http://git-scm.com/

Outro problema constante que faziam o SVN ser uma opção inferior eram:

- tempo de resposta horrível na rede para tudo!!! Isso mesmo, tudo que tínhamos que fazer no SVN depende da rede, e nossa rede do escritório não é uma maravilha. Todo commit, update, log e qualquer outro comando. Era coisa de você literalmente apertar o botão, ir pegar o cafezinho e voltar depois.

E nessa última manutenção, segunda seguida em menos de uma semana, decidi que era gota d’água: mandei um e-mail para todo mundo e “vendi o peixe” do GIT.

Como migrar contando com a resistência natural das pessoas

teimoso

Lembram desse?!?

Lembro como foi para implementar o SVN: além de ter que conhecer o conceito e as ferramentas, o mais importante que é convencer todo mundo a usar com você. Faz bem pouco tempo que o último dos colegas instalou a ferramenta para acessar os repositórios. Muitas aplicações legadas que estão em produção estão sequer versionadas (principalmente aqueles códigos VBA que nunca vi os códigos-fonte).

Mesmo assim, depois de bastante tempo o SVN virou padrão e se tornou um dos nossos pilares para desenvolver nossas aplicações no escritório, aqui em São Paulo. Foi até uma vitória quando consegui implantar ele num projeto que participei na matriz, em Brasília, com um pessoal que foi desde o começo super-resistente a novas ferramentas (torço que ainda esteja funcionando com controle de versões).

Percebi que com o tempo, com você e a equipe tendo mais prática, fica mais simples de mostrar os pontos chave do conceito, e é mais fácil de mostrar que aquilo que propôs é uma boa opção.

E foi dessa forma que consegui converser o pessoal a tentar a migração do SVN. Esse foi um resumo dos argumentos que usei para a utilização do GIT:

- Conceito já maduro, com bastante material para consulta

- Ferramentas com interface gráfica para gerenciar os repositórios (TortoiseGit, o pessoal já usava o TortoiseSvn)

- Os comandos são muito mais rápidos, pois não precisam de acessar a rede nem o repositório central.

- Estou aqui para ajudar!!!

Esse de ajudar o que eu fiz:

- Consegui um monte de material para o pessoal (depois vou colocar os links aqui, mas tinha help do github, bitbucket, etc.). Com o SVN, mas só com o livro oficial

- Baixei os dois programas básicos para eles começarem a utilizar (msysgit e TortoiseGit). No SVN era só o TortoiseSvn

 

logo msysgitlogo tortoise gitlogo msysgitlogo tortoise git

- Acompanhei-os na instalação, mostrei exemplos rápidos de git clone, git init, git push, git pull (lógico que tudo pela interface gráfica do TortoiseGit).

Acho que de tudo a coisa que mais impressionou os colegas foi a rapidez do git. Para mostrar quão rápido ele é (gostei de frisar que muito mais rápido que o Windows), foi numa operação de copiar um diretório versionado na rede para o computador deles. Peguei uma aplicação que montada em cima do Codeigniter, que mesmo não sendo pesada em MBs, tem muitos arquivos, e para transferir isso na nossa rede é uma dureza. Na primeira tentativa mostrei fazendo a “cópia” usando o git clone. E na segunda usei o Windows Explorer, copia cola mesmo. Posso dizer que não deu nem pro cheiro: o git foi muitas vezes mais rápido (não cronometrei mas tenho testemunhas, certo Nelson?).

Futuro

Agora é fazer com que a equipe continue utilizando o GIT nos projetos.

Continuar estudando, aprender melhor todos os conceitos envolvidos (sei que tem um monte) deve fazer essa transição e utilização ser mais tranquila, espero pelo menos do que foi no começo com o SVN.

Acho que a migração de vários projetos de código aberto que utilizamos estarem sendo migrados para GIT, e principalmente para o GitHub deve ser um incentivo ainda maior para continuar mantendo o pessoal focado.

Quem sabe não é até uma forma de ajudar a fazer da equipe uma contribuidora no mundo do software livre, hein?

Até mais.

P.S.0: Estou lendo um livro sobre GIT que estou achando muito bom, dá todos os fundamentos: ProGitPDF, EPUB, MOBI (gratuitos) ou Amazon (pago).

capa do livro Pro Git

P.S.1: Visitem minha conta no GitHub, tem alguns repositórios lá que eu criei e outros forkados

octocat

Fonte: http://octodex.github.com/plumber/

P.S.2: Minha empresa (Pradoj.com), meus apps (Jana, Tati e Cppc).

logo Pradoj.com

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Como conectar em servidor por SSH sem informar senha

Este post é para mostrar como conectar num host por ssh sem pedir senha, utilizando para isso a configuração do .ssh/authorized_keys.

SSH

Fonte: http://www.throughput.biz

Primeiro você precisa localizar sua chave ssh pública no seu guest (seu computador que irá acessar o servidor), nos sistemas *NIX ela geralmente está no caminho: ~/.ssh/id_rsa.pub.

Se você não tiver essa chave criada, ou quiser criar uma nova, pode seguir o passo-a-passo do pessoal do Github de acordo com seu sistema operacional (Windows, Linux ou Mac).

 Em seguida, abra esse arquivo da chave pública num editor de texto e copie o conteúdo para a área de transferência.

Fonte: http://www.iconarchive.com/

Fonte: http://certcollection.org/

Após isso, abra o terminal, e conecte por ssh no seu host remoto. Lá acesse a pasta onde estão seus arquivos ssh, geralmente o caminho é ~/.ssh/:

$ cd ~/.ssh/

Faça uma listagem dos arquivos, e confirme se já existe um arquivo chamado authorized_keys. Se não existir ainda, crie-o.

Após isso, abra esse arquivo authorized_keys num editor de texto (eu usei para isso o nano na linha de comando), e cole o que você tinha copiado alguns passos atrás na última linha desse arquivo.

Fonte: http://www.egginfo.org/

Salve o arquivo e está pronto. Dessa forma, sua chave pública estará autorizada para acessar o seu servidor sem precisar digitar a senha novamente.

Fontes:

http://help.github.com/mac-set-up-git/

http://blogs.oracle.com/jkini/entry/how_to_scp_scp_and

http://linuxproblem.org/art_9.html

Este artigo foi publicado originalmente em RogerioPradoJ.com.