Ao invés desse marketing todo em cima do software, é melhor explicar aqui os motivos que fazem eu utilizá-lo atualmente.

Git é descentralizado. Sim, isto é uma maravilha ! Sem delongas, permite que eu gerencie meus branches localmente, sem a necessidade daquele role todo para de criar um branch no servidor e depois fazer um checkout dele. Em miúdos, isso dá a agilidade necessária para eu parar o que estou fazendo atualmente para corrigir algum imprevisto, a.k.a, bug, em um branch separado voltando versões se necessário, fazer merge com meu branch principal e subir no servidor de homologação.

Git comunica-se com vários repositórios remotos sem complicações.

Eu, faço uns testes mirabolantes com meus códigos, logo, preciso comitar um mesmo código em servidores diferentes, inclusive em servidor SVN. Ora, isso é bem simples com os “remotes” do Git.

$ git remote add <remote_name> <url_address>
$ git remote show

Para mostrar as informações de um remote específico:

$ git remote show <nome_do_remote>

No SVN, consigo facilmente receber e mandar commits para o servidor.

$ git svn rebase  #para receber do servidor svn os commits que você ainda não possui
$ git svn dcommit #para enviar os commits locais ao servidor

Ou caso queira você criar o merge manualmente das revisões:

$ git svn fetch
$ git merge remotes/git-svn

Isto supondo que você está no branch master, claro.

Git tem um “ponteiro” com índices e mais…

Esse é o nome que dou aos stashes do Git. Quebra um galho imenso e muitas vezes acabo utilizando um stash ao branch. O Stash, salva em um “vetor” as modificações que estão no seu “stage” – em miúdos: arquivos já trackeados pelo Git e arquivos novos no stage - para uma memória temporária.

Seu uso é simples:

$ git stash                       #salva os arquivos modificados dentro do stage.
$ git stash list                  #lista os stashes existentes em memória (Sim, armazena mais de um)
$ git stash pop  <stash name>     #recupera os arquivos do stash e apaga o stash.
$ git stash drop                  #limpa o stash sem recuperar os arquivos
$ git stash branch <name> <stash> #cria um branch <name> com o <stash>

Git tem Ctrl + Z

Claro, afinal este é o propósito de qualquer VCS. Mas no Git a coisa é mais fácil voltar em qualquer ponto após quaisquer ações, digamos, não desejadas.

$ git reflog

Para aplicá-lo, basta pegar o nome que o reflog lhe dirá

$ git checkout <hash>

Pode-se usar também, o git merge, a depender do que quer fazer.

A solução para um problema que eu penei até encontrar uma resposta: como ignorar alterações em arquivos que já estão sob o controle de versão do Git ?

Quer um exemplo ? O databases.yml ; config.yml; … A solução era bem simples:

$ git update-index --assume-unchanged <file> #adiciona o arquivo na lista de índices ignorados
$ git update-index --assume-changed <file>   #volta o arquivo para o índice de arquivos à comitar.

Para fechar, para aqueles que não desejam criar um workspace ao iniciar um repositório Git, deve-se criar um repositório do tipo bare.

$ git init --bare <diretorio>

Isto é útil para você criar o repositório em sua VPS para salvar ou/e compartilhar  seus códigos remotamente.

Annotation @author

Desde que comecei a programar no ínicio do segundo semestre de 2004, eu utilizo desse tal de arroba-aútor. Já vi algumas variantes dela, por exemplo:

Annotation @author Augusta edition

Há ainda aqueles que detalham no cabeçalho sua pog contribuição:

Blablabla no annotation (clique para ampliar - ou não)

Sinceramente eu nunca fui pesquisar se há uma convenção na utilização deste annotation. O fato é que meu uso com isto é descomplicado:

• Insiro meu nome em novos arquivos;
• Adiciono meu nome abaixo do último se eu fiz alguma adição ao arquivo, ou;
• Não adiciono quando faço pequenas modificações sem acrescentar algo de valor ao então domínio/objetivo/proposta do arquivo.

Mas mesmo assim, sempre coloco no formato Nome completo <email@provedor>

Porém, não pela primeira vez vejo um developer defendendo o não uso deste annotation. A última vez foi numa discussão – no bom sentido – entre @sergioprado e @lfamorim. Com isto, fui perguntar a eles – e alguns outros mais – a opinião pessoal em relação ao tal annotation. Confira:

Eduardo Guerra – @emguerra

Obviamente se o uso de @author nas classes for uma prática da equipe irei segui-la sem problemas, mas se a escolha for minha opto por não colocar. Esse tipo de marcação no meu ponto de vista atrapalha a propriedade coletiva do código por determinar explicitamente os autores da classe. No caso de erros na classe, sempre haverão dedos apontando o autor como culpado, mesmo se não foi ele quem introduziu o problema.

Como toda documentação não-executável, pode deixar de ser atualizado com a evolução de um projeto e muitas vezes o autor original não é mais quem mais contribuiu para a classe no seu estado atual. Adicionalmente, sou a favor de manter o código o mais limpo possível e esse tipo de coisa acaba deixando o código de todas as classes mais verboso.

Cainan Costa - @sryche via Jabber

[20:03:08] cainan.costa: não faz sentido, porque o VCS já mostra =P
[20:03:16] cainan.costa: quem é o maluco que fez a parada
[20:03:25] cainan.costa: aí tu usa um git blame
[20:03:33] cainan.costa: e já sabe quem encher de porrada

Lucas Fernando Amorim – @lfamorim

Hoje em dia a tag @author é tão obsoleta quanto respeitar um limite de colunas para seu código, mas ainda assim acho elegante e talvez até relevante.

Fica muito mais fácil para aqueles programadores que não usam a IDE XPTO verem o criador de determinado arquivo, método ou função sem ter que recorrer a um programa. É repetitivo você pode alegar, mas eu posso retrucar que a tarefa pode ser automatizada.

Eu aprecio muita essa tag, pois a partir dela posso usando minha humilde IDE identificar o criador de determinados códigos, antecipando os vícios do autor e me adaptando para a leitura. Tudo isso sem abrir a shell e digitar N^C comandos.

N = Familiaridade com o programa X de controle de versão.
C = Commits anteriores.

Christian Benseler - @chrisbenseler

Tenho uma visão que o negócio é “mais embaixo”. Antes de tentar assinar um script como seu, o desenvolvedor tem que se preocupar com outros assuntos mais importantes: é um projeto pessoal ou colaborativo? Está prestando serviços a alguém, outra empresa? Qual a política do seu cliente? Qual a versão do script? E qual o tipo de licensa que será adotada?
Só assinar o script não vai fazer a menor diferença se não tiver essas informações. E não vai fazer nenhuma diferença se a comunidade não parar de copiar o script feito por A, retirar os author notes do script e redistribuir o script sem dar esses créditos e/ou sem levar em conta o tipo de licensa adotado.

Carlos Duarte do Nascimento – @chesterbr

Antes de mais nada, você se refere a qual linguagem? Em Java, @author pode significar tanto uma anotação em si (e aí depende do contexto), tal como:

@author(“chester”)
public foo(int bar) {
…

quanto (o que eu imagino que você queira dizer) a anotação feita em um doclet, i.e.:

/**
 * Um elemento coberto por JavaDoc.
 * @author chester
 */
public foo(int bar) {
...

No segundo caso, eu gosto de @author devido à facilidade em lidar com a autoria coletiva: ela permite anotar classes inteiras ou métodos/atributos particulares; você pode colocar múltiplos autores, e
o Eclipse pode ser facilmente configurado para adicioná-la automaticamente. No PHP, se me recordo, é possível usar algo
equivalente (phpdoc) em cabeçalhos de código, mas não sei se é válido colocar em métodos/atributos, ou se é possível ter múltiplas declarações no mesmo escopo.

Em qualquer caso, vale notar que sistemas de controle de versão como svn e git são mais eficientes para descobrir quem efetivamente contribuiu com uma classe/método do que esse tipo de tag. Além disso, elas não são suficientes para notas de copyright (ou seja, teriam que ser replicadas apropriadamente para o correto licenciamento do código, independente da licença utlizada), o que limita de fato sua utilidade prática.

Sérgio Prado – @sergioprado

Há muito tempo atrás, as ferramentas disponíveis aos programadores eram escassas e limitadas.

<oldschool>Já programei em Assembly com um DOS rodando num x86 e monitor CGA de 80 colunas x 25 linhas </oldschool>

Nesta época, ferramentas de controle de versão não eram tão comuns, nem monitores de 21 polegadas. Foi então que surgiram alguns paradigmas. Eram consideradas boas práticas de programação usar no máximo 80 colunas por linha de código (limitação causada pelos monitores da época), e incluir informações no cabeçalho do arquivo como @version, @author, @date, @changes etc.

O problema é que para muitas pessoas estes paradigmas perduram até hoje, por herança, por gosto (ou mazoquismo mesmo). Qualquer ferramenta decente de controle de versão pode te trazer, desde sua criação, todo o histórico de alteração de um arquivo. Além de ser mais seguro e confiável. Se eu usar no código-fonte “@author pica-pau”, grande parte das pessoas não irá perceber, porque ninguem lê o cabeçalho do arquivo. Também não existe garantia de que o nome documentado no código-fonte é realmente o do desenvolvedor. Já com uma ferramenta de controle de versão esta garantia existe.

Eu mesmo usava @author nos cabeçalhos uns tempos atrás, mas parei de usar depois que comecei a criticar alguns paradigmas que tinha. É tudo questão de delegar para ferramentas o que pode ser automatizado e buscar novas soluções para os mesmos problemas.

Fábio Miranda – @fabiolnm

Não uso por pura falta de hábito – nunca trabalhei em um projeto onde essa prática fosse adotada.
Mas acho interessante, não só o autor, como o email / github tb.

Pode ocorrer de ser necessário dar manutenção em determinado código cuja compreensão não seja trivial, e a possibilidade de contactar o autor, mesmo que remota, deve ser considerada e viabilizada.
Não vejo razão para ser contra.

E pra finalizar, os comentários fundamentados de Hanneli Carolina Tavante @hannelita – sobre o uso de @author e muito mais:

Bom, vou dar minha opinião sobre comentários no código antes de qualquer coisa…. Também utilizarei algumas metáforas e exemplos reais.

Eu já trabalhei com códigos de sistemas legados – Mainframes e sistemas bem antigos – , envolvendo C e Assembly. Vou contar uma coisa – quando abríamos um código e víamos infinitas linhas de comentário, já sabíamos que vinha coisa ruim pela frente. Tudo bem para aquele tipo de código sempre achei necessário comentar – Há algumas subrotinas do inferno que precisam de explicação. E o cara que fez isso tem idade pra ser meu pai, já faleceu ou se aposentou. Portanto, códigos assim são “legíveis” graças aos comentários deixados para trás. Já peguei código em Assembly sem comentários. E fiquei quase 10 dias só pra entender por cima o que o programa fazia.

Mas atualmente estamos em uma época onde encontramos linguagens extremamente expressivas, como Ruby e Python. E pra ajudar ainda tem uns framewroks tipo Sinatra, incorporando DSLs. Ou seja, hoje é possível escrever códigos que HUMANOS são capazes de ler. (humanos comuns, quis dizer hehehe). Se você escreve códigos em Ruby que humanos não entendem, então sinto muito, meu amigo, vá ler o Clean Code ou aprender a programar de forma limpa. Aliás, práticas de TDD ou BDD, por exemplo, influenciam e praticamente geram um código limpo e legível dadas as etapas que sugerem na construção da aplicação. Por exemplo, o famoso “Vermelho, verde, refatorar” do TDD – O refatorar ocasiona um cógido extremamente mais compreensivo. Construído tal código sólido e bem estruturado, eu questiono – comentários para que? Eles perdem o sentido. Por exemplo, você se depara com a seguinte expressão em Ruby:

 unless valor == 0
  puts "Valor diferente de zero!"
 end

Bem expressivo, certo? Pra que um comentário então? Uma das coisas que me irrita um pouco é encontrar códigos assim:

public class Pessoa {
  private String nome; //define o nome da pessoa
  private int idade; // define idade da pessoa
}

Ou pior, bem pior que isso:

public class Pessoa {
  private String a; //define o nome da pessoa
}

Ambos os casos eu considero inapropriados. O primeiro por gerer redundância – é ÓBVIO que o atributo “nome” faz menção ao nome da entidade pessoa! O segundo exemplo nos remete a alguém que não fez uso de bom senso de orientaćão a objetos para definir o nome do atributo. O comentário era necessário porque não houve refatoração e uso de um nom esclarecedor ao campo. De qualquer forma, isso é incorreto no meu ponto de vista.

Então quando usar comentários? Costumo usar comentários quando, por exemplo, utilizei algum recurso pouco conhecido da linguagem. Por exemplo, o uso de Fibers no Ruby – poucas pessoas sabem o que são Fibers; coloquei um comentário no meu código extremamente sucinto explicando o que era e onde achar mais informações. Ou se você utilizar alguma magia-negra no código, embebida por metaprogramação, por exemplo, acho que é bom deixar um comentário sucinto do que aquilo quis dizer. Esse tipo de comentário ajuda programadores juniors a adquirir experiência e ajuda até memso os seniors a captar a idéia geral de um método/bloco que possui lógica complexa.
E há alguns casos que comentários podem ajudar a leitura do código fluir e ficar mais agradável. Pra Java, por exemplo, existe uma API – GAG => http://code.google.com/p/gag/ – Google Annotations Gallery, da qual já fui colaboradora. Essas anotações dão emoćão ao código; de vez em quando acho interessante utilziar algumas delas; tornam o coódigo mais expressivo. Novamente, acho que se deve usar sem abusos =)

Sobre o uso do @author – Aí já acho que é uma cosia meio pessoal. Eu não coloco. Saber que sou colaboradora/commiter do projeto já está bom pra mim. A ligaćão entre eu e o código fonte vai muito mais além que um @author. Claro, tem o lado bom de se colocar; todos que tiverem o fonte saberão o responsável por aquela ciração, e poderão parabenizá-lo, encontrá-lo no Twitter ou no Facebook e coisas do gênero. Ou poderão xingar sua mãe com vontade. Mas acredito que há outras formas de se descobrir e pedir ajuda sobre algum fonte que não são através do @author.

Bom, essa é minha visão geral da coisa! =D

E aí, é contra ou a favor do @author ?

Mas, perché ?
Simples ! O que significa refatorar ?

Essa palavra que está na roda de conversa dos developers atualmente nem sempre é utilizada com sua real definição. Pare para pensar na última vez em que você refatorou algo. Responda a si mesmo as perguntas:

• Qual o objetivo do refactoring ?
• Quantas coisas (pontos de função, pacotes, formas (?)) foram alteradas ?
• Após, o que mudou ?
• Por quê necessitou refatorar ?

1. Qual o objetivo do refactoring ?
Fazer valer os princípios trazidos do alto da montanha descritos por developers como Uncle Bob e Barbara Liskov.
Em outras palavras: não repetir a mesma coisa duas vezes; ser coeso; ser claro e objetivo; cada “coisa” precisa ter sua responsabilidade e esta deverá ser única; e etc, etc e etcetera.

2. Quantas coisas (pontos de função, pacotes, formas (?)) foram alteradas ?
Uma e somente uma. Se você resolveu mudar uma funcionabilidade e junto adicionou uma coisa por menor que mínima, você aumentou a probabilidade de dar tudo errado. A dica aqui é: não é possível assoviar e chupar cana ao mesmo tempo.

3. Após, o que mudou ?
Nada. Você não tinha como objetivo mudar um comportamento, apenas melhorar algo que já existia. Se fez um refactoring por causa de um bug, então você não refatorou, mas sim, inseriu um ou mais novos bugs. Leia o item 2 novamente se ficou com dúvidas.

4.  Por quê necessitou refatorar ?
Vários motivos podem levar você a isto, mas a finalidade sempre acaba recaíndo sobre: melhorar o processo, a atividade ou relacionamento entre eles.

Processos, atividades e relacionamentos.

Repare que eu evitei falar de código diretamente. Isso pois eu vejo a refatoração algo possível para qualquer um em qualquer área. Tente aplicar os 4 itens acima em sua área. Se for um gestor, veja a refatoração como evolução e adequação dos processos existentes; No item 2 eu falei sobre formas(?) justamente com este propósito. Refatore a forma como você faz algo.

Nós da área Web da Vex, mantemos dentro do repositório dos projetos os arquivos SQL que geramos ao decorrer de cada alteração/adição feita aos projetos. Em meados do primeiro semestre de 2009, os arquivos .sql eram salvos da seguinte forma:

/data/projetoXPTO/moduloABC/umNomeDescritivo.sql

O umNomeDescritivo.sql parece algo legal. Vamos fazer um teste de mesa com isto:

/data/erp/relatoriosFinanceiros/engineDeGraficos.sql

Woow! Funciona perfeito. Tudo referente à engine de gráficos ficará neste arquivo .sql e done deal.

Com o tempo, aquilo ficou impossível de controlar pois a cada nova atualização, os arquivos ficavam maiores e o pior: quando o deploy da aplicação era realizado, como saber exatamente o que atualizar no banco de dados de produção ?

A partir deste problema, uma refatoração na forma de salvar arquivos SQL fora realizada. O novo modelo sugeria o padrão:

/data/projetoXPTO/moduloABC/YYYYMMDD_umNomeDescritivo.sql

Legal, problema resolvido ! Vamos ao teste de mesa:

/data/erp/relatoriosFinanceiros/20100301_engineDeGraficos.sql

A primeira vista, tudo perfeito. Contudo, nossos softwares são feitos com base em releases e acredite, temos muito código a cada novo release, gerando assim muito SQL para atualização. Processos manuais ou automatizados tornaram-se inviáveis pois a pergunta que ecoava na sala era:

Quais foram as datas dos Release 1.2.2 e Release 1.2.3 do software de autenticação mesmo ?

Pois é. E agora, José ? A partir disso eu pensei um bocado e resolvi dar palpite no processo. Porque não armazenar por release ?

/data/release-1.2.3/projetoXPTO/modulo_umNomeDescritivo.sql

Pronto. Agora consigo fazer uma análise do que mudou por versão. Essa refatoração no processo de armazenamento dos arquivos SQL mudou a forma como os arquivos são salvos e só.

Refatore sempre que puder. Mude e melhore aquilo que funciona, mas que não está na sua melhor forma. Tenha em mente que deixar algo que pode ser melhorado para trás, poderá custar-lhe caro amanhã. Porém, eu entendo que só há refatoração quando o objeto alvo está finalizado e funcionando. Antes disso o nome ao meu ver é implementação.

Keep refactoring

Artigo originalmente postado por mim no até então blog Ready to Sail, hoje, o planet da Vex.

A coisa toda deslanchou quando CRMs e ERPs começaram a ganhar versões web, direcionando-se para um modelo centralizado, eliminando a necessidade daquelas instalações em clientes, controle das versões, módulos e todo aquele inferno toda aquela via sacra que é controlar isto.

Os softwares web evoluíram, mas ainda precisavam do bendito refresh a cada ação. Surge então, a brilhante idéia baseada em uma API Microsoftiana esquecida ao léu, concebida ainda na década de 90, onde na ocasião os desenvolvedores a chamaram de XMLHttpRequest e tinha como objetivo iteração entre Outlook e Internet Explorer, provendo acesso ao Outlook Web Access. Ah sim, isso é conhecido pelos stakeholders como Ajax.

Com o advento desse tal Ajax, as telas baseadas em funcionabilidades puderam evoluir para telas baseadas em eventos – o que pode ser conversa para outro post – Com essa utilidade, softwares web-based aumentaram em quantidade astronômica e junto levaram a complexidade às alturas !

Essa tal de complexidade, começou a exigir dos softwares comunicação com outros softwares, iteração com diversos dispositivos: hardware hospedeiro; ferramentas e dispositivos físicos plugados na máquina cliente, ou seja, na máquina que está acessando o software via browser. De frente à toda essa necessidade, no ínicio teimaram em prover tudo isso com sua Linguagem de Programação Preferida e Bala de Prata ™. O resultado ? Perda de desempenho, muito dinheiro gasto com códigos que apenas satisfazem a necessidade da linguagem (i.e. Java, oi ?) e noites sem dormir.

PHP é uma excelente linguagem que muitos programadores PHP ainda não conhecem porém, não insista em controlar a impressora do cliente com a tal linguagem por que você simplesmente tomará na cabeça !

Disso, surgiu, assim digamos, um novo tipo de programador: o poliglota. Isso não quer dizer que entender ahn, COBOL e PHP torne-o passível de ser tachado como tal. Martin Fowler em entrevista à Paulo Silveira na Agile Brazil 2010, afirmou sem titubear que o programador poliglota é aquele que trabalha com mais de uma linguagem de programação em um mesmo software.

Neal Ford, tem uma visão um pouco mais abrangente sobre poliglotismo: ele afirma no livro The ThoughtWorks Anthology que o grande ponto do poliglotismo é aproveitar o que cada linguagem que roda sobre a JVM tem de melhor a oferecer. Ele dá exemplos de Java + Groovy; Java + JRuby e até Java + Jaskell. Isso é sem dúvidas infinitamente melhor do que tentar fazer uma aplicação em PHP e testá-la com Ruby e Cucumber sem qualquer tipo de integração direta =P

Desenvolver desta forma é mais comum do que se pensa ! Os primórdios dos Internet Banking’s foram construídos – e assim continuam – desta forma. Nada de arquitetura SOA ! – O banco ABN AMRO tem um artigo sobre SOA publicado no JISTEM-USP – É utilizado Java e PHP com o módulo PHP-Java bridge para tal mágica. Empresas como Facebook, Last.fm, Google, Yahoo! utilizam mais de uma linguagem para uma mesma ferramenta como é anunciado na rede. Isto demanda profissionais com algumas características:

• Livre de tecnologia. Os fanboys de linguagem de programação ficam a ver navios;
• Domínio da teoria. Não basta ficar preso às facilidades de uma linguagem X ou Y; Faz-se necessário conhecer o por quê das coisas, pois uma linguagem pode ser mais ou menos easy-to-use do que a outra;
• Interesse em conhecer novas formas e padrões: não adianta forçar-se a programar com o estilo Java com linguagens como Ruby. Camel case não é o padrão em Ruby;
• Vontade em conhecer novas linguagens. No livro The Pragmatic Programmer é pelos autores recomendado que você aprenda uma linguagem nova a cada ano, e;
• Estar apto a mudar tudo quase tudo, sempre!

Diante de tudo isso, qual linguagem “investir”? Eu levo em consideração a minha vontade na linguagem. Não é porque a linguagem Scala não está no topo dos mais procurados que eu não partiria para aprendê-la e usá-la em meus projetos e experimentos pessoais. É questão de afinidade com a linguagem. O mercado? Virá atrás de você de forma natural.

Artigo originalmente postado por mim no até então blog Ready to Sail, hoje, o planet da Vex.

Random Hack of Kindness São Paulo 2010 por danicuki

Eventos como Yahoo! Open Hack day; Google Developer Day; o recente Random Hack of Kindness; Coding Dojo (o de Sampa no IME da USP está meio inativo ao que consta); e vários outros movimentos iniciados até por empresas, como a própria Caelum que já abriu as portas para criar um ambiente onde programdores pudessem se juntar e desenvolver suas coisas, ou mesmo que fechado ao grupo de programadores da mesma como já ouvi relatos de programadores.

O que leva esse bando de programador malhucos das cavernas a participarem com empolgação destes eventos – muitas das vezes apenas com free lunch e Internet 0800 ? São desocupados ? Loucos ?

Yahoo! Open Hack Day Brazil 2010 por Antônio Carlos

Simples: adoram o que fazem ! São essas pessoas que geralmente criam tendências, aplicam ideias e tomam iniciativas nas corporações em que trabalham; São os mesmos developers que passam horas a fio programando com vários livros de nomes nonsense à tira-colo; ou que criam projetos pessoais para suprir uma necessidade própria e acabam chamando a atenção de muita gente – vide tantas startups bem sucessidas criadas e mantidas por programadores.

Geralmente esses mesmos programadores conhecem pelo menos duas linguagens. O motivo ? Curiosidade ! Pouco importa se Ruby on Rails fará sucesso no mercado coorporativo ou se Python não agrada o chefe. É legal para eles, então, investem tempo nisto.

Sempre em busca de novos conhecimentos, fanáticos pela arte em programar e fazer coisas novas; de novas formas e com novas ferramentas. Criam coisas, compartilham o feito e ainda passam a diante o novo conhecimento com artigos, blogs ou seminários. São programadores sempre motivados que buscam fazer uma análise crítica sobre suas próprias formas de programação buscando a evolução das ideias.

Vida social ? Muito bem, obrigado ! Nestas idas e vindas acabam conhecendo pessoas, lugares e oportunidades diferentes. Trocam ideias, conversam, trocam contactos das redes sociais; juntam-se em botecos ou equivalentes tornando o simples ato de programar em grupo em praticamente uma festa completa !

"Java printout por Ngọc Hà @ flickr"

Naquela época era claro para mim que programação era algo relacionado à área de exatas, pois criar uma aplicação é algo lógico tendo envolvimento direto com matemática e tudo mais.
Em coisa de um mês e pouco já conseguia fazer até uns “SQLs” e montava sites no estilo macarrônico de desenvolver. Aquilo para mim era fantástico! Tinha como objetivo aprender bem a linguagem para assim conseguir minha certificação da Zend, tornando-me assim um programador profissional.

Aconteceu porém, algo inesperado: comecei a “seguir” – não era no Twitter, até porque ele ainda era um protótipo de projeto na época – pessoas realmente profissionais em desenvolvimento de software e eu percebi assim que o buraco era mais embaixo e que eu ser excelente em uma linguagem era apenas um dos passos para tornar-me um programador profissional.

Abrindo um parênteses, eu li através do @sergioprado, não lembro onde agora, uma frase interessante e que tem como tradução algo como:

"O caminho para tornar-se mestre: siga o mestre; ande com o mestre;
torne-se o mestre."

Após começar eu a seguir os mestres, pude perceber que programação vai muito além da leitura de um requisito funcional de software e fazer daquilo algo sistêmico. Hoje, arrisco-me a dizer que programação não é algo somente relacionado à exatas. Possuí também, questões éticas – humanas – e artísticas.

A programação é relacionada a área de exatas

Isso é bem claro aos envolvidos em desenvolvimento de software. Você lê um problema descritivo, vulgo especificação funcional, ou visual (UML, rabisco na Moleskine, whatever) e faz daquilo algo sistêmico e que agregue valor ao negócio de seu cliente.

Como premissa você precisa aprender uma linguagem. Conhecer uma linguagem bem não é nada fácil. Você precisa empenhar-se para conhecer as intrínsecas e peculiaridades para aproveitar o melhor dela, tornando-se um especialista na linguagem. Eu valorizo mais um programador excelente em uma linguagem a um que já “trabalhou” com várias. Não é impossível uma pessoa ser excelente em mais de uma linguagem, mas isto, porém, demandaria muito tempo de dedicação para atingir tal nível.

A programação é relacionada a ética

Toda área tem suas condutas éticas e humanas, óbvio. Em programação, porém, vejo muitos ditos programadores ignorando isto. Quando você troca qualidade por falso ganho de tempo, você está sendo antiético. Quando não analisa corretamente as decisões que irá tomar em cima de algum problema, falta-lhe ética. Quando deixa de atentar seu cliente, o que inclui seu chefe, sobre a ausência de segurança, qualidade ou algum problema em cascata que venha a aparecer em decorrência de uma atitude, você está sendo antiético.

E isso acontece em demasia em nossa área! Seja por falta de interesse por parte do dito programador ou mesmo por medo de perder o emprego/projeto por “afronto” ao seu chefe ou cliente.

Para conhecer as técnicas, metodologias e artimanhas no desenvolvimento de software é necessário antes, ter uma boa noção de análise e projeto de software; arquitetura de aplicações; padrões e melhores práticas, para, após criticar uma atitude antiética de seu chefe/cliente, você ter total embasamento para propor a solução sem comprometer o projeto nem a aplicação. Isto será necessário também, para você ter um vocabulário comum para quando estiver numa roda de conversa entre os “mestres” da área.

Importante ressalvar que seu cliente ou chefe pode estar tomando uma atitude antiética, no ponto de vista de programação, inconscientemente. Afinal ele é especialista no negócio, o programador profissional é você!

A programação é também relacionada a artes

Há uma enorme diferença entre criar algo que funcione e criar algo que além de funcionar, transparece o domínio (regra de negócio).

Eu posso saber ler e escrever em português, mas há uma diferença gritante entre um poeta português e eu. Ele, diferentemente de mim, sabe utilizar muito bem as palavras e com elas, faz transparecer sentimentos, idéias e pensamentos sobre determinado tema, trazendo um enredo ao assunto abordado, envolvendo-nos em sua história.

Posso saber desenhar, mas isso não me torna um artista que emociona as pessoas com minhas obras.

Como programadores profissionais é fundamental conseguirmos fazer o mesmo ! É de nossa responsabilidade criar um código simples, legível e que conte toda a história da aplicação através de seus pacotes, classes, métodos, parâmetros, atributos e variáveis. Qualquer coisa diferente disso, não pode ser aceito como código profissional.

Pouco importa se a linguagem X é tachada como mais poluída que a Y. Você como profissional, tem que quebrar essa barreira e torná-la tão legível quanto qualquer outra, afinal, você é especialista na linguagem, lembra ?

Além de criar, é nossa responsabilidade cuidar para que o código continue sempre otimizado por tantas quantas forem as mudanças que nele ocorrer. Criar algo legível recai diretamente sobre isto, pois, no futuro outro profissional em programação poderá continuar seu trabalho sem danificar ou abandonar as premissas cruciais para um bom código. Andrew Hunt aborda o título: “Don’t live with broken windows”, onde resumidamente ele alerta para não descuidarmos da qualidade, pois, basta uma janela quebrada em uma casa para que ela transpareça o estado de abandono, fazendo assim, com que outras pessoas destruam mais janelas.

E como toda arte, não há uma receita para criar bons softwares. É necessário muito empenho, ler muitos códigos, revisar muitos paradigmas ao longo do tempo e claro, programar bastante. Não é possível tornar-se um programador profissional sem conhecimento teórico, tão pouco, sem vivência com erros e acertos.

Ao desenvolver a aplicação, não aceite nada menos do que seu melhor naquilo e atente-se para não cair na armadilha de criar softwares de forma sistematizada. Tenha autocrítica para fazer avaliações em seus próprios códigos e evitar assim, programar por coincidência.

Lembre-se de que será seu nome no @author.

Desde quando comecei a fazer programas venho usando algumas ferramentas para desenvolver em PHP.
Na categoria Editor / IDE, na minha mão (ui) já passaram Quanta Plus, KDevelop, Eclipse PHP IDE, Netbeans for PHP e agora estou utilizando o Zend Studio. Com exceção do último, todos free ou opensource.

Netbeans é muito bom, porém o que me chamou a atenção no Zend Studio foi o all-in-one que ele traz por default. Listando rapidamente:

• Editor PHP
• Integração SVN/CVS/Git
• PHP Debugging já integrado ao Zend Debugger
• PHP Profiling
• Database Management e Debug
• Um ToDo simples
• Facilidade em achar as coisas nos projetos
• Zend Toolbar integration para Firefox e IE – mas quem liga pro IE afinal
• etc…

Claro que não é impossível configurar toda essa penca de coisa no Eclipse nativo ou Netbeans, só que isto demandaria tempo.

Destaque para PHP Debug, Profiling e Zend Toolbar. Isto me chamou MUITA atenção quando estava olhando reviews e também nos trinta dias de testes.

Além do feijão com arroz temos:

1. Call Hierarchy / Type Hierarchy / Open Type Hierarchy

Ajuda um bocado na localização nas relações entre classes e métodos dentro do projeto. No exemplo tenho um método que chama outro e esse outro chama outro. No caso, tudo dentro de mesma classe, mas funciona perfeitamente em qualquer parte do sistema – incluindo libs no Include Path:

Já o Type Hierarchy mostra a relação entre uma classe e suas relações com classes pai ou interfaces:

E o Open Type Hierarchy (Ctrl + Shift + H) auxilia a localização de objetos, arquivos e métodos dentro do projeto.

Ainda na área de localização de elementos, há uma pesquisa mais completa (Ctrl + H) que permite localização de métodos, arquivos, classes separando por tipo e muito mais:

Após encontrar um resultado, a tab search é exibida/focada:

2. Indentação e Marcação (diff) no código:

Outra coisa interessante – e que existe em qualquer IDE decente – é a possibilidade de trazer o que é chamado de Quick Diff. Este recurso permite mostrar de forma simples o que você alterou, removeu ou adicionou no código. Funciona com SVN, CVS e cópia do disco local. Selecione o tipo e as cores e voilà !

Embora muito comum, a indentação de código é algo interessante de manter ajustado (tab com 4 espaços) e suas preferências quanto a espaço entre os elementos; posição de chave de abertura e etc;

Nessa tela é possivel você definir praticamente tudo sobre indentação de código ! Depois de configurar ao seu gosto (ou padrão) pode exportar para XML e usar em qualquer outra ferramenta que leia o formato – qualquer Eclipse, por exemplo =P

Depois de configurado, você pode selecionar o trecho a ter a indentação ajustada selecionando o trecho e  Ctrl + i – obrigado, Otávio pela dica; Pode formatar todo um arquivo usando Ctrl + shift + F – valeu Toscano pela tip – ou ainda, formatar TODO o projeto: Selecione o Projeto no PHP Explorer, Source -> Format – obrigado hlegius

Note que todos atalhos funcionam no Eclipse também

3. PHP Debug

Não é um recurso muito usado pelos developers PHP, principalmente aqueles que começaram com PHP, como eu, mas sem dúvidas revoluciona a forma de como você desenvolve. Após adotar o debug você não quer mais saber de var_dump() ou print_r() com aqueles: ‘estou aqui’ para verificar o que pegou na aplicação.

Como o PHP é baseado em Web, seria fundamental ele poder ser debugado como se estivesse sendo carregamento pelo browser, não ? E é exatamente isso que permite o Zend Debugger – o Xdebug também =~

Ambas engines de debug podem ser integradas ao Zend Studio, porém, no pacote do Studio já vem a versão mais recente do Zend Debugger e tudo já meio que ajustado para rodar com ele

É possível debugar um script PHP Modo terminal e claro, o PHP Web Debug. Para este último você fornece a URL que quer debugar e ele abre a sessão de debugging parando na primeira linha.

Utilizando os breakpoints você pode acompanhar o fluxo da aplicação, valores das variáveis, propriedades dos objetos instanciados e etc.

Claro que nossas aplicações vão muito além de uma simples URL. Temos chamadas com POST, GET e até chamadas em Ajax. O Zend Studio provê uma extension para o Firefox chamada Zend Toolbar. Essa toolbar, permite que você diga ao browser para chamar a sessão de Debug ou Profiling do Studio na próxima página; página atual; Qualquer submit POST ou ainda em qualquer ação no browser. E o pior: funciona !

A configuração do Zend Debugger na sua máquina é simples, mas acho ser digna de um post inteiro sobre isto. Vou tentar preparar um material e publico aqui a configuração e uso dele no Zend Studio.

4. PHP Profile

Além de debuggar, seria interessante analisarmos o desempenho da aplicação. Ok, segue:

Chamadas, quantas vezes chamou; quem demora mais; quem é mais rápido; quem chama quem;

E ele, o fluxo da aplicação:

A Zend Toolbar também provê acesso simples ao Profiling. Basta clicar em Profile na toolbar e pronto. O Studio é chamado e o profile da página é feito.

5. Database Management

Para fechar, gerenciamento dos databases. Possui ponte para vários databases incluindo Oracle, MySQL, PostgreSQL e MSSQL.

Por ele é possível adicionar valores, editar, remover, rodar Queries SQL, backup de estrutura e valores e ele também armazena suas Queries para re-executá-las com um clique quando quiser.

6. Outros

SVN, projetos remotos – incluindo acesso SMB ou FTP; WebServices; Históricos locais, SVN, diff, suporte a Git e suporte a quaisquer plugins que rodem no Eclipse, afinal o Zend Studio tem como base o Eclipse.

Já o configurei no Ubuntu lá na Vex, Windows 7 e Arch Linux aqui no escritório pessoal. Tudo muito tranquilo, sempre.

7. Preços e licença

O custo da licença eu acho alto demais para uma IDE de desenvolvimento. Atualmente são US$ 400,00 por ano para ter suporte e atualização sempre. Caso queira, pode comprar a licença por um ano e depois não comprar mais. Neste caso você ficaria com a última versão antes da expiração de seu suporte ilimitado. Em miúdos: enquanto você paga, recebe atualização da versão.

Comprei em setembro, na versão 7. Em Setembro de 2010, vamos imaginar que esteja na versão 9. Terei as licenças para 7, 8 e 9. Expirou e não renovei, mas saiu update da versão 9, a 9.1, por exemplo. Tenho update dela, pois a licença é a mesma da 9. Porém, no lançamento da 10, eu precisaria comprar uma nova licença para ter direito de baixar e usar a o v10.

Minha opinião final: gostei e tenho usado apenas ele desde quando comecei a testá-lo em meados de Setembro de 2009. Tem muita coisa boa e que ajuda muito e mesmo com o alto custo, vale cada centavo pago até o presente momento.

#notamental não é post patrocinado, tão pouco trabalho na Zend, certo ?

Pense numa rotina que desenvolveu. Qualquer uma ! Agora tente se recordar de quantas formas ela poderia ser quebrada pelo usuário, gerando assim algo inexperado na sua aplicação fazendo com que você retornasse um erro para o cliente.

E qual é a forma que você utiliza para retornar estes erros ? Veja, eu posso ajudar a recordar você:

Com isso lá na sua Action você fica fazendo malabarismo para encontrar o erro retornado e gerar a mensagem para o usuário. Não demorará muito para você criar sua tabela de erro:

• -1 para erros de entrada
• -2 para erros de máscara
• -3 para calcúlos errados
• -4 para usuário não logado
• -5 ....
• -7634 ....

Realmente, bem simples assim né ? Só consultar a tabela e mandar bala.

Eu realmente não entendo o motivo de muitos não utilizarem a classe nativa de exceções do PHP. É simples, é funcional e de grátis você não precisa montar sua tabelinha de códigos de erro.

Veja o mesmo código reescrito utilizando a tal classe:

Com isso na sua Action, simplesmente:

Assim, você pode ter 1, 2, 3, n mensagens de erro em n camadas da aplicação sem a necessidade de se preocupar em tratar uma a uma também na Action. Fica ultra-transparente na Action além de economizar seus dedos refazendo coisas que já estavam prontas camadas a dentro.

Nota: Não esqueça disso nunca : jamais lance como exception uma mensagem de erro do PHP. Isso é feio - porque vem em inglês -, você será xingado por 3 gerações futuras de programadores além de permitir que os usuários vejam detalhes sobre sua aplicação.

Como detectar os erros sem lança-los ao usuário ?

Bem simples. Persista-os - eita mania - em arquivos de log. Mas calma, antes de sair criando algo com fopen(), leia isto: o PHP também traz o cara que salva - persiste - erros ! Ah sim, o PHP é excelente eu sei. Voltando ao exemplo...

Sim, ele, o error_log() salva o log para ti. E pior, digo, melhor: caso queira ele pode enviar a notificação no seu e-mail. Certo, em boa parte dos casos isto definitivamente não é uma boa ideia. Mas pode ser útil algum dia, penso.

Resumo do dia: use ao máximo as Exceptions e as funções para tratamento de erros do php .

Pensando rapidamente parece um absurdo tratar sobre isto, mas acredite, assim como temos os Freetards - pessoas que têm amor ao Software Livre e critica todo o resto - Mactards, Wintards temos os programadores que descutem sobre indentação do código ! E acredite, tem "grupos" de programadores, cada qual defendendo um lado ! Loucura ? Continue lendo !

Nosso ponto de partida..
Como eu não sei exatamente onde que teve inicio isto, tomaremos como ponto de partida a publicação do livro The C Programming Language, escrito por Brian Kernighan e Dennis Ritchie. No livro você percebe que eles indentam o código da seguinte forma:

Porém, há uma exclusão aí ! Quando temos funções, a indentação desta é diferenciada, veja:

Repare que nestes casos, a abertura de chaves fica abaixo da linha que indentifica a função. Em todo o resto, a chave de abertura ficará na mesma linha.

Nota: vale lembrar que a mesma dupla que definiu que "Os nomes de variáveis e funções tem que expressar o significado do que ela armazena/executa, entretando o nome não pode ser extenso demais."

Em desacordo, nascem outras formas...

1. Eric Paul Allman - "Allman Style"
Vejamos a forma que ele usa e defende(defendia) :

A explicação é clara, assim como o código: isso evita que tenhamos linhas cheia de "tabs" apenas com chaves lá no final. Uma vez que as chaves sempre ficariam antes do conteúdo do bloco de código. É, até que tem sentido...

2. Whitesmiths Style
Esse estilo é usado pela Symbian ao desenvolver as aplicações em C++ para seus dispositivos móveis.

As chaves do bloco ficam abaixo da última letra do nome do método/construtor da linguagem. Ao que me parece, era usado nos primórdios do Windows também. (Carece de fontes confiáveis)

3. GNU Emacs
Sim, o guru do Software Livre também entrou nessa e criou seu estilo. Ele nada mais é do que a mistura do Allman com a Whitesmiths.

O código é indentado da seguinte forma: após o *if* você vai para linha debaixo e dá 2 espaços, e então coloca a abertura da chave do bloco. Vai para a linha debaixo novamente, e dê mais 2 espaços avançando dentro dos dois anteriores. Aí agora pode colocar seu código

Analisando alguns códigos...
Vejamos alguns códigos por aí a fora para ver o que a galera acha "pop".

- Código fonte Kernel do Linux (arquivo proc.c)

- Código fonte Mozilla Firefox (GranParadiso Alpha8) (arquivo nsBrowserApp.cpp)

- Código fonte The Vim Editor (arquivo edit.c)

- Código fonte Zend Framework 1.5 (arquivo Action.php)

- E claro, a "minha" forma de indentação

Resumindo....
Pegando emprestado o resumo do EmacsWiki.org, temos:

“gnu”
The default style for GNU projects
“k&r”
What Kernighan and Ritchie, the authors of C used in their book
“bsd”
What BSD developers use, aka “Allman style” after Eric Allman.
“stroustrup”
What Stroustrup, the author of C++ used in his book
“linux”
What the Linux developers use for kernel development
“python”
What Python developers use for extension modules
“java”
The default style for java-mode (see below)
“user”
When you want to define your own style

Para fechar o post, deixo aqui uma frase que encontra-se no livro The Programming C Language:

The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently.

Veja também: (Links em inglês)
http://www.emacswiki.org/cgi-bin/wiki/IndentingC
http://en.wikipedia.org/wiki/Symbian_OS
http://en.wikipedia.org/wiki/Indent_style
http://www.gamedev.net/community/forums/topic.asp?topic_id=446444

Quem já ouviu falar de design patterns e que programa em PHP ? Melhor: quem que programa em PHP e está utilizando qualquer uma das patterns mais conhecidas ?

Isso não é nada espantoso! Os programadores PHP em sua grande parcela ainda não acordaram para a nova realidade: código mais extensível e pensado. Nunca falei aqui, mas acho que o PHP tem um defeito grave: ser super simples. Isso estragou, em partes a fama da linguagem.

Vamos a um exemplo: duelo. Java Vs PHP.

Java: Hello world no shell

PHP procedural

PHP O.O

O que é mais fácil ? PHP ou Java ? PHP procedural ou PHP O.O ? Essa facilidade fez com que várias aplicações inseguras e mal pensadas infestassem a rede, causando uma rejeição do PHP por parte de vários Clientes e com isso, empresas de desenvolvimento de software. Isso é ruim para a linguagem, ruim para o profissional sério e ruim para o cliente que terá que pagar mais caro por uma tecnologia como o Java.

Hélio, tá, mas onde entra os design patterns nessa sua conversa mole ? Ok, até o momento eu tangenciei o tema, mas veja que para existir Pattern é ideal que haja Programação Orientada a objetos com tudo que temos direito.

Design patterns nada mais é que um conjunto de conceitos que visa auxiliar na resolução de um problema comum entre os programadores de verdade.

E dale exemplos

MVC (Model View Control - Modelo Visualização Controle) :: essa Pattern foi desenvolvida para resolver o problema da lambança de códigos, ou seja, um arquivo faz tudo: conecta no banco, traz dados, exibe na tela, pega retorno do cliente, aplica regra de negócio e salva no banco.
Imagine uma aplicação como E-commerce feita desta forma! Loucura hein! Falando em lambança, encontrei recentemente em um dos projetos que assumi, um arquivo executa.php. Já ouviu falar dele ? O "faz tudo" ? Não ? Assunto para outro post!

Então, como eu ia dizendo: para resolver o problema de manter tudo nas "costas" de uma mesma aplicação, foi pensado e desenvolvido esse modelo MVC onde a aplicação fica separada em camadas. Na camada mais baixa, fica o modelo, que faz a interação com o servidor de banco de dados, sistema de arquivos e etc.; Depois temos a classe que processa os dados recebidos pelo usuário e se passar por checagens simples é entregue a "Model"; e por fim, temos a View que nada mais é do que o HTML que o usuário vê, sem PHP, sem CSS sem Javascript misturado.

Criando um diagrama bobo temos:

Banco de dados -> Model -> Controller -> View

View: Usuário clica no botão submit com o campo Nome preenchido.
Controller recebe esse formulário. Verifica se o nome tá setado (sem checar seu valor). Setado ? Ok, manda para a model.
Model recebe e aplica a regra de negócio: no exemplo, o nome precisa ter pelo menos 3 caracteres. Tem ? Ok, pega o poll de conexão com o banco de dados e salva.
Retorna "true" para a Controller que exibe uma mensagem de "Sucesso" na View

DAO: (Data Access Object) :: Essa Pattern tem como objetivo separar a Model em dois: regra de negócio do acesso ao banco de dados. No nosso exemplo anterior, a Usuario.php receberia da UsuarioController.php o dado e a mesma aplicaria a regra de negócio. Após estar ok, a Usuario.php enviaria o status de "ok, pode gravar" para o UsuarioDao.php e este gravaria a informação no banco (verificando se o nome não existe por exemplo) e retornaria a informação de "true" para nosso Usuario.php.
Veja que ela tem como objetivo deixar a Model mais limpa e legível à manter regra de negócio e acesso ao banco tudo junto.

Factory Pattern (Fábrica) :: tem por objetivo englobar vários recursos dentro de um mesmo método usando os blocos de condição "if" ou "switch". Exemplo:

Veja que no exemplo o método Pesquisa() é um só mas dependendo do tipo de informação que ele recebe, executa uma ação diferente. Isso é a Pattern Factory, novamente resolvendo outro problema usando conceitos simples. Uma outra forma de resolver o mesmo problema seria criando vários métodos PesquisaId() PesquisaNome(), porém, estariamos deixando de lado a Pattern Factory.

Singleton :: essa Pattern tem como objetivo evitar que uma mesma variável, poll de conexão e etc., ocupe mais espaço na memória. Vamos a um exemplo:

No desenho que criei no Gimp, ao conectar com o banco é alocado certo endereço da memória para ele. Caso eu faça outra requisição de conexão, ao invés de alocar outro endereço de memória, ele vai usar o mesmo endereço. Pense em algo fixo. Posso fazer "n" requisições que ele sempre usará o mesmo espaço que foi alocado inicialmente.

A mágina está no public static $Con. Estou definindo que o $Con será estático.
Abaixo, o script que está na imagem:

Caso tenha interessado o assunto, você poderá pesquisar outras diversas Patterns que propõem solução para vários outros "problemas" que temos diariamente. Esse foi apenas um panorama geral sobre Design Patterns.