27 de maio de 2009

Linguagem ou framework?

Quem desenvolve para web, há algum tempo vive ouvindo falar de uma coisa chamada framework. Tem Struts (para java), Zend Framework (para PHP), Django (para Python), Ruby on Rails -- ou, simplesmente RoR -- (para Ruby), e por aí vai.

Entretanto você, que é desenvolvedor, vai programar na linguagem ou no framework?

Cada dia a resposta a essa pergunta fica mais difícil, pois os frameworkds que antes limitavam-se a ser um conjunto de funções para auxiliar o desenvolvedor a não realizar tarefas de "baixo nível", hoje cresceu para a geração de código completo e funcional.

Até bem pouco tempo atrás, um framework simplesmente provia serviços que abstraíam o protocolo http ou a camada de acesso a dados, ou a camada de comunicação, por exemplo.

Hoje esse cenário está muito (MUITO) diferente.

Com a popularização das linguagens de script (leia PHP, Python e Ruby, principalmente) os frameworks começaram a entregar novos serviços, tornando o desenvolvedor muito mais produtivo e aumentando o nível do que era considerado "de baixo nível".

O Django, por exemplo, com base em um modelo de banco de dados, entrega prontinho um conjunto de funcionalidades chamado ADMIN. Com o admin do Django é possível popular as tabelas do seu banco de dados sem programar quase nada. Ou seja, fazer CRUD virou tarefa de baixo nível.

O RoR também vigia seu modelo de dados, para que quando ele for alterado, as alterações sejam representadas no servidor de BD. Com isso, executar comandos de atualização de DDL também virou tarefa de baixo nível.

Há muito tempo os frameworks preocupam-se em abstrair o banco de dados utilizado, para que as aplicações possam ser portáveis entre vários servidores de BD. Isso é muito bom e preocupar-se com o BD já era, há muito tempo, tarefa de baixo nível. Agora, os frameworks foram além e implementaram um ORM completo, com sintaxe própria e extensível. No RoR é possível até chamar método que não existe e ele se vira para resolver o que você quer! Agora, programar em SQL também virou baixo nível.

Toda essa melhoria nos frameworks nos leva a uma situação inusitada. As pessoas querem aprender RoR sem aprender Ruby. Tem gente aprendendo Django sem aprender Python.
Essa situação aconteceu há alguns anos, quando ninguém queria aprender orientação a objetos, mas queria saber tudo de Java.

Parece estranho, mas é verdade.

Portanto, caro desenvolvedor, você vai programar tanto na linguagem quanto no framework. Lembre-se que sua aplicação vai passar a ser dependente de mais um componente externo. Já não basta a linguagem, o servidor de BD, as bibliotecas ou classes desenvolvidas por terceiros, agora também tem o framework.

É por isso que as pessoas dizem: "eu fiz o site em RoR" ou "eu desenvolvo em Django".

Mas nunca se esqueça que por trás do framework tem uma linguagem. E conhecê-la faz TODA a diferença na utilização dos recursos do framework.

Portanto, aprenda o framework e também a linguagem. Esse é o casamento perfeito.

1

5 de maio de 2009

Como escolher meu editor de programas


Para quem desenvolve aplicativos é muito importante a escolha de um bom editor de programas. Você já se deu conta de que pode estar usando um que não seja a melhor opção para você?

Já percebeu que para escolher a linguagem de programação que vamos trabalhar, pensamos se ela é bem aceita no mercado, se tem suporte do fabricante ou da comunidade, se é muito nova, quem usa, e coisas assim que acabam influenciando e dando a segurança (ou a impressão) de ser uma boa escolha?

E para escolher seu editor de programas? Que critérios você usou?

Eu concordo com o Andy Hunt quando ele diz no livro The Pragmatic Programmer, que um bom programador deve dominar (DO-MI-NAR) sua principal ferramenta de trabalho, que é o editor de programas.

Afinal, você vai passar a maior parte dos seus dias trabalhando nele, certo? Demora dominar um bom editor. E não é nada agradável trocá-lo por outro. Você já está acostumado com os recursos do anterior. Já sabe os atalhos de teclado de cabeça. Já tem até alguns scripts que resolvem seus problemas sem muito esforço.

Bem, talvez você realmente não saiba os atalhos de teclado nem tenha escrito scripts para automatizar tarefas. Talvez você nem saiba que seu editor tem esses recursos. Se esse é o seu caso, sinceramente, eu sugiro que você comece a pensar na quantidade de trabalho repetido que tem feito no seu dia-a-dia! E como diz o velho ditado, que tempo é dinheiro, se você está perdendo tempo...

Um editor é uma ferramenta de trabalho. Aliás, ele pode ser melhor que isso. Ele pode trabalhar para você!

Um dia, motivado por uma mudança, comecei a procurar o editor de programas definitivo para mim e resolvi relacionar alguns recursos que achei serem necessários.

Você já passou por esse momento?

Seguem abaixo algumas características que um bom editor de programas deve ter, na minha opinião:
  1. Navegação eficiente no código (mais do que as setas)
  2. Marcadores (ou bookmarks, como queiram)
  3. Undo de muitas operações
  4. Comandos de teclado para todas (eu disse todas?) as suas operações
  5. Auto-complete
  6. Auto-correção (sim, nós programadores também erramos)
  7. Syntax Highlighting
  8. Gravação de macros (é, você faz algumas coisas várias vezes e da mesma forma)
  9. Uma linguagem de script (faça seu editor trabalhar para você!)
  10. Comandos de localizar e substituir realmente poderosos (vá além do óbvio. Experimente as expressões regulares!)
  11. Folding de código (ok, nem todo mundo gosta disso)
  12. Responder rápido (isso todo programador quer, né?)
  13. Vários buffers de copy-and-paste (muito, muito útil)
  14. Várias janelas abertas ao mesmo tempo
  15. Auto-identação de acordo com a linguagem
  16. Integração com shell (prompt do DOS) e compiladores
  17. Capacidade de repetir comandos
  18. Personalizar de teclas de atalho
  19. Extensível com plugins
Há muito tempo eu usava um editor não muito conhecido, chamado Boxer. Mas aí o MS-DOS morreu e veio o Windows.
Depois, achei um bem poderoso, chamado Ultraedit.
Mais tarde, comecei a usar o Context, mas ele não era o que eu esperava. Nem de longe.
O PSPAD passou a ser meu editor oficial por alguns anos. Esse é bom, mas ainda não era o que eu precisava.
Analisei o emacs, mas não me adaptei a ele, apesar de ser muito poderoso.
Finalmente re-encontrei o Vim e resolvi ficar com ele.

Ele é um editor diferentão. É modal, meio feioso, old-fashioned, e demora para aprender a usá-lo. Mas como não pretendo mudar de editor, mesmo mudando de sistema operacional, não vejo problema nisso. É um investimento a longo prazo.

Ele está no mercado há um tempão, tem sempre melhorado e já vem com todas distribuições Linux. Ou seja, é um projeto ativo.
E funciona! No Windows, no Linux e no Mac-OS.

Ele é altamente configurável e tem todas as características que citei acima.
Não, ele não é perfeito. Nenhum é. Nem digo que o vim é o melhor editor de programas. Mas ele é bom e me adaptei a ele numa boa.

E você? Usa bem os recursos do seu editor de programas? Ou usa vários editores para conseguir realizar suas tarefas?

Use a ferramenta certa.

4 de maio de 2009

Use o teclado



Todo mundo que o computador usa o teclado, certo?
Mas será que usa como poderia?

Eu sou programador, tradutor e escrevo alguns artigos de vez em quando. Vivo escrevendo e-mails. Para mim é muito importante conseguir digitar usando os 10 dedos e com velocidade.

Minhas idéias são expressas através de minhas mãos no teclado. Quando escrevo um programa ou um artigo como esse, estou materializando minhas idéias. Portanto, se meus dedos forem muito mais lentos do que meu racioncínio, não dá certo.

Por isso, tenho um hábito visto como esquisitisse por muitos de meus colegas: procurar os atalhos de teclado dos softwares que uso.

E tenho outro também: não gosto do mouse!

Outro dia eu descobri um software para Windows chamado Keybreeze que permite você chamar qualquer programa usando o teclado. Gostei muito dele.
Atualização em 28/09/2009: no Linux (Ubuntu) eu uso o Gnome Do.

Se você tem dificuldade de digitar sem olhar para o teclado, procure um tutorial de digitação na internet. É um esforço compensador.

Fica aí a dica: se você quer ser mais produtivo, não tire as mãos do teclado!

3 de maio de 2009

O editor onipresente


Eu sou desenvolvedor de aplicativos. Por isso, um dia percebi que precisava buscar outra plataforma de trabalho, além do Windows.

Eu mexi um pouco com Unix em 1997 e não havia interface gráfica nos sistemas que eu conheci: HP-UX e IBM S/6000. Hoje, se eu tivesse que re-aprender tudo, o tempo para adotar o novo sistema seria muito grande. E eu não queria me tornar um especialista em Linux.

No meu caso a escolha natural foi o Ubuntu, pela popularidade. No entanto há outros sabores de Linux, como Fedora, Debian, Red Hat, etc. e eu não queria ficar de fora deles. Ubuntu seria apenas uma porta de entrada.

A ferramenta que um programador mais usa é o editor de programas, certo? No Windows eu usei o PSPAD por vários anos e estava muito satisfeito com ele. Mas ele não existe para outros sistemas operacionais. Sim, eu poderia usá-lo com o Wine, mas eu não queria isso.

Resultado: eu teria que aprender um novo editor. Com novos atalhos de teclado, novas opções de menu e novos recursos. Alguns faltantes e outros novos.

Como eu já era bem produtivo com o PSPAD, isso me assustou mesmo! Então resolvi procurar um editor poderoso que funcionasse bem em todos os ambientes, sem que eu precisasse reaprender tudo quando mudasse de ambiente. Seria possível, isso?

Pesquisei bastante e me deparei com duas opções que quase ninguém mais fala e eu pensei nem existirem no mundo onipresente das interfaces gráficas: vim e emacs.

A discussão entre os usuários desses editores é quase religiosa! Parece com as discussões entre torcedores de times de futebol ou entre usuários de Linux, Mac-OS e Windows.

Eu usei um pouco o emacs mas, pessoalmente, não me adaptei a ele. Achei esquisito ter que manter a tecla CTRL pressionada para eu me movimentar pelo programa.

Daí parti para experimentar o vim. Foi impressionante quando eu me deparei usando intuitivamente alguns comandos que eu uso no Gmail e no Firefox!

Quer exemplos?
No Gmail existem os atalhos de teclado "j" e "k" para navegar entre as mensagens e o "/" para pesquisar mensagens. Alguns atalhos iniciam com "g".
No Firefox você pode usar também o "/" para pesquisar na página corrente. Adivinha de onde eles pegaram esse comando? Do vim!

Daí pesquisei um pouco mais e descobri que o vim já vem junto com todas as instalações de Linux e roda até no PS3. E que ele usa muito menos recursos do que o emacs. Além disso, ele também tem uma linguagem de script e grava macros!

Do quê mais eu precisava? Apenas de re-aprender a usá-lo corretamente. Eu poderia usá-lo no Windows em modo gráfico, modo texto, em qualquer Linux e também no Mac-OS!

Dizem que usar o vim é como morar em Brasília: ou você ama, ou abandona. Eu, gostei tanto do editor como da cidade.

Sim, eu uso vim. Gosto da linha de comandos e acho que é possível ser produtivo com ela, sem usar o mouse.

O vim é bom. O emacs também. Não estou dizendo que o vim é melhor do que o emacs. Os dois são poderosíssimos, mas a curva de aprendizado em qualquer um deles é grande. Qual usar é apenas uma questão pessoal.

Sua produtividade está diretamente relacionada ao editor que você usa para escrever seus programas. Pense nisso!