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

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.

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.

Uma Nota Sobre as Mensagens do Git Commit

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.

Continue lendo

20 maneiras de salvar filhotes e aprender PHP – parte 2

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

Este artigo foi publicado originalmente em RogerioPradoJ.com.

20 maneiras de salvar filhotes e aprender PHP

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

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

PHP Conference Brasil 2011

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

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.