Effective Programming: More Than Writing Code

1559_thumbComo programador que sou, dedico boa parte do meu tempo escrevendo para um computador e tentando me aperfeiçoar nisto. No entanto, isto não é tudo que se espera de mim como profissional. Grande parte do meu trabalho não está relacionada ao código que escrevo. Por mais que me tornar um escritor de código melhor seja essencial para o meu trabalho, existem outros pontos tão essenciais quanto (ou mais) e é disto que Effective Programming: More Than Writing Code se trata.

Este ebook é um apanhado de posts do famoso blog Coding Horror de Jeff Atwood  — um dos meus blogs favoritos, devo admitir — é comercializado pela hyperink por justos US$ 2,99, e você ainda pode enviar para os amigos de graça no momento da compra! Claro que tudo isso é possível porque a “editora” sabe que você já tem esse conteúdo gratuitamente, mas acredite, só o trabalho de separar e organizar estes posts já vale mais do que o simbólico preço.

O Coding Horror é um blog publicado desde sempre 2004 e embora eu até já conhecesse alguns dos posts no livro, a maioria foi inédita para mim. Eu recomendo muito a leitura, mas se você não estiver planejando comprar, considero os seguintes posts altamente interessantes:

I Repeat: Do Not Listen to Your Users: Muito perceptível no dia-a-dia. Ouvir cegamente seu usuário chega a ser frustrante, mas isto não significa que devemos ignorá-lo.

Listen to Your Community, But Don’t Let Them Tell You What to Do: Sobre como receber o feedback da comunidade ao redor do seu software ou projeto.

Low-Fi Usability Testing: “You don’t know if your application truly works until you’ve performed usability tests on it with actual users.”.

I Pity The Fool Who Doesn’t Write Unit Tests: “Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead.”

The Ultimate Unit Test Failure: Seu usuário não liga muito para sua cobertura de testes de 100%.

Meetings: Where Work Goes to Die: Me fez fazer a minha “lição de casa” antes das reuniões do trabalho.

Sharpening the Saw: “Sharpening the saw is shorthand for anything you do that isn’t programming, necessarily, but (theoretically) makes you a better programmer.”

Como o próprio título do livro já diz, eu aprendi mais do que escrever um código melhor.

Introdução à Arquitetura e Design de Software

Em virtude dos projetos em que eu estava envolvido, decidi aprender um pouco mais sobre Java. É comum no meu dia-a-dia escrever algumas linhas de código nessa linguagem — normalmente acompanhado por alguém com mais experiência do que eu. Foi exatamente um desses programadores mais experientes, o Thiago Caiubi, que me indicou o livro “Introdução à Arquitetura e Design de Software — Uma visão sobre a Plataforma Java”. Excelente indicação, por sinal.

Me lembro de ter ouvido um colega de faculdade dizer que uma das partes de se aprender uma nova linguagem é entrar no “eco-sistema” dela. Um grande acerto do livro é começar exatamente por este ponto. O capítulo 1 — A plataforma java — nos introduz ao glossário da linguagem, nos explica como a linguagem tem evoluído e mostra como funciona o sistema de especificações com a tal “burocracia”  em se incluir uma funcionalidade na plataforma. Embora seja um livro focado em uma tecnologia, fiquei impressionado com o grau de imparcialidade apresentado. Foi muito bom ver que nenhuma das ferramentas é apresentada como “a solução definitiva para o problema X” (nem mesmo o próprio Java). Os autores se esforçaram para apresentar pontos a favor e contra cada tecnologia, assim como possíveis casos de uso.

O livro se faz valer também por suas referências. Pausei a leitura várias vezes para poder lê-las e refletir com calma. Essas pausas, no entanto, se tornaram um pouco incômodas com o tempo. Porque as referências ficam listadas todas no final do livro (NBR 14724, ou parecido). Aliás, por que não colocá-las no rodapé da página?

Como a própria descrição já diz, o objetivo deste livro não é te ensinar a linguagem e sim te introduzir ao pensamento arquitetural, e de design, de software que utiliza a plataforma Java nos dias de hoje. Isso faz com que o livro aborde temas como frameworks, REST, conceitos de orientação a objetos, dentre outros. Ainda assim, enriquece estes tópicos mais “comuns” com a experiência dos autores — Não necessariamente recomendando algo, mas estimulando seu raciocínio.

Visto que a última vez que li um livro de Java foi em 2008 — durante a minha faculdade — este livro me ajudou a me atualizar com o desenvolvimento Java desta década e estudar conceitos de arquitetura e design. Não sei se o livro gerará tanto interesse aos que já tem mais experiência com a linguagem, mas acho bem possível que ele te leve a uma reflexão.

Pro Javascript Design Patterns

Mais um livro de JavaScript lido. Desta vez foi Pro Javascript Design Patterns de Dustin Diaz e Ross Harmes. Fiquei interessado pelo título logo de cara, não conseguia enxergar como certas convenções populares em  outras linguagens iriam se encaixar no estilo “diferente” do JS.

O livro cumpre bem seu papel de apresentar os Design Patterns de forma fácil e mostrar como é possível adaptá-los ao Javascript. Confesso que resisti bastante às concessões feitas para tornar possível a implementação de alguns conceitos, como namespaces, ainda que seja claro o potencial benéfico que têm.

Embora os exemplos sejam bem enfáticos quanto à separação de responsabilidades, o que já era esperado dado que o intuito é ensinar Design Patterns, fiquei incomodado com o estilo do código-fonte. Boa parte das funções e métodos são bem extensos e sem boa legibilidade. Algumas vezes eu simplesmente desisti de entender o que cada linha de código fazia e deduzi pelo nome do método. Provavelmente, não há algum problema de design neles, mas o jargão do Uncle Bob ecoou na minha cabeça algumas vezes.

Se você já não gosta de JavaScript, por qualquer motivo, provavelmente este livro não vai mudar a sua opinião. Mas, se você já conhece a liguagem, está acostumado a desenvolver tudo o que precisa sem muita orientação a objetos e separação de reponsabilidades, e já percebeu que isto não é suficiente, este livro pode te ajudar muito.

Professional JavaScript for Web Developers, 2nd Edition

Professional JavaScript for Web Developers - 2nd EditionJavascript é uma linguagem que tem se tornado cada dia mais importante. Ela percorreu um grande caminho desde os longínquos tempos em que servia apenas para validar formulários e impressionar os amigos, passando pela revolução do AJAX e interfaces ricas, até chegar nos dias de hoje com novas possibilidades do HTML5 e Node.js. Diante de todo este movimento, eu precisava aprofundar meus conhecimentos na linguagem.

Muitos são os livros que abordam o Javascript, mas o Professional Javascript for Web Developers me pareceu ser aquilo que eu precisava. Em seu índice, encontrei desde conceitos básicos, como variáveis e escopo, até outros mais novos, como Client-Side Storage.

Durante a leitura, me surpreendi ao descobrir pequenas armadilhas e pormenores interessantes mesmo em capítulos onde eu não esperava novidades. Pude entender conceitos como: O que é ECMAScript, DOM Levels, Como evitar alguns memory leaks, melhorias de performance, boas práticas, etc.

O autor, Nicolas C. Zakas, trabalhou por bastante tempo no Yahoo! como front-end engineer e contribuiu bastante para o desenvolvimento da YUI. Recentemente, ele ajudou a criar o CSSLint, uma ferramenta de qualidade de código CSS aos moldes do JSLint. Uma boa parte do conteúdo do livro está disponível online nos artigos de seu blog, vale a pena conferir.

De fato, a leitura deste livro me ajudou bastante a conseguir entender a linguagem como um todo e desenvolver boas práticas. Os dois últimos capítulos do livro (Upcoming APIs e The Evolution of JavaScript) tentam adiantar o que estava por vir, aumentando sua vida útil. Naturalmente, dado a evolução a passos largos do HTML5, a implementação de algumas features tomaram hoje um caminho diferente ou perderam parte de sua relevância visto que o livro é de 2009.

Uma atualização com as APIs e funcionalidades mais recentes seria bem vinda. Ainda assim, não perca a oportunidade de ler este livro se você, como eu, quer se aprofundar mais nas “entranhas” do JavaScript.

MockPress: TDD mais fácil no WordPress

Praticar TDD no WordPress não é trivial. Como utiliza variáveis globais, não é difícil fazer Mocks para vários objetos (o objeto $wpdb de conexão com banco de dados, por exemplo). Mas se você já desenvolveu algum plugin, sabe que é necessário mais do que os objetos globais. A todo momento, é necessário utilizar funções próprias do WordPress. O desafio é testar seu plugin sem precisar testar todo o CMS. Para resolver este problema, existe o MockPress.

MockPress é uma biblioteca de funções mock. O criador, John Bintz, fez um bom trabalho criando uma instalação fácil e uma boa documentação. O código-fonte também está muito bem escrito (e testado). Para instalar a versão mais atual, só é necessário clonar o projeto no github e adicioná-lo ao seu include_path.

Após instalado, inclua o seguinte entre os requires de seus testes:

require_once "MockPress/mockpress.php";

Pronto, agora você pode utilizar as funções do WordPress em seus testes unitários. Recomendo apenas que você dê uma lida no código-fonte para entender quais são os retornos das funções mock.

Nem todas as funções do WordPress estão presentes no MockPress. Se você precisar de alguma função adicional, recomendo que contribua com o projeto. Das duas vezes que enviei uma contribuição, foi aceita bem rápido e sem burocracia.

Lembre-se que este é um projeto ainda em estágio inicial, apesar de muito útil e quanto mais adoção houver, mais completo deverá se tornar.

Finalmente VIM

vim-editor_logoDentre todas as flamewars do desenvolvimento de software, poucas são tão antigas quanto a dos editores de texto (atualmente, editores de texto e IDE’s). De forma alguma quero tentar defender alguma bala de prata. Eu mesmo já mudei de ideia várias vezes quanto a este assunto.

Ainda estou aprendendo a usar o VIM, mas já estou colhendo os resultados deste esforço. Estou impressionado com a extensibilidade e personalização deste editor. Com certeza, é uma excelente ferramenta e tem uma curva de aprendizado fantástica (mas exige esforço, principalmente no começo). Se você ficou interessado, pode começar a aprender a utilizá-lo lendo o vimtutor (Digite vimtutor no terminal ou leia online).

Quando houverem dúvidas, é fácil encontrar informações e dicas em várias fontes. Mas, se você está começando e já leu o vimtutor, recomendo a leitura dos seguintes artigos:

Sugiro que assim que você comece a personalizar seu arquivo .vimrc, faça um backup. O Gist do github é um excelente lugar para isto (O meu já está lá). Se você tiver alguma dica ou comando que costuma adicionar ao seu .vimrc, por favor, me mande. Quanto mais dicas melhor.

A Arte do Desenvolvimento Ágil

Há muito tempo, desenvolvimento ágil é um assunto do meu interesse. Este interesse começou em 2005 quando li um e-book que explicava superficialmente o que é XP. Anos passaram, fiz faculdade, aprendi mais sobre desenvolvimento software,  e meu conhecimento sobre este tema não passou do “superficial”.

Resolvi comprar o livro The Art of Agile Development de James ShoreShane Warden (comprei o original, mas também existe a versão em português). A descrição, na página da amazon, diz que o livro não diz apenas o que é Desenvolvimento Ágil, mas trás informações práticas para adotá-lo por todos os envolvidos no projeto. Isto era exatamente o que eu precisava.

O livro cumpre exatamente o que se propõe. É muito interessante repensar conceitos sobre qualidade e sucesso de um projeto, entender conceitos como TDDDomain-Driven DesignPair Programming,  etc. Além de saber o que é e como fazer, também fui incentivado a descobrir o porquê dos conceitos. O livro te leva à reflexão de uma forma muito interessante, pois depois das explicações, também são apresentadas contra-indicações e alternativas. O livro contém experiências dos autores e exercícios que são usados para que possamos entender melhor algumas práticas.

A cada nova prática utilizada, os benefícios são quase instantâneos. Como dito por um dos participantes da grupo de discussão do XP: O desenvolvimento ágil fez com que o desenvolvimento de software voltasse a ser divertido.

Clientes de Debug para PHP [Atualizado]

xdebug-logoDias atrás, participei da PHP Conference. O evento foi melhor do que as minhas expectativas e voltei cheio de ideias e dicas para por em prática. Uma das dicas foi começar a usar o xDebug pra valer. Chega de fazer debug com var_dump!

Quanto à instalação do xDebug, não tive problemas. O complicado mesmo foi escolher o cliente do debug. Pelo que tenho visto em posts e eventos, a maioria dos programadores PHP faz debug em uma IDE, na maior parte, o Eclipse PDT. Teoricamente (ou seja, segundo o site do xDebug) existem várias outras opções. Tentei testar todas as opções para linux na prática, algumas não saíram da teoria.

Testei o protoeditor como plugin do Kate (meu editor de código atual) e não consegui compilar por falta de algumas bibliotecas. Dei uma chance para o Eclipse, mas a lentidão e a quantidade de bugs dele me tiraram do sério (por isso o Kate é meu editor atual). Tentei o plugin do Emacs, mas também não consegui fazer funcionar (acredito que seja por falta de conhecimento). Pensei no Netbeans, mas não tive paciência para baixar e instalar. Por último ou não, testei o plugin do VIM, este sim funcionou perfeitamente!

Eu ainda gostaria que houvesse um programa para linux parecido com o MacGDBp, mas o VIM está cumprindo o objetivo com louvor, principalmente depois que eu li o vimtutor.  Aliás, com o que eu aprendi do VIM, deu até vontade de passar a usá-lo mais regularmente. Talvez em um futuro próximo…

Para facilitar a vida

Criei uns bookmarklets para adicionar as variáveis de ambiente do xDebug na página atual do navegador (o código ficou tão pequeno que coube até em um tweet – Pena que não dá pra ler direito). Se quiser usar também, arraste o link abaixo para sua barra de favoritos:

[xDebug] Start Session

[xDebug] Stop Session

[xDebug] Profile

Para agilizar o debug de scripts php-cli, também pode adicionar estes dois “aliases” em ~/.bashrc (para que sejam recriados em novas sessões do terminal):

alias xdebug_debugger='export XDEBUG_CONFIG="remote_port=9000 remote_enable=1"'
alias xdebug_profiler='export XDEBUG_CONFIG="profiler_enable=1"'
alias xdebug_clean='export XDEBUG_CONFIG=""'

Atualização – 31/12/2009: Adicionei dois bookmarklets (profile e stop xdebug – aproveitei para reduzir ainda mais o código :)) e um alias para iniciar o profile em linha de comando.

Até a próxima!

Kubuntu 9.10: Desta vez acertaram!

Desde que escrevi o post sobre o Kubuntu 9.04, tive uma experiência muito mais completa com ele. Por isso, estava aguardando ansiosamente uma nova versão. Não que eu tenha achado o Jaunty (9.04) uma versão péssima, mas ao utilizá-lo fui me deparando com vários pequenos bugs que juntos deixaram o sistema meio “sem sal”.

Quando finalmente chegou o dia do lançamento do Kubuntu 9.10 (Karmic Koala), não sabia se depositava minhas expectativas nele ou me conformava pensando que o Kubuntu não teria a mesma atenção aos detalhes que o Ubuntu.

Instalei a versão 64 bits, tanto no notebook quanto no desktop citados no post anterior. Devo admitir que me surpreendi. O novo Kubuntu melhorou muito! Ao comparar com a versão anterior, imagino o gigantesco trabalho da equipe do KDE e da Canonical.

imagem1

Uma lista de novidades está presente neste link, mas eu gostaria de destacar alguns itens que me chamaram a atenção.

KDE 4.3

Esta nova versão do KDE está muito mais bonita e estável. Se você utilizou a versão anterior, deve ter passado por inconvenientes como o gerenciador travar e voltar para a tela de login, ou uma grande perda de performance quando os efeitos da área de trabalho estão ligados.

Dica: Meu computador ficou ligado por muitos dias, aumentando muito o consumo de CPU do programa plasma-desktop. Usei o comando Shit+Alt+F12 para desabilitar os efeitos na área de trabalho e, logo em seguida, repeti a combinação para reabilitá-los. O uso de CPU voltou ao normal.

Amarok 2.2

O amarok da versão anterior era interessante e bonito, mas perdia muitas características se comparado com a versão 1.4 (para kde 3). A boa notícia é que algumas coisas da versão 1.4 voltaram a funcionar (Integração com a Last.fm, exibição de mídias em dispositivos conectados), outras funções foram melhoradas (Painel de contexto, lista de reprodução, personalização do layout), mas ainda sinto falta de algumas coisas (descrição nos episódios dos podcasts, equalizador). De qualquer forma, o amarok 2.2 já é meu player favorito.

Dolphin

Eu já gostava da versão anterior do dolphin. O que fizeram foi melhorar aquilo que já estava bom. E não foi pouca coisa, adicionaram preview das imagens nas miniaturas das pastas e agora também é possível ver um preview do video clicando em um pequeno botão play abaixo de sua miniatura.

Outros componentes também receberam melhorias consideráveis. É o caso do gwenview, kopete, network manager, kpackagekit (apesar de ainda estar confuso na hora de adicionar novos programas), etc. Ou seja, se você estava esperando o KDE 4 ficar maduro para sair do KDE 3 ou para experimentar o Kubuntu, a hora é agora.

Criptografar o código-fonte é uma boa ideia?

Usar uma linguagem de programação interpretada, normalmente, significa que o código-fonte terá que ficar no servidor de produção (no caso de softwares para a web). Em alguns projetos, isto é um problema. Uma solução para muitos é manter o código-fonte criptografado. Apesar de ser uma prática muito comum, acredito que para muitas pessoas esta não é uma ideia muito boa.

A pouco tempo, estava procurando por um módulo de uma ferramenta que estava personalizando. O módulo era gratuito e não foi desenvolvido pelos criadores da ferramenta, que é paga (desculpe por não poder citar o nome das ferramentas. Não se preocupe, isso não é muito importante). Instalei o módulo e quando fui usar, percebi alguns erros. Logo pensei: “Não me parece muito difícil de consertar, talvez eu possa consertar rapidamente e mandar as alterações para os desenvolvedores”. Como vocês já devem imaginar, o código-fonte estava criptografado.

Não consegui imaginar porque alguém criptografaria uma ferramenta assim. Ao ler a página dos desenvolvedores, descobri que a estratégia era cobrar uma mensalidade para obter suporte (ainda assim, sem o código-fonte). Não sou um militante do FOSS (acredito eu), mas acho que criptografar o código e cobrar o suporte, neste caso, é um tremendo tiro no próprio pé.

Imagino que os criadores do módulo não disponibilizam o código por medo de que algum “concorrente” venda ou ofereça suporte ao produto deles. Este risco existe. Mas esta ação não resolve o problema.

Meu primeiro pensamento quando não pude ter acesso ao código foi fazer minha própria versão. Da mesma forma que eu pensei, outra pessoa também. Tanto que ao fazer um pesquisa no google, encontrei um módulo com o mesmo propósito, mais atualizações, sem os erros que eu havia encontrado e com o código aberto.

Pra completar, ao procurar opiniões sobre o módulo de código fechado, a imagem da empresa estava sendo praticamente destruída em diversos lugares, justamente por não permitir que os usuários possam melhorá-lo. Ou seja, a empresa obteve várias desvantagens: Os “concorrentes” podem oferecer suporte da versão de código aberto, os usuários avançados não são incentivados a mandar feedback e corre um grande risco da “má reputação” da empresa chegar aos demais usuários.

Este não é o único caso que eu conheço onde criptografar o código-fonte pode acabar gerando problemas. Já vi venderem código-fonte de software GPL criptografado, por exemplo.

Não acredito que todos os softwares podem ter seus códigos abertos. Mas muitas empresas ao decidir por não compartilhar seu código, não pensam nas desvantagens que podem ter. É sempre bom lembrar que existem idéias muito boas por aí. Por que não estar receptivo a elas?

imagem: johnath