Boas práticas aqui NÃOOOOO!!!!

Todo programador deve aproveitar oportunidades de implementar algo que agrege valor para o projeto e/ou refatorar código legado para otimizar a manutenção do sistema.

Infelizmente em alguns ambientes, principalmente onde não há testes … o código funcionando por pior que esteja deve ficar como está, não se modifica uma virgula, ou ajax é considerado ‘firula’ do qual se evita utilizar … creio que para programadores ignorarem técnicas da nossa profissão como ajax, melhoria continua e refatoração, é um sinal que algo está faltando.

Esse foi a minha constatação ao participar de dois projetos PHP , onde percebi a diferença entre desenvolvedores e empresas(que utilizam PHP comparado ao Ruby), principalmente sobre teste unitário, ao convesar a respeito do assunto, ouvi respostas como: “aqui não rola teste unitário”, ou, “o que é teste unitário?”, e ainda, “não vimos utilidade no teste unitários, na verdade, achamos que iriam mais nos atrapalhar”.

Então procurei anotar algumas situações nestes projetos onde os testes trariam benefícios, que seguem abaixo:

  • Em uma tarefa para uma correção de bug e criei alguns teste unitários, e mostrei para o responsável por aprovar as alterações, foi onde ouvi “Teste unitário aqui não rola!”, então ele pediu para excluir os testes do branch e subir apenas a correção. Alguns dias depois, quando surgiu um outro bug, no mesmo método, ele me pediu para testar bem as modificações antes de colocarmos em produção, se fazer isso manualmente para alguém que conhece todo o sistema não é eficiente, imagina para alguém novo no projeto.
  • “Métodos pequenos não são necessário, aqui adicionamos novos requisitos e comentamos”. Havia métodos com mais de cem linhas e quando é necessário uma nova funcionalidade no sistema a regra é adicionar direto nos métodos existentes.. mas quando ocorreu um bug no meio de um destes métodos, com vários ‘ifs’ aninhados, que ninguém conseguiu identificar a causa do bug, o bug foi consertado, extraindo um trecho do algoritmo, mas a real motivo do erro não foi detectado.
  • Em outra situação, ao desenvolver um script para buscar o geocode no gmap, estava sendo excedido o limite de consultas na API, travando o desenvolvimento da solução, e os teste (manuais) do script, obrigando a deixar essa tarefa para o dia seguinte. Nessa situação, mocks e stubs poderiam ser a solução para não interromper o desenvolvimento.
  • Implementaram um padrão para codificação de código (do qual foi recentemente definido na empresa), como tabs, nome de funções, e espaços agora devem seguir o padrão, mas há muito código feito antes de se definir o padrão do qual esbarramos quando vamos corrigir um bug, que a regra é modificar apenas o código que a tarefa pede, ou seja, não faça refatoração, se você ver algo errado, deixe do jeito que está, tudo isso por medo de derrubar um sistema do qual a única maneira de verificar se algo deu errado é através dos logs de erros do sistema !!  Claro que a empresa tem prejuízo se algum desenvolvedor fizer algo errado, mas um projeto que não é melhorado constantemente torna-se difícil de gerenciar e diminui a produtividade do time, talvez irá dar ainda mais prejuízo .

Minha conclusão ao retornar ao PHP depois de ruby, existem diferenças de linguagem e plataforma, mas a maior diferença é a cultura da comunidade de desenvolvedores, infelizmente a maioria dos programadores PHP não estão preocupados com boas práticas.

Site – Descubra o melhor com Tabasco no Foursquare

Campanha pioneira integrando o Foursquare criada pela FocusNetworks para a TABASCO® brand Pepper Sauce com o objetivo de ser um guia colaborativo para mapear estabelecimentos que oferecem a pimenta TABASCO® aos seus clientes, e as melhores dicas de estabelecimentos são premiados com um kit exclusivo de pimenta e no final da campanha com um Ipad2.

Veja mais informações sobre a dinâmica do concurso no site brainstorm9 e no videocase do programa Adnews na TV e Mix Tv.

Site tudocomtabasco.com

Site tudocomtabasco.com

Fui responsável pelo desenvolvimento server-side utilizando Ruby on Rails, SASS e HAML como template e a GEM FOURSQUARE2 para buscar os estabelecimentos com dicas, contribui com o desenvolvimento desta GEM adicionando as funcionalidades de filtrar o conteúdo do Foursquare com determinadas palavras dos quais era necessárias para a camapanha, (assunto abordado neste post), e da programação client-side utilizando jquery, e da conversão do PSD para HTML ( template HAML ) e CSS (SASS).

GEM para filtrar o conteúdo do Foursquare

Trabalhando em um projeto que usa a API do  foursquare(+ info em breve), precisei desenvolver um filtro para as dicas, estabelecimentos e usuários que contenham um determinado termo no texto das dicas, como a funcionalidade não existe na api oficial do foursquare e em nenhuma outra GEM Rails, adicionei as funcionalidades na Gem Foursquare2 .

Endpoints é como a documentação do foursquare se refere a cada recurso da sua API,  foram adicionados  os seguintes endpoints:

Pesquisa estabelecimento através das dicas, retornando apenas estabelecimentos que possuem uma dica sobre café por exemplo

client.search_venues_by_tip(:ll => '36.142064,-86.816086', :query => 'coffee')

Pesquise usuário por dicas, retornando apenas estabelecimentos que possuem uma dica sobre “cerveja” por exemplo

client.search_users_by_tip(:ll => '36.142064,-86.816086', :query => 'Marco')

E adicionado uma funcionalidade extra nestes dois já existentes:

Pesquisar dicas de um estabelecimento com determinado texto, como pizza

client.venue_tips("4b2afcaaf964a5205bb324e3", :query => 'pizza')

Pesquise dicas de um usuário com determinado texto

client.user_tips("123456", :query => 'coffee')

Nesta Gem utilizei duas ferramentas que gostei muito, o framework de test shoulda e a Fakeweb, o fakeweb acelerou os testes e permitiu continuar o desenvolvimento mesmo offline, ferramenta que ainda não havia utilizado e que tornou o desenvolvimento extremamente produtivo, então desenvolver algo integrado com alguma API sem Fakeweb nunca mais.

As alterações foram integradas a GEM Foursquare2 original.

Material para aprender o Vim

Estes dias eu e o Marcos Santos conversamos a respeito de materiais de estudo para aprender o VIm, e creio que este assunto pode ser útil para quem está iniciando a jornada por este poderoso e/ou complexo editor.

Junto com o VIm há um minicurso instalado por padrão, é o VImtutor, um tutorial interativo do vim, onde você vai lendo sobre os comandos e experimentando com eles no próprio texto do tutorial. (o conteúdo é em inglês, então quem precisa estudar o idioma leva 2 pelo preço de 1..rsss )

Pra quem procura conteúdo intermediário há o VIm tips, um wiki com muitas dicas,  eles também postam no twitter um resumo destas dicas, do qual vale o follow ;-).

Outra ótima maneira de aprender é observamos outras pessoas usando o VIm, e na falta de alguém por perto, tem o screencast  vimcast, com conteúdo que vai do avançado ao básico.

E o livro Vim book, traduzido em pt-br e free, é um pdf com 130 páginas com as principais rotinas de edição de texto, e o pra quem prefere impresso há o Learning The VI And Vim Editors, que é muito bom, em papel não há nenhum em pt-BR, se alguém encontrar algum deixa a dica nos comentários ;-)

Algo útil de ter por perto para referência, é este stylesheet que mapeia a função de todas as teclas.

Graphical cheat sheet VIm

E  tem a apresentação “7 Habits For Effective Text Editing 2.0“, de ninguém menos que o pai da criança Bram Moolenaar.

Agora para ser um ninja em VIm, é só praticar, praticar , praticar …

Agile Vale 2010 .. eu fui

O time de desenvolvimento web da Canção Nova esteve no Agile vale 2010 e tivemos uma grata surpresa durante o evento, fomos citado na palestra de “cultura de aprendizagem” da Bluesoft devido ao nosso grupo de estudo… \o/\o/\o/

    Time de desenvolvedores web da Canção Nova e o pessoal da Bluesoft

Time de desenvolvedores web da Canção Nova e o pessoal da Bluesoft

As palestras foram ótimas e tivemos dificuldades em escolher qual participar, destaque para a mesa redonda que discutiu temas bem interessantes.

post original : http://blog.cancaonova.com/desenvolvimentoti/agile-vale-2010-nos-fomos/

Ruby conf BR 2010.. eu fui

Estive nos dias 26 e 27 de outubro no Ruby Conf Brasil 2010, evento com palestrantes nacionais e internacionais sobre o universo Ruby e afins .

As palestras foram de altíssimo nível, tratando de assunto bem avançados, voltei de lá cheio de lição de casa pra fazer. =D

E durante o networking conheci alguns desenvolvedores do vale que também estavam no evento (@cassiomarques, @zigotto, @derencius)

Fato triste foi ter pegado a estrada sozinho, próxima vez é melhor encarar a viagem com alguém.. (já prepara a agenda Matheus Muller)

Parabéns a Locaweb pela organização do evento.

Filosofia das linguagens

Estudando Python tive contato com o Easter Egg “The zen o python”,  é uma mensagem que traduz a filosofia da linguagem, isto me fez pensar sobre a filosofia de algumas outras linguagens, aquilo que a comunidade de desenvolvedores incorpora, que serve como um guideline quando se desenvolve com a linguagem e que influência a maneira da linguagem funcionar.

Abaixo listo algumas filosofias que encontrei,  a maioria dos princípios são aplicadas no principal motivo da existência de uma linguagem de programação, o desenvolvimento de software, e estão mais para filosofias de Software Craftsmanship.

Escolher uma linguagem de programação vai além que aprender sintaxe e APIs.. ;-)

em Unix

Escreva programas que façam apenas uma coisa mas que façam bem feito.

Escreva programas que trabalhem juntos.

Escreva programas que manipulem streams de texto, pois esta é uma interface universal.”

http://pt.wikipedia.org/wiki/Filosofia_Unix

em C tem o “Spirit of C”

Trust the programmer.
Don’t prevent the programmer from doing what needs to be done.
Keep the language small and simple.
Provide only one way to do an operation.
Make it fast, even if it is not guaranteed to be portable.

fonte: http://www.artima.com/cppsource/spiritofc.html

em Python tem o “The zen of python”

Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Plano é melhor que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o bastante para se quebrar as regras.
Embora a simplicidade supere o purismo.
Erros nunca deveriam passar silenciosamente.
A menos que explicitamente silenciados.
Ao encarar a ambiguidade, recuse a tentação de adivinhar.
Deveria haver uma – e preferencialmente apenas uma – maneira óbvia de se fazer isto.
Embora aquela maneira possa não ser óbvia à primeira vista se você não for holandês.
Agora é melhor que nunca.
Embora nunca, seja muitas vezes melhor que pra .
Se a implementação é difícil de explicar, é uma má idéia.
Se a implementação é fácil de explicar, pode ser uma boa idéia.
Namespaces são uma idéia estupenda – vamos fazer mais deles!

Sobre o python há um podcast sobre cada um dos conceitos contidos no Zen, e aqui, http://code.google.com/p/soc/wiki/PythonStyleGuide, uma lista de boas prática para atingir o zen

Em ruby encontrei alguns dizendo que certas coisas são o inverso do python, como várias maneiras de se fazer a mesma coisa.. e tem o “The ruby way”.