RSS Feed
  1. 10 Resoluções de Ano Novo Que Todo Desenvolvedor Web Deveria Fazer

    dezembro 29, 2011 by admin

    Tradução livre de 10 New Year’s Resolutions Every Web Developer Should Make, do NetTuts+.

    Em menos de uma semana já será 2012. Sei que isso é um clichê, mas como o ano passou tão rápido assim? Naturalmente estamos agora naquele momento do ano quando as pessoas definem metas para o novo ano. Embora você deva ter algumas metas para sua vida “real”, que tal algumas resoluções para a sua vida de desenvolvedor?

    1. Aprender uma Nova Linguagem, um Novo Framework ou uma Nova Metodologia

    A única constante no desenvolvimento web é a mudança. Veja o NodeJS, por exemplo: dois ou três anos atrás ele não existia, e havia muito pouco (se existisse) de coisas sendo feitas com JavaScript no lado servidor. Agora, você não  pode se distanciar disso. Todo desenvolvedor web quer estar na crista da onda. E para fazer isso, precisamos continuar aprendendo sobre as últimas tecnologias. Se você for um desenvolvedor backend, significa aprender sobre JavaScript e Node.js. Um pouco menos de Ruby e Rails. Para o desenvolvedor frontend, significa aprender sobre CSS3 ou entender as novas APIs do HTML5. É claro que não significa que você tenha que usá-los regularmente, apenas se mantenha aprendendo.

    Na mesma linha, agora é melhor do que nunca para reavaliar seu fluxo de trabalho e aprender melhores e diferentes ferramentas para fazer seu trabalho mais rapidamente.

    2. Ficar melhor ainda no que você já conhece

    É claro, se manter afiado significa mais do que aprender coisas novas. É também melhorar o uso das suas ferramentas diárias. Me culpo por tentar usar apenas os padrões que já conheço, mas não aprender algo novo pode ser o melhor em determinadas situações. Quão grande está o seu conhecimento dos padrões de projeto do JavaScript? Você tem uma compreensão sólida de orientação a objetos e programação funcional no PHP? Você já usou joins no SQL? Tem alguma função no seu editor de texto que você ainda não usa? Essas coisas não são novas tecnologias, mas, se você ainda não as utiliza, são conceitos novos para você! Reserve algum tempo para se focar também nas linguagens e softwares já existentes.

    3. Explorar uma nova área

    Essa resolução é uma interpretação diferente da primeira. Aprender uma nova linguagem, framework ou metodologia na sua área é excelente, e deve ser útil no seu dia a dia. Mas, se você for como eu, deve estar fascinado com todos os cantos da web. Tente explorar novas áreas. Desenvolvedores backend: investiguem o desenvolvimento frontend. Frontends, explorem mais do que você já explorou sobre “usabilidade” ou “experiência de usuário”. Se você gostar de escrever, pode se interessar em “estratégia de conteúdo” ou design. Existem dezenas de áreas diferentes dentro da web; explore-as!

    4. Envolver-se com a Comunidade

    A web é um lugar incrível: eu não consigo pensar em nenhum outro fenômeno em nenhum período que tenha conseguido criar amizades tão fortes entre pessoas que estão tão distantes. Em 2012, por que você não tenta se envolver com esse grupo de pessoas surpreendentes um pouco mais? Fale com eles no Twitter; leia seus artigos nos blogs e faça comentários ou então escreva seus próprios artigos em resposta; faça contribuições para os códigos deles no Github ou outro site parecido. Ou ainda, participe de encontros, grupos de usuários e conferências. Chame isso de envolvimento, networking ou chame do que você quiser; mas uma coisa é certa: isso irá (na maioria das vezes) beneficiar você e as outras pessoas. Além de construir grandes relações pessoais, é provável que você ganhe novas referências.

    5. Ensinar os Outros

    Andando lado a lado com o tópico anterior, você deveria resolver ensinar mais os outros em 2012. Por que? Bem, como dizem por aí: “Ensinar algo é o melhor de jeito de aprender sobre isso”. Estou escrevendo para o Nettuts+ há quase 3 anos, e posso confirmar que essa frase é completamente verdadeira. Escrever exatamente como um conceito funciona te força a entendê-lo completamente; você vai se surpreender com o quanto você irá aprender sobre um tema quando você tentar ensiná-lo. Além disso, a incrível sensação que você tem quando você sabe que ajudou alguém a aprender um novo conjunto de habilidades.

    Sem dúvida, você vai encontrar alguns “trolls”, te apontando erros legítimos (ou apenas fazendo comentários ofensivos). Não se preocupe (muito); ensinar é um aprendizado, e você irá melhorar quanto mais você fizer. Os comentários mais benéficos são aqueles que ferem seus sentimentos.

    6. Tomar Conta de Você Mesmo Melhor

    Desenvolvedores web parecemos nos orgulhar de nossa dedicação à nossa profissão. Trabalhamos por muitas horas, debruçados sobre um computador no escuro, tão absortos no nosso trabalho que esquecemos até de tomar banho ou comer. Nós somos os mártires da web, sofrendo para fazer a internet um lugar melhor.

    Soa heróico, mas na verdade não é.

    Com o risco de parecer que estou “mimando” você, vou sugerir que tome conta de você mesmo em 2012. Além de dormir e comer bem, garanta que seu local de trabalho seja ergonômico. É razoável que, se você gasta um terço de sua vida no escritório, faz sentido deixá-lo o mais confortável possível.

    7. Gerenciar Melhor O Seu Tempo (e Outros Recursos)

    Talvez isso não seja relacionado especificamente com desenvolvedores web, mas mesmo assim, é algo que quase todo “profissional do conhecimento” tem que melhorar. Para muitos de nós – especialmente os freelancers – o que fazemos com nosso tempo pode ser a diferença entre um ter banquete ou ficar de jejum. Lembra de toda a diversão das novas tecnologias web que recomendei que você aprendesse sobre? Bem, não deixe que aquela sedução diminua suas horas no que faz você realmente ganhar dinheiro. É claro, a internet em geral pode ser vista como uma distração. Tenho certeza que você leu isso recentemente; eu fiquei impressionado quando vi:

    “@jeresig: Over 1 trillion videos were watched on Youtube this past year. That’s 550 videos per person with internet access. Insane.”

    Assumindo que a média da duração de um vídeo no Youtube é de 2 a 3 minutos, estamos olhando para algo da ordem de um dia inteiro. Algo me diz que não estou muito melhor que isso.

    É claro, “só trabalho, nenhuma diversão” e tudo mais, certo? Não estou dizendo para que você seja um escravo dos seus clientes ou um chato e insuportável viciado em trabalho. Estou simplesmente dizendo que devemos ser sábios  para rastrear exatamente onde nossas horas estão indo e nos esforçar para usá-las um pouco melhor.

    8. Usar Práticas de Programação Melhores

    Não, eu não estou repetindo a resolução número dois em outras palavras. Agora, estou falando sobre as práticas relacionadas diretamente ao código. Eu não consigo lembrar quando vezes iniciei ansioso um projeto novo, e meia hora depois disse: “Xi…, deveria ter criado um branch para essa funcionalidade. Oh, pior ainda, esqueci de iniciar um repositório Git quando comecei…” Garantir que eu use versionamento de código desde de o início é algo que vou trabalhar  em 2012, pois isso mantém o histórico dos projetos muito mais limpo.

    Outra prática de meta-codificação que geralmente neglicencio (prejudicando eu mesmo) é comentar. Eu escrevo uma poucas linhas espertas de código, e fico feliz pelo resto do dia. Na próxima semana, vou voltar ali e gastar vinte minutos só para tentar descobrir o que aquele trecho faz. Isso também assola você? Faça um favor para você mesmo e deixe comentários úteis para você e para os outros. Documentar anda lado a lado com comentar. Quando eu estava aprendendo Dojo recentemente achei valiosa a documentação dele que vem embutida no código. É claro, o nível de documentação dependerá da publicidade do seu projeto, mas documentação demais nunca será um problema para você.

    9. Gerar Rendimento Passivo

    Estou chutando que a maioria do público do Nettuts+ faz trabalhos para clientes, seja como freelancer ou de outra forma. Então porque não ter alguma renda passiva paralelamente? A Envato tem dez lojas online onde qualquer pessoa com as habilidades certas pode lucrar. Crie um tema para o Themeforest, escreva um script para o CodeCanyon, as possibilidades são quase infinitas. É claro, se seus habilidades não se encaixam nas lojas da Envato – ou mesmo que elas se encaixem – existem um monte de outras maneiras de gerar rendimento passivo. Se você for um escritor, por exemplo, de uma olhada no Tuts+ Premium. Eles estão sempre procurando por novos professores apaixonados.

    Vender coisas numa loja online ou em um site pessoal é uma maneira brilhante de conseguir algum dinheiro extra passivamente ao mesmo tempo que você continua fazendo o que você gosta.

    10. Dar Uma Relaxada

    Até agora, todas as resoluções foram coisas que te fariam melhorar seu habilidade como desenvolvedor. Vou finalizar dizendo que uma das melhores coisas que você pode fazer para se tornar um desenvolvedor melhor é não ser um desenvolvedor… às vezes. Coloque um chapéu completamente diferente… às vezes. Mantenha outro passatempo que não seja relacionado com desenvolvimento, e, preferencialmente, um que não involva computadores. Alguns tocam instrumentos, alguns lêem, alguns escrevem, alguns cozinham. Não importa o que você faça, reserve algum tempo livre para isso. Quando você fizer isso, vai descobrir que soluções para problemas de programação surgem frequentemente durante esse tempo livre.

    Certamente, paradas regulares são importantes, mas as mais longas também são, como algumas semanas por ano de férias e as festas de fim de ano. Ponha algumas dessas paradas na seu planejamento anual também.

    Suas resoluções?

    Bem, essa é minha lista das dez resoluções que todo desenvolvedor web deveria fazer. Você tem alguma que não está na minha lista? Vamos ouvir nos comentários!


  2. FRAPI – Web APIs de forma fácil no PHP

    dezembro 9, 2011 by rogeriopradoj

    A inspiração para esse artigo veio a partir do Felipe Marques.

    Estive na PHP Conference Brasil 2011 (aqui e aqui), e uma boa parte das trilhas falava sobre serviços.

    Rest, restfull, webapis, orientação a serviços… as opções de palestras eram muitas.

    De todas a que mais me chamou a atenção foi a RESTFUL webservices com FRAPI do Alex Piaz.

    Informações sobre o Frapi você pode pegar aqui e aqui.

    Ele precisa que você configure vhost para funcionar seguindo o manual, mas caso você tenha algum impedimento para fazer isso (como eu tenho no escritório, por não usar Apache e a versão do meu webserver não permitir configuração de vhost), subi no Github um repositório com um versão configurada para usar subdiretórios.

    Logo Github

    Acesse lá.

     


  3. PHP nos Podcasts – “É nóis no iPod”

    novembro 30, 2011 by rogeriopradoj

    Olá pessoal,

    É legal ver que a comunidade PHP aqui no Brasil está em alta, com alguns integrantes ativos fazendo boas participações em Podcasts de tecnologia.

    Foi uma surpresa ver o Rafael Dohms ser recebido no Grok Podcast, principalmente depois de seus donos, que são rubystas meio fanáticos, baterem tanto na linguagem PHP em episódios anteriores.

    Mais uma surpresa foi ver o Er Galvão Abbott no DatabaseCast, nesse caso mais porque esse é um podcast focado em banco de dados.

    É bom lembrar que comunidade PHP nacional já tem alguns podcasts focados como o PHPSPCast, o PHPFiveMinutes, getOnCode().

    Mas é interessante ver que o assunto também é abordado fora deles, além do mais sendo em podcasts de bastante qualidade e com boa periodicidade.

    Se você ainda não assina esses feeds no seu iTunes ou no seu agregador de podcasts preferido, não sabe o que está perdendo. Dê uma conferida.

    Até mais.


  4. Sou PHPSP e Contribuo com projetos Open Source

    novembro 30, 2011 by rogeriopradoj

    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!


  5. Uma Nota Sobre as Mensagens do Git Commit

    novembro 29, 2011 by rogeriopradoj

    Atualizado em 30/11/2011.

    Tradução livre de A Note About Git Commit Messages do tbaggery.

    Esse é um texto sobre como fazer um boa mensagem para os commits que você faz no GIT.  Dedico ao Téo.

    Aqui vai um link que complementa o que está colocado abaixo: https://github.com/erlang/otp/wiki/Writing-good-commit-messages.

    ———————-

    Vou tomar um tempo aqui refletir sobre o que faz uma mensagem de um commit ser considerada bem feita. A boa prática que define como montar essas é um dos pequenos detalhes que tornam o Git excelente. É compreensível que alguns dos primeiros commits no repositório do rails tenha mensagens do tipo “linha gigante!!!”, vou dizer aqui por que aqui porque aquela era uma prática ruim.

    (mais…)


  6. 20 maneiras de salvar filhotes e aprender PHP – parte 2

    novembro 20, 2011 by rogeriopradoj

    Continuando a tradução livre do 20 Ways to Save Kittens and Learn PHP do NetTuts+, disponível aqui.

    3. Não deixe as boas práticas para depois!

    A medida que você vai aprendendo irá ouvir bastante sobre boas práticas de programação: coisas como prepared statements e os padrões de codificação da PEAR.

    Não deixe para depois o aprendizado desses assuntos só porque eles parecem ser difíceis.

    “Se algo é uma boa prática não é porque nós (ou seja, outros desenvolvedores PHP) nos reunimos e dissemos: “Como podemos tornar mais difícil a vida dos iniciantes”" .

    As boas práticas existem para manter seus programas seguros, rápidos e gerenciáveis. Aprenda sobre eles o mais rápido que você puder. Na verdade, nem sequer aprenda o jeito errado.

    Você vai gastar o mesmo tempo para aprender sobre a mysql_query() ou para aprender PDO e MySQLi. Sendo assim escolher começar aprendendo os dois últimos fará com que inicie com uma base sólida nas interações com bancos de dados e na verdade gastado menos tempo e esforço.

    Não se esqueça de navegar no Nettuts+ (e porque não no rogeriopradoj.com) para acessar uma variedade de tutoriais sobre boas práticas em PHP, incluindo o uso de prepared statements.

    4. Não deixe as boas práticas para depois!

    Só para ter certeza que você tinha visto essa dica.

    “Falando sério. Não tente usar atalhos. Toda vez que você viola uma boa prática só porque o jeito certo parece “muito difícil” a Petrobrás mergulha um filhote no petróleo.”

    Então se você não quiser fazer isso por si mesmo, pelos seus projetos, pelos seus colegas ou pelo progresso da comunidade como um todo, pelo menos pense nos filhotes.

    5. Faça códigos auto-documentados

    No início é tentador tentar ser “inteligente” com os nomes das suas variáveis e funções. Talvez você tenha lido um artigo sobre performance ou visto em algum lugar um trecho de código que fazia um monte de trabalho em duas linhas. Pode ser que você queria criar o seu estilo próprio de programar. Ou talvez você só tenha ouvido falar que eu odeio isso e você quer me irritar.

    Não importa qual é o motivo dessa tentação, resista a ela a todo custo.

    De uma olhada nesse trecho de código:

    <?php
    
     $a = b('jason.lengstorf@copterlabs.com');
    
     $c = explode('@', $a);
    
     $d = $c[1];
    
     echo 'The email address ', $a, ' belongs to the domain ', $d, '.';
    
     function b($e) { return htmlentities($e, ENT_QUOTES); }
    
    ?>

    Ele faz sentido para você?

    É claro que você pode descobrir o que ele faz, mas por que forçar alguém que está tentando trabalhar em cima do seu código a perder alguns minutos coçando a cabeça tentando lembrar o que a variável $c está guardando.

    Vamos então pegar aquele código e deixá-lo mais auto-documentado:

    <?php
    
     $email = sanitize_string('jason.lengstorf@copterlabs.com');
    
     $email_pieces = explode('@', $email);
    
     $domain = $email_pieces[1];
    
     echo 'The email address ', $email, ' belongs to the domain ', $domain, '.';
    
     function sanitize_string($string) { return htmlentities($string, ENT_QUOTES); }
    
    ?>

    Pronto. Muito melhor. Agora apenas olhando para o código dá para ter uma ideia geral do que está acontecendo. Sem coçadas de cabeça, sem xingar ninguém em voz baixa e, o mais importante, sem nenhuma diferença real na funcionalidade.

    É lógico que você teria economizado alguns bytes com nomes de variáveis menores. Mas, honestamente, se você precisar espremer alguns caracteres dos nomes de suas variáveis para ganhar 0.2ms no tempo de execução do seu programa, provavelmente tem algum problema diferente rolando aí.

    Continua…

    Parte 1

    Parte 2


  7. 20 maneiras de salvar filhotes e aprender PHP

    novembro 15, 2011 by rogeriopradoj

    Tradução livre do 20 Ways to Save Kittens and Learn PHP do NetTuts+, disponível aqui.

    Existe um antigo provérbio, originado por volta de 1700, que diz que: “Um filhote morre cada vez que um programador PHP não segue as boas práticas”. Ok, não realmente, vamos apenas seguir adiante.

    Começar a usar o PHP pode ser uma experiência assustadora. Tendo isso em mente, essas 20 dicas vão ensiná-lo a seguir as boas práticas e salvar vidas… vidas de filhotes.

    0. Programe tão frequentemente quanto puder

    Você já estudou alguma língua estrangeira na escola? Estudou todas as partes do discurso, aprendeu os verbos e como conjugá-los, acompanhou como o professor dizia expressões comuns?

    Quanto dela você ainda consegue falar?

    Se sua resposta for, “nada”, posso apostar que é por causa de você nunca ter usado de verdade a língua – você só a estudou. No entanto se você ainda consegue manter uma conversa, isso se deve a você realmente gastar algum tempo falando aquela língua fora do ambiente de aprendizagem. Talvez você passou um ano no exterior ou trabalhou num emprego onde uma segunda língua era necessária?

    Seja qual for  o motivo, você a manteve porque a usou em situações da vida real e colocou ela num contexto pessoal que é muito mais fácil de lembrar depois.

    “O PHP é uma língua estrangeira, assim como o espanhol ou o francês. Para que você se torne confortável com ele, você precisa utilizá-lo fora da sala de aula. Tutoriais e e projetos de exemplo são ótimos para aprender os fundamentos mas a menos que você aplique esses conceitos em seus próprios projetos, será muito mais difícil de aplicar esses fundamentos num contexto e gravá-los na sua memória.”

    Então, não se preocupe em “não saber o suficiente” para desenvolver um projeto. Quando você escolhe seu projeto, tem uma razão válida para pesquisar um conceito e implementá-lo. Programar frequentemente e com um propósito fará com que as lições que você aprende se fixem.

    1. Familiarize-se com o manual do PHP

    Toda lista de dicas para iniciantes contém essa daqui, e é por uma boa razão.

    “Aprender como navegar na documentação do PHP é a coisa mais simples e útil que você pode fazer para si mesmo como programador.”

    Se você olhar no histórico do meu navegador os sites que eu mais visito, o manual do PHP vai estar lá no topo. Não acho que isso deve mudar enquanto o PHP se mantiver minha escolha como linguagem de programação.

    Primeiro, o manual parece um pouco assustador – ele não parece ser fácil de pesquisar e a navegação nele às vezes pode ser um pouco estranha. No entanto, você pega o jeito rapidamente.

    Talvez a melhor coisa para a saber sobre o manual do PHP é que a maioria das funções pode ser consultada usando o padrão http://php.net/nome-da-função na barra de endereços. Por exemplo, para consultar a função strpos() use http://php.net/strpos e para array_key_exists(), use http://php.net/array-key-exists. (NOTA: preste atenção na omissão dos parênteses e na substituição na barra de endereços dos sublinhados (_) por hífens (-).

    1a. Leia os comentários!

    É fácil ignorar os comentários, mas faça um favor a si mesmo e de uma olhada neles. Se você está recebendo um resultado inesperado em uma função é provável que alguém já tenha visto algo parecido e explicado sobre nos comentários.

    2. Aproveite-se da imensa comunidade online do PHP

    Além do manual do PHP, existem comunidades excelentes de desenvolvedores em toda a internet. Algumas das minhas favoritas são os os fóruns StackOverflow.com e W3Schools.com.

    Adicionalmente, o Twitter é um lugar surpreendentemente bom para postar suas dúvidas de PHP. Se você tuitar com uma hashtag #PHP, provalmente alguém da comunidade vai vê-la e te dar uma mão.

    Uma Nota Sobre o Twitter: É claro, tudo que é útil inevitavelmente é tomado por spammers e por aqueles tristes indivíduos que não entendem profundamente o sentido das mídias sociais. Se estiver usando o Twitter como uma rede de suporte, provavelmente irá bloquear ou ocultar de forma rotineira as contas que vomitam anúncios de emprego ou aquelas que retuítam tudo que menciona o PHP.

    “Lembre-se: a medida que você melhora, por favor passe isso para frente. A comunidade de desenvolvedores precisa que todo mundo arregace as mangas, e não levará muito tempo até que você seja capaz de responder perguntas de outros iniciantes. Não se torne um surdo.”

    Continua…

    Parte 1

    Parte 2

     


  8. PHP Conference Brasil 2011

    novembro 10, 2011 by rogeriopradoj

    Esse ano em dezembro, dias 01, 02, 03 e 04, rolará a PHP Conference Brasil 2011, novamente organizado pela Tempo Real Eventos (do gente boa Anderson).

    Em 2010 eu fui, recomendo que você vá para conhecer novas tendências, profissionais do país inteiro, fazer networking e tudo o mais de uma conferência.

    Esse ano devo marcar presença de novo, então, nos vemos lá.

    PHP Conference Brasil

    Clique na imagem para acessar o hotsite.

     logo Rogeriopradoj.com


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

    novembro 9, 2011 by rogeriopradoj

    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

     


  10. Como conectar em servidor por SSH sem informar senha

    outubro 19, 2011 by rogeriopradoj

    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