Esteja preparado para uma enorme quantidade de gambiarras.

ELPA

A primeira coisa que faço numa nova instalação do Emacs é configurar o ELPA, ou Emacs Lisp Package Archive. Para quem não conhece, pense no ELPA como se fosse um apt-get da vida, guardadas as devidas proporções (como veremos a seguir).

As instruções para instalação podem ser vistas nesta página. Se tudo der certo, agora deve ser possível rodar o comando M-x package-list-packages <ENTER>. Leia este documento caso tenha dificuldades para usar atalhos e comandos do Emacs.

Após alguns instantes, a lista de pacotes disponíveis para instalação via ELPA deve ser exibida num buffer secundário.

Clojure-Mode

Coloque o cursor sobre a linha do pacote swank-clojure e pressione a tecla I para marcá-lo para instalação. Faça o mesmo com o pacote paredit. Se outros pacotes foram marcados acidentalmente, mova o cursor para as linhas correspondentes e pressione U para desfazer a marcação. Pressione X para prosseguir com a instalação.

Feito isso, ao rodar o comando M-x slime <ENTER>, o Emacs irá perguntar se você deseja que ele faça o download dos JARs de Clojure. Não adianta dizer que sim, pois não irá funcionar.

Para resolver isso, baixe manualmente os JARs de Clojure e os coloque no diretório ~/.clojure/. Em seguida, baixe o JAR mais recente projeto swank-clojure e o coloque no diretório ~/.swank-clojure/.

Pronto. Reinicie o Emacs e rode o comando M-x slime <ENTER> para iniciar um REPL Clojure dentro do Emacs!

Clojure no Emacs Slime

Vale lembrar que o Slime fornece vários recursos para edição de código, como auto-completion, exibição de docstrings, entre outras coisas. Consulte o site do projeto para mais informações.

Outros Lisps

Rode o comando abaixo para instalar duas das principais implementações open source do ANSI Common Lisp, CLISP e SBCL:

$ sudo apt-get install clisp sbcl

Finalmente, abra o arquivo ~/.emacs e cole o código a seguir na última linha:

;; paredit + lisp modes
(defvar *lisp-modes* '(clojure-mode-hook lisp-mode-hook emacs-lisp-mode-hook
                       lisp-interaction-mode-hook slime-repl-mode-hook))
 
;; config used in all lisp modes
(defun lisp-config ()
  (paredit-mode t)
  (show-paren-mode t))
 
(mapc (lambda (mode)
        (add-hook mode 'lisp-config)) *lisp-modes*)
 
;; other lisp implementations
(eval-after-load "slime"
  '(progn (setq slime-lisp-implementations
                '((sbcl ("/usr/bin/sbcl"))
                  (clisp ("/usr/bin/clisp"))))))

Swank

As últimas versões do Slime já trazem servidores Swank para diversas implementações Lisp, mas curiosamente essa parte do código não é baixada quando se instala o Slime via ELPA.

Certifique-se de que um cliente CVS esteja instalado e rode o comando abaixo para fazer o download da última versão do Slime:

$ cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime

Em seguida, vá até o diretório slime recém-criado e copie todos os arquivos deste diretório por cima dos arquivos instalados via ELPA em ~/.emacs.d/elpa/slime-<VERSION>. Aproveite e remova o arquivo slime.elc deste último diretório, já que tal arquivo é uma versão compilada de um arquivo que acabamos de sobrescrever.

Reinicie o Emacs. O comando M-x slime <ENTER> continua servindo para iniciar um REPL Clojure. Para iniciar um REPL SBCL, por exemplo, rode o comando M-- M-x slime <ENTER>, digite sbcl e pressione <ENTER>.

SBCL no Emacs Slime

“Nunca vi tanta gambiarra num lugar só…”

Tudo seria mais fácil se o ELPA disponibilizasse versões minimamente atualizadas — e não-”capadas” — de certos pacotes, por isso creio que essa complicação deva ser temporária. Atualizarei este texto quando a coisa mudar. Para melhor, espero.

Como o mercado é dominado por linguagens imperativas, é bem difícil encontrar pessoas que realmente conheçam e utilizem linguagens funcionais com certa regularidade. Mas isso não significa, de forma alguma, que não há espaço para tais linguagens. Na verdade, a tendência é que elas ganhem cada vez mais espaço.

Por que aprender uma linguagem funcional?

Em linguagens imperativas, a programação de um software consiste basicamente na definição e manipulação de seu estado interno, conduzida de modo a resolver um determinado problema. Portanto, pode-se dizer que softwares escritos em tais linguagens são movidos a efeitos colaterais, pois a forma e a ordem com que seu estado interno é modificado é o que define o funcionamento do software.

Em softwares triviais isso não chega a ser um problema, mas quando falamos de softwares grandes e complexos, essa volatilidade complica, e muito, a vida de quem os desenvolve e os mantém.

Linguagens funcionais, por outro lado, são conhecidas por evitar efeitos colaterais ao máximo, e isso nos trás uma infinidade de vantagens. Assim como na matemática, executar uma função f(x) com o mesmo argumento N vezes produz sempre o mesmo resultado, e por isso:

1. o código fica muito mais fácil de entender, debugar e testar. Tudo o que você precisa saber sobre uma função está nos seus argumentos;
2. o código, por também contar com estruturas de dados imutáveis, pode ser executado de forma concorrente, com poucas ou quaisquer modificações, e você nunca terá de se preocupar com locks, condições de corrida, deadlocks e coisas do tipo;
3. o compilador pode fazer otimizações impossíveis de serem feitas em linguagens imperativas, como automaticamente paralelizar ou reordenar chamadas a funções;

Enfim, esse é só um resumo das vantagens que linguagens funcionais têm sobre linguagens imperativas. Confira os links no final deste post para saber mais.

Escolhendo a linguagem

Clojure, Erlang, Haskell, J, (Common) Lisp, Scheme. E essas são somente algumas das linguagens com forte base funcional disponíveis por aí.

Mas qual delas escolher? Cada pessoa segue um ritual diferente ao escolher uma nova ferramenta e por isso não sou eu quem irá te dizer qual delas escolher. O que eu posso fazer é dar algumas sugestões:

• Quer saber como tudo começou? Aprenda Common Lisp.
• Quer uma linguagem parecida com Lisp, mas que rode na JVM? Clojure pode ser uma boa.
• Quer uma linguagem com uma sintaxe sucinta e poderosa? Dê uma olhada em J.
• Quer uma linguagem que facilite a construção de softwares distribuídos e de alta disponibilidade? Vá de Erlang.
• Quer uma linguagem que mude a forma com que você pensa sobre programação? Aprenda qualquer uma delas!

Erlang e Haskell estão na minha mira mas, no momento, eu optei por aprender Clojure.

Praticar é essencial

Ok, escolhida a linguagem de programação, o próximo passo é ler muito e praticar mais ainda.

Para quem está interessado em aprender Clojure, material não falta. Apesar de bem nova (apenas 2 anos de existência), a linguagem vem ganhando popularidade e muito vêm sendo escrito sobre ela. Aliás, o primeiro livro sobre Clojure foi publicado recentemente pela Pragmatic Bookshelf. (Pode comprar sem medo, o livro é excelente)

Agora, independente da linguagem escolhida, uma forma interessante de aplicar os conhecimentos recém-adquiridos é tentar resolver os problemas propostos pelo Project Euler, um website com centenas de problemas do tipo “What is the value of the first triangle number to have over five hundred divisors?”. No começo eu sofri um pouco para pegar as manhas da linguagem, mas depois de ter resolvido uns 10-15 problemas desse tipo, eu sinto que as coisas estão começando a fazer sentido.

Aos interessados, eu acabei de disponibilizar no Github um projeto contendo as soluções, todas em Clojure, para alguns dos problemas propostos.

E vocês, o que recomendam?

Depois de algumas semanas pesquisando sobre Programação Funcional, eu me sinto como se tivesse deixado de lado um vício: meio assustador no início, mas melhor a cada dia que passa!

Aos que já conhecem ou trabalham regularmente com linguagens funcionais, que dica vocês dão para quem acabou de tomar a pílula vermelha?

Referências

• On Lisp Book (Obrigatório!);
• Functional Programming For The Rest Of Us (Obrigatório!);
• The Promises Of Functional Programming (Atualização);
• Programming Clojure;
• Clojure – Functional Programming for the JVM;

O poder do Python

Quem não está acostumado a trabalhar com Django pode estranhar o fato deste utilizar um script Python para fazer a configuração do projeto: o famoso settings.py. E essa estranheza é justificada, afinal muitos desenvolvedores — principalmente os que vêm de outras linguagens — estão acostumados a trabalhar com ferramentas onde tal tarefa é feita com arquivos XML ou coisa assim.

O fato é que utilizar um script Python para tal é uma excelente idéia, pois você deixa de depender de algum tipo de estrutura estática (e muitas vezes inconveniente) para algo mais flexível e poderoso, que, no caso, é a própria linguagem de programação. Isso faz uma grande diferença em situações onde tal flexibilidade é necessária.

Quer exemplos?

Ambientes de desenvolvimento/produção

Eis como fizemos aqui. Primeiramente, defina a variável de ambiente WORKSPACE. No Linux, isso pode ser feito através do arquivo ~/.bashrc:

export WORKSPACE=1

A idéia é possibilitar a criação de perfis de configuração, cada qual correspondente a um ambiente de execução. A existência ou não da variável de ambiente é o que define o ambiente no qual a aplicação roda.

Continuando com o exemplo, no diretório raíz do seu projeto Django, crie o módulo environment.py, com o seguinte conteúdo:

import os
 
def production_mode():
    return not development_mode()
 
def development_mode():
    return 'WORKSPACE' in os.environ

Finalmente, modifique o módulo settings.py para que este utilize tais métodos onde for necessário definir configurações diferentes para ambientes de execução diferentes:

from environment import production_mode
 
# Configurações padrão
PREPEND_WWW = False
DEBUG = True
 
# Configurações para ambiente de produção
if production_mode():
    PREPEND_WWW = True
    DEBUG = False
 
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'pages.middleware.PageFallbackMiddleware',
    'django.contrib.redirects.middleware.RedirectFallbackMiddleware',
)
 
# Habilitando caching em modo de produção
if production_mode():
    MIDDLEWARE_CLASSES += (
        'django.middleware.cache.UpdateCacheMiddleware',
        'django.middleware.cache.FetchFromCacheMiddleware',
    )

Não tenha medo de utilizar os recursos do Python onde eles se fizerem necessários, apenas tomando cuidado para não exagerar e acabar criando acidentalmente um Algoritmo Genético para configurar seu projeto!

Informações secretas (IPs, usernames, passwords, etc)

Praticamente não há quem ignore a importância de um bom sistema de controle de revisões (Subversion, Git, etc). O problema é que, muitas vezes, não tomamos o devido cuidado com o que colocamos dentro dos nossos repositórios. Sempre que possível, informações secretas — como endereços de IP, usernames e passwords — devem ser mantidas fora dos repositórios.

Em um projeto Django, as informações de acesso a servidores de e-mail e bancos de dados devem estar disponíveis através do módulo  settings.py. Felizmente, existe um jeito simples de manter essas informações separadas das outras configurações.

Primeiramente, abra o arquivo settings.py do seu projeto e remova todas as senhas e outras informações que você considere secretas. Em seguida, cole o seguinte trecho de código no final do arquivo:

try:
    from private import *
except ImportError:
    pass

Feito isso, crie o módulo private.py no diretório raíz do seu projeto Django. Coloque nele as configurações que você removeu do settings.py no passo anterior. Exemplo:

from environment import production_mode
 
SECRET_KEY = 'secret_key_do_seu_projeto'
 
EMAIL_HOST = 'localhost'
EMAIL_HOST_PASSWORD = 'senha_email_local'
 
DATABASE_HOST = 'localhost'
DATABASE_USER = 'username_db_local'
DATABASE_PASSWORD = 'senha_db_local'
 
if production_mode():
    EMAIL_HOST = 'ip_email_producao'
    EMAIL_HOST_PASSWORD = 'senha_email_producao'
 
    DATABASE_HOST = 'ip_db_producao'
    DATABSE_USER = 'username_db_producao'
    DATABASE_PASSWORD = 'senha_db_producao'

Certifique-se de adicionar o arquivo private.py no ignore (.cvsignore para CVS, .gitignore para Git, etc) correspondente ao sistema de controle de revisões sendo utilizado. Faça o commit e pronto.

Para finalizar, se o seu repositório já contém uma versão “insegura” do módulo settings.py, mude as senhas dos seus servidores.

E você, o que recomenda?

Tem alguma dica útil para compartilhar conosco? Nós adoraríamos ouvir o que você tem a dizer!

Modelo-exemplo de banco de dados

Nem irei perder tempo explicando esse modelo, até porque não há nada nele que precise de explicações. Bem, na verdade, há uma coisa sim: por que raios existe uma tabela só para armazenar os tipos de contato?! Qual é o problema com os bons e velhos códigos fixos (1-email, 2-celular, N-…)?

Um argumento a favor dessa abordagem é que “o usuário pode querer cadastrar um contato cujo tipo não seja suportado pela aplicação”. Mas será mesmo que colocar essa informação no banco de dados resolve o problema? E, mais importante, existe algum efeito colateral?

Bem, na minha experiência, embora essa abordagem pareça boa o bastante para resolver a questão num sistema simples de “cadastro”, a bomba explode quando o sistema passa a depender dessas flags para a realização de lógicas de negócio que vão além do famigerado CRUD.

Anti-pattern?

E se eu te dissesse que usar tabelas no banco de dados para armazenar flags é um anti-pattern? Digo isso pois, como veremos a seguir, as vantagens são irrisórias frente às desvantagens:

Poluição do modelo de dados. Um sistema não muito grande provavelmente conta com mais de uma centena de tabelas. Isso todo mundo sabe. O que todo mundo também sabe, mas parece ignorar, é que não seria surpreendente constatar que 10-15% dessas tabelas serviriam apenas para armazenar flags (situação de pedido, estado civil, forma de pagamento, e por aí vai). E o pior: essas tabelas, quase sempre, possuem exatamente a mesma estrutura, que apelidei carinhosamente de tabelas código-descrição. A tabela TipoContato, mostrada no diagrama que encabeça este texto, é um exemplo desse tipo de tabela.

Ruim para o meio ambiente. Poluir o modelo de dados com dezenas de tabelas código-descrição torna o modelo desnecessariamente maior e mais difícil de compreender. Imprimir um modelo desses consome mais papel, o que é ruim numa época onde o desenvolvimento sustentável está em voga. Quantas árvores suas tabelas código-descrição já derrubaram?

Ultra-normalização. Quanto mais tabelas uma consulta envolver, mais joins, e mais dados indo e vindo para o banco de dados. E, considerando que o banco de dados é (quase) sempre o gargalo, isso não é muito bom para a performance do seu sistema.

Poluição do modelo de objetos. As linguagens com suporte à orientação a objetos figuram entre as mais usadas atualmente, por isso eu diria que muito provavelmente você utiliza esse paradigma no desenvolvimento dos seus sistemas. Se este for o caso, também é bem provável que você utilize algum framework ORM para facilitar a tarefa de integração do software com o banco de dados. Como muitos frameworks ORM exigem um modelo de objetos compatível com o modelo de dados, bem, você acaba sendo forçado a poluir seu modelo de objetos com classes burras que apelidei carinhosamente de (pasmem!) classes código-descrição.

Se tem tabela, tem cadastro. Bom, já que todas as flags possuem suas tabelinhas no banco de dados, isso significa que você, pobre desenvolvedor, terá que fazer “cadastros” para todas elas (e reze para não precisar fazer relatórios, também). Além da chatisse costumeira de se fazer um cadastro, devemos levar em consideração que fazê-los consome tempo e, tempo é dinheiro.

Código quebradiço. Essa é feia. Vamos supor que, nessa nossa aplicação de gerenciamento de clientes/contatos, você queira incluir uma funcionalidade que permita enviar um torpedo ao cliente caso ele possua um contato do tipo Celular. Como mostrado no trecho de código a seguir, você fatalmente terá que incluir no código-fonte referências a registros armazenados no banco de dados, tornando o código quebradiço. Consequentemente, um único UPDATE ou DELETE executado por engano no banco de dados pode fazer o sistema cair de joelhos.

Enviando torpedos a um cliente:

public void enviarTorpedo(Cliente cliente, String texto) {
    // Tenta localizar um contato do tipo celular
    for (Contato contato : cliente.getContatos()) {
         // WTF!! Estamos referenciando um registro do banco de dados!!
         if (contato.getCodigo() == 10L) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

A solução

Com certeza existem outros problemas que eu acabei deixando passar, mas espero que os problemas que listei já sejam o suficiente para te convencer que guardar flags em tabelas no banco de dados é uma má idéia.

Mas, como resolver isso então? Simples: use enums sempre que possível. A única desvantagem é que os usuários não poderão mais sair criando novas flags a torto e a direito, o que não é realmente um problema frente às vantagens que as enums oferecem.

Poluição do modelo de dados? As flags virariam campos numéricos ou alfanuméricos nas tabelas que as usam e o framework ORM se encarregaria de converter esses campos de/para objetos enum. Diga adeus às tabelas código-descrição.

Ruim para o meio-ambiente? Sem as tabelas código-descrição, seu modelo fica menor, mais enxuto, facilitando a visualização e gastando menos papel ao imprimí-lo. A natureza agradece.

Ultra-normalização? Usando enums você diminui a quantidade de ligações entre as tabelas, tornando as entidades um pouco mais auto-contidas. Menos tabelas, menos joins, mais performance.

Poluição do modelo de objetos? As enums tomariam o lugar das classes código-descrição, o que por si só tornaria o código mais claro, pois, ao contrário das classes “normais”, as enums possuem um propósito bem definido.

Se tem tabela, tem cadastro? Ué, por que você está com esse sorriso estampado no rosto?

Código quebradiço? Quem mais se beneficia das enums são os trechos de código onde as lógicas de negócio são definidas. Mais especificamente, seu código deixa de referenciar registros do banco de dados, eliminando a fragilidade e melhorando a legibilidade. As enums também impedem que valores arbitrários sejam usados em atribuições e comparações, tornando o código ainda mais confiável. Um exemplo disso pode ser visto no código a seguir, que é uma adaptação da atrocidade do código mostrado anteriormente:

public void enviarTorpedo(Cliente cliente, String texto) {
    for (Contato contato : cliente.getContatos()) {
         // Bem melhor agora!
         if (contato.getTipo() == TipoContato.CELULAR) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

O fato de a sua linguagem do coração não ter suporte nativo a enums não deve ser um impedimento para que você deixe de usufruir de suas vantagens. Existem formas de se conseguir uma funcionalidade semelhante sem muito esforço.

Conclusão

Desenvolver software é, antes de tudo, fazer escolhas. É o custo/benefício, os prós e contras antes de se tomar uma decisão. A boa notícia é que o nosso produto, o software, é maleável o suficiente para permitir que decisões ruins sejam re-feitas sempre que elas resultam em problemas como o descrito neste texto.

Bom carnaval!

Um dos aspectos que se encontram em constante evolução é a parte de conectividade. O Network Manager, gerenciador de conexões utilizado nas versões mais recentes do Ubuntu, torna simples a tarefa de se conectar com praticamente qualquer tipo de rede, inclusive com as recém chegadas redes 3G.

Apesar de facilitar a vida na maioria dos casos, o Network Manager presente na última versão do Ubuntu parece não funcionar do jeito que deveria, principalmente quando tentamos conectar numa VPN PPTP (Point-to-Point Tunneling Protocol). Na versão anterior do Ubuntu, eu conseguia conectar em VPNs PPTP sem problemas, coisa que deixou de acontecer após a instalação da última versão do Ubuntu.

A boa notícia é que, depois de perder algumas horas pesquisando, eu consegui resolver o meu problema. E é isso que mostrarei a seguir!

Atualizando o Network Manager

A primeira coisa que fiz foi tentar substituir a versão pré-instalada do Network Manager pela versão distribuída pelos próprios desenvolvedores.

Para isso, abra o Synaptic e selecione o menu Settings – Repositories. Em seguida, selecione a aba Third-Party Software e clique no botão Add. Finalmente, cole a linha abaixo e confirme:

deb http://ppa.launchpad.net/network-manager/ubuntu intrepid main

Feche a tela e pressione CTRL+R para baixar as informações atualizadas dos repositórios. Após o término, pressione CTRL+G para iniciar o processo de atualização dos pacotes. Quando a instalação terminar, o Ubuntu irá pedir que você faça o reboot. Obedeça.

Configurando a VPN

Após o reboot, o sistema já deve estar funcionando com a nova versão do Network Manager. Clique no Applet do Network Manager e selecione o menu VPN Connections – Configure VPN. Aqui, basta configurar de acordo com as instruções que você deve ter recebido do pessoal responsável pela parte de redes da sua empresa.

Para não terminar o post aqui, eu vou mostrar como eu fiz para configurar a conexão VPN que estou utilizando atualmente. É obvio que cada empresa configura sua VPN de um jeito diferente, por isso o que segue abaixo é apenas um exemplo de configuração.

Informações básicas

Na primeira tela você deve informar os dados para conexão com a VPN, como IP do servidor da VPN, usuário e senha:

Informações básicas

Clique no botão Advanced para configurar em detalhes como deverá ser a comunicação entre seu computador e a VPN:

Opções avançadas

No meu caso, o servidor da VPN foi configurado para fazer autenticação via CHAP; marque ou desmarque as opções disponíveis na tela, se necessário.

Configurando as rotas

Prosseguindo, na aba IPv4 Settings você poderá configurar o seu IP na VPN. No meu caso, o IP local, juntamente com o servidor DNS e Gateway, são fornecidos automaticamente pelo servidor. Por isso eu optei por manter a opção Automatic (VPN) no campo Method.

Neste ponto você já deve ter a VPN funcionando, mas com um pequeno inconveniente: pelo menos aqui, a VPN passou a ser acessível através da rota padrão (IP 0.0.0.0). Isso significa que todo o tráfego é direcionado para a VPN!

Para solucionar esta questão, é preciso configurar uma rota através da qual a VPN possa ser acessada, mantendo inalterada a rota padrão. Para isso, basta clicar no botão Routes… e configurar a(s) rota(s):

Declarando rotas

Aqui, eu substituí as rotas obtidas automaticamente pelas rotas informadas na tabela. No meu caso, a faixa de IP da VPN é 192.168.0.X, por isso o Prefix foi configurado como 24 (aprenda aqui o que esse número significa). O campo Gateway foi configurado para o “IP remoto virtual” da VPN, fazendo com que os pacotes destinados a IPs 192.168.0.X sejam redirecionados para a VPN. O campo Metric foi deixado como zero.

Feito!

Isso deve bastar. Tente conectar com a VPN:

Conectando na VPN

Não conectou? Confira os dados de conexão e modifique os parâmetros avançados de conexão (métodos de autentiação, encriptação, etc). Tente encontrar o motivo nos logs /var/log/messages e /var/log/syslog. Conectou? Ótimo, agora faça o seguinte teste:

1. Dispare um ping contra algum computador da VPN;
2. Dispare um ping contra algum computador da sua rede local;
3. Dispare um ping contra algum computador da Internet (ex: google.com);

O teste falhou? Com certeza tem algo errado com a(s) sua(s) rota(s). Ainda conectado na VPN, utilize os comandos ip route e/ou route -n para ver como ficaram as rotas; faça os ajustes necessários, reze e tente novamente. O teste foi um sucesso? Parabéns, você conseguiu!

Update: Aos usuários do Fedora 10, o procedimento de configuração é praticamente o mesmo. O que muda é a configuração das rotas:

Declarando rotas (Fedora 10)

Na verdade, ninguém parecia se importar em automatizar tarefas “mecânicas” como o deployment, coisa que mudou de figura ao passo que metodologias ágeis — juntamente com técnicas como Integração Contínua — passaram a se tornar populares. Desde então, algum esforço vem sendo investido para criar ferramentas para automatização de muitas dessas tarefas.

Atualização: Trechos de código adaptados para as versões mais recentes do Fabric (22/06/2010).

Fabric: ferramenta Python para deployment

Apesar de já ter utilizado algumas dessas ferramentas no desenvolvimento de projetos em Java, plataforma na qual eu possuo uma experiência maior, eu ainda não conhecia nenhuma ferramenta em Python que me permitisse automatizar o deployment de uma aplicação.

Como eu estava começando a ficar de saco cheio de ter que atualizar os arquivos de uma aplicação Django via SCP, eu resolvi que já era hora de ir atrás de alguma ferramenta que me ajudasse a automatizar esse processo. Finalmente, depois de muita procura, eu encontrei Fabric, uma ferramenta mais ou menos parecida com um Capistrano “capado”.

A instalação do Fabric é bem simples para quem costuma usar o easy_install:

$ sudo easy_install Fabric

Basta executar esse comando para que os fontes da última versão do Fabric (0.0.9 no momento da publicação deste texto) sejam baixados e instalados.

Atenção: Quem utiliza máquinas Windows, provavelmente precisará do Cygwin, já que o Fabric assume o uso de ambientes Unix.

Fabric a 3.000 pés

Neste momento você já deve conseguir executar o comando fab no terminal. Se tudo correu bem até aqui, estamos prontos continuar.

Vamos começar criando o arquivo fabfile.py no diretório-raíz da aplicação. Coloque o seguinte conteúdo neste arquivo:

from fabric.api import *
 
env.project = 'project_name',
env.package = '$(project).zip',
 
# Remote servers
env.user  = 'usuario_ssh',
env.hosts = ['servidor1.com', 'servidor2.com'],
 
 
def deploy():
    "Deploys the application to the production servers."
    build()
 
def build():
    "Builds the application."
    prepare()
 
def prepare():
    "Prepares the build directory."
    clean()
 
def clean():
    "Removes the build directory."
    pass

Cada método definido no arquivo é equivalente a uma task do Capistrano. No início temos as variáveis env.* necessárias para o script. Destaque para a variável env.hosts, que indica os servidores nos quais os comandos remotos devem ser executados.

Ok, tente executar o comando fab -l no terminal, no mesmo diretório onde se encontra o arquivo fabfile.py. Se tudo correr bem, você receberá a seguinte saída:

$  fab -l
Available commands:
   build      Build the application.
   clean      Remove the build directory.
   deploy     Deploy the application to the production servers.
   help       Display Fabric usage help, or help for a given command.
   license    Display the Fabric distribution license text.
   list       Display a list of commands with descriptions.
   prepare    Prepare the build directory.
   set        Set a Fabric variable.
   shell      Start an interactive shell connection to the specified hosts.
   warranty   Display warranty information for the Fabric software.

Veja que as tasks que criamos estão disponíveis para serem executadas via linha de comando. Para executar as tasks clean e deploy, por exemplo, utilizaríamos o seguinte comando:

$  fab clean deploy

Simples, não é? Antes de vermos um exemplo de script completo, vamos conhecer os três principais métodos utilizados em scripts Fabric: local, run e put:

• local: Serve para executar comandos na máquina local. Ex: local('mkdir build');
• run: Igual ao local, mas executa os comandos nas máquinas remotas (indicadas na variável env.hosts);
• put: Envia um arquivo para as máquinas remotas. Ex: put('arquivo.zip', '/home/user/app.zip').

Finalmente, o script completo!

Antes de mostrar o script que eu venho utilizando para fazer o deployment de uma aplicação Django, veja como seus arquivos e diretórios estão organizados: (isso deve ajudar a entender melhor o script)

Estrutura do projeto

E, finalmente, o script:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
"""Build script.
"""
 
from fabric.api import *
 
 
env.project = 'destaqueweb'
 
# Build output directory
env.build_path = 'build'
env.package    = '%s.zip' % env.project
env.local_path = '%s/%s' % (env.build_path, env.package)
 
# Media
env.media_src   = 'media'
env.media_root  = 'public_html'
env.media_path  = '%s/%s/%s' % (env.media_root, env.project, env.media_src)
env.media_build = '%s/%s' % (env.build_path, env.media_path)
 
# Application code
env.app_root  = 'wsgi_apps'
env.app_path  = '%s/%s' % (env.app_root, env.project)
env.app_build = '%s/%s' % (env.build_path, env.app_path)
 
# Remote servers
env.hosts       = ['destaquenet.com']
env.destination = '/home/destaquenet'
 
 
def clean():
    """Removes the build directory.
    """
    local('rm -fR %s' % env.build_path)
 
def prepare():
    """Prepares the build directory.
    """
    clean()
    local('mkdir -p %s' % env.media_build)
    local('mkdir -p %s' % env.app_build)
 
def build():
    """Builds the application.
    """
    local('cp -R %s/* %s/%s' % (env.project, env.build_path, env.app_path))
    local('cp -R %s/* %s/%s' % (env.media_src, env.build_path, env.media_path))
    local('find %s -name *.pyc -delete' % env.build_path)
    local('find %s -path *upload* -delete' % env.build_path)
    local('find %s -path *fixtures* -delete' % env.build_path)
    local('cd %s;zip -r %s %s %s' % (env.build_path, env.package, env.media_root, env.app_root))
 
def reload_app():
    """Reloads the app.
    """
    run('touch %s/%s/%s/index.wsgi' % (env.destination, env.media_root, env.project))
    run('python %s/%s/manage.py ping_google /sitemap.xml' % (env.destination, env.app_path))
 
def deploy():
    """Deploys the application to the production server.
    """
    build()
    put(env.local_path, env.destination)
    run('cd %s; unzip -uo %s; rm %s' % (env.destination, env.package, env.package))
    reload_app()

Este código deve ser facilmente entendido por quem tem trabalha com uma certa facilidade no terminal.

Basicamente o que o código faz é organizar os arquivos da aplicação para que estes fiquem dispostos da mesma forma utilizada pelo servidor de produção, enviar os arquivos dentro de um pacote ZIP para os servidores e descompactá-los no local correto, além de executar um touch no script WSGI para que o Apache recarregue a aplicação.

Tudo pronto. Agora basta executar fab deploy no terminal para subir a aplicação para o(s) servidor(es) desejado(s).

Fabric e ambiente de homologação

Uma coisa que vem se tornando comum é o uso de diferentes ambientes onde uma aplicação costuma ser implantada (ex: ambiente de homologação). Se sua empresa costuma trabalhar dessa forma, o Fabric ainda pode te ajudar.

Por exemplo, vamos supor que sua empresa possua um servidor de produção e um servidor de homologação. Podemos, então, adequar o script para que ele possa trabalhar com ambos os ambientes:

# ...
env.user  = 'production',
env.hosts = ['app.com']
 
def staging():
    # deploy to staging servers
    env.user  = 'staging'
    env.hosts = ['staging.app.com']
 
# other tasks...

Fazendo as mudanças mostradas acima, para executar o deployment no ambiente de homologação basta rodar o comando fab staging deploy; o deployment em ambiente de produção continua disponível através do comando fab deploy.

Isso é possível pois podemos substituir o valor de uma variável (ou configurar novas variáveis) a qualquer momento. Então, quando executamos o comando fab staging deploy, o Fabric executa a task staging, substituindo o valor das variáveis env.user e env.hosts, fazendo com que os comandos contidos na task deploy sejam executados nos servidores de homologação em vez de nos servidores de produção.

Essas situações, embora aparentam ser ruins em um primeiro momento, são excelentes oportunidades para nos ensinar algumas coisas que provavelmente não aprenderíamos de outra forma. Aliás, talvez seja até mais fácil aprender com nossos próprios erros do que ler sobre isso em algum livro ou artigo. O problema é que nem sempre é fácil saber tirar algo de bom de situações problemáticas.

Por isso, tentarei fazer um gancho entre esse assunto e a área de desenvolvimento de softwares, mostrando algumas das lições em que aprendi errando. Também seria interessante se os leitores que se identificarem com o assunto também compartilhassem algumas lições que aprenderam em períodos turbulentos. Afinal, errar faz bem!

Lição número 1: confie no código e não no documento

Deixe-me contar uma experiência interessante que tive na faculdade. Certa vez, um de nossos professores chegou na aula, colocou no projetor um Diagrama de Classes e um Modelo Entidade-Relacionamento e disse para a sala:

Esse é o modelo de um sistema de locadora. Nesses diagramas vocês tem tudo o que é preciso pra fazer isso funcionar. Não quero nem saber se vocês não gostam do cara que está sentado do seu lado, se acha que ele tem chulé ou mau hálito; eu quero que vocês aí se organizem e me entreguem isso funcionando até o final da aula.

Enfim, todo mundo se levantou e começou a andar de um lado para o outro e, alguns momentos depois, tínhamos nos organizado para dar início a programação. Pois bem… depois de algum tempo programando o que estava nos diagramas, o professor se volta para a sala e diz, em tom de sarcasmo:

Vem cá, vocês não encontraram nada estranho, não?

Praticamente todo mundo da sala havia percebido que alguns relacionamentos estavam faltando, outros sobrando, outros com a multiplicidade incorreta, entre outras coisas. Ninguém só não havia dito nada antes por pensar que o diagrama era indefectível. Se isso aconteceu em um “projeto de mentira” com duas dúzias de pessoas, quem imagina o que pode acontecer em projetos com dezenas e dezenas de pessoas envolvidas?

O fato é que os erros foram colocados lá propositalmente e isso acabou me fazendo perceber que nem sempre um documento representa fielmente um sistema. O que sempre representa fielmente um sistema é o seu código-fonte!

Durante um tempo, trabalhei numa empresa onde praticamente tudo o que precisava ser desenvolvido era entregue aos programadores na forma de textos (para fins de documentação, diziam). Para você perceber a gravidade da situação, se eu implementasse exatamente o que estava escrito nas folhas que recebia, a chance do sistema sequer compilar era altíssima. Além do mais, as especificações normalmente vinham incompletas, o que fazia com que nós tivéssemos de nos preocupar não em simplesmente programar, mas também de tentar driblar possíveis falhas na especificação.

Eu confesso que, naquele tempo, a minha vontade era dar um tiro na minha própria cabeça. Mas hoje, olhando para trás, percebo que isso fez com que eu adquirisse algumas habilidades que não seriam desenvolvidas se as especificações chegassem perfeitas em minhas mãos.

Lição número 2: escreva testes automatizados

Novamente remetendo aos tempos da faculdade, eu não poderia ter escolhido um tema melhor para o meu TCC do que o desenvolvimento de um framework. Me lembro que fui alertado dezenas de vezes pelos professores de que tratava-se de algo inusitado e que eu não teria direito de reclamar caso algo saísse errado. Bem ameaçador, não acha?

Apesar de assumir o desafio sozinho – pois a faculdade não dispunha de um orientador com experiência em design de frameworks – tudo correu bem nas primeiras semanas de desenvolvimento, afinal o código estava bonito e funcionava bem. O que mais eu poderia querer? Entretanto, um sério (e óbvio) problema foi se instalando sem que eu percebesse: a ausência de testes automatizados.

No começo, quando o framework possuía apenas algumas dezenas de classes – era fácil localizar e corrigir os problemas que apareciam. Mas, quanto mais o código crescia, menos controle eu tinha sobre ele. Fazer experimentações no código já não era mais seguro.

Nessa época eu já sabia como escrever testes e tudo mais. O meu grande equívoco foi pensar que, se poupasse o tempo utilizado na escrita dos testes, eu teria mais tempo para entregar aquilo que prometi no começo do ano. Obviamente, eu não poderia estar mais errado.

Escrever testes automatizados (e até mesmo levá-los a outro nível, como acontece com o TDD) é essencial para que as aplicações evoluam de forma consistente. Sem a segurança que tais testes proporcionam, é impossível garantir que o que foi feito hoje continue funcionando amanhã. Não testar o código é comparável a um jogo de tabuleiros, onde, num momento de azar, você acaba caindo numa casa que diz “volte à primeira casa”.

A grande lição que eu tirei disso foi aprender que os testes não servem unicamente para comprovar que tudo está funcionando (pois isso eu já sabia). Eu aprendi que deixar de escrever testes alegando falta de tempo é burrice. Falando nisso, ainda encontramos pessoas que dizem que testes são ruins porque “é mais código para dar manutenção”, ou “escrever testes consome tempo que não temos” ou ainda “mas quem vai testar os testes?”. Não irei responder a essas perguntas, mas posso dizer que são poucas as coisas que fazem tão bem a um software quanto a criação de testes automatizados.

Lição número 3: desenvolva software para o cliente, não para a infraestrutura

Algumas pessoas, ao se iniciar um novo projeto, já tenta desde o início juntar e configurar o framework de injeção de dependências, o framework web, o framework ORM, e por aí vai. A minha pergunta é: pra quê? Confesso que eu mesmo já fiz isso, mas devo dizer que trabalhar dessa forma não faz muito sentido na maioria dos casos.

Voltando aos tempos de faculdade, uma outra coisa que eu gostava era que nós montávamos os sistemas sem pensar em bancos de dados, latência da rede, essas coisas. Nosso banco de dados era nada mais que algumas instâncias de LinkedHashSet! Então, considerando que algumas boas práticas foram usadas e que o sistema esteja funcionando em memória, trocar o mecanismo de persistência (ou lidar com qualquer outra questão de infraestrutura) era fácil.

Por exemplo, em um sistema de locadora, o caso de uso Alugar Filme não fará nada de diferente caso estejamos persistindo os objetos em um banco de dados em vez da memória. Da mesma forma, o caso de uso Reservar Filme (que envia uma mensagem para o usuário informando quando o filme está disponível) não mudará se trocarmos a implementação atual – que executa…

System.out.println("Filme disponível");

…para uma outra que utiliza a API JavaMail para enviar uma mensagem via SMTP. O que importa é que os objetos estão sendo armazenados em algum lugar e que o usuário é notificado de algum jeito quando o filme que ele reservou está disponível. Acredite, isso é o bastante durante boa parte do desenvolvimento de uma aplicação.

Lição número 4: seja preguiçoso

Uma coisa interessante que aprendi foi que nem todo programador preguiçoso é um bom programador, mas todo bom programador é preguiçoso!

Os bons desenvolvedores possuem um faro aguçado que os permite identificar situações nas quais soluções melhores podem ser adotadas de modo a diminuir esforços, tornando o código (e a aplicação de um modo geral) mais conciso e organizado. Alguns chamam tais situações de cheiros (ou smells), termo este que “pegou” após a publicação do livro Refactoring: Improving the Design of Existing Code, de Martin Fowler.

Para identificar tais situações, vamos começar do básico: o que um desenvolvedor de software mais costuma odiar em seu trabalho? Trabalho repetitivo. Se você precisa fazer uma determinada tarefa e tal tarefa exige a repetição de procedimentos que você suspeita serem supérfluos, então faça um favor para si mesmo: deixe sua preguiça trabalhar por você!

Não sei se você é assim, mas eu costumo aprender as coisas mais rapidamente através de exemplos… então, vamos a eles.

Imagine que você tenha sido selecionado para trabalhar no deployment de uma aplicação. Se você já tentou implantar uma aplicação “no braço”, certamente sabe que, se você for fazer o trabalho manualmente, terá de fazer sempre as mesmas coisas, indefinidamente. O deployment de uma aplicação simples poderia ser exemplificada da seguinte forma:

1. Organizar as classes compiladas em uma estrutura de diretórios específica;
2. Copiar bibliotecas que devem estar disponíveis a nível de servidor (como drivers JDBC) no diretório de bibliotecas do Container;
3. Disponibilizar as bibliotecas usadas pela aplicação em um diretório específico;
4. Mover os descritores e arquivos de configuração aos locais apropriados;
5. Gerar um WAR ou EAR;
6. Implantar o WAR ou EAR no Container;
7. (Re)iniciar o Container (caso este não suporte hot deployment).

Veja que fazer o deployment de uma aplicação não é assim tão complicado, mas perceba que você terá de fazer essas mesmas tarefas sempre que você precisar rodar a aplicação. Trata-se de algo completamente mecânico e chato.

Neste exemplo, você teria duas opções: continuar fazendo isso manualmente até o dia da sua morte, ou criar um script para automatizar essa tarefa para você. O que você prefere?

Cuidado com os extremos!

Uma coisa importante é não levar essa lição ao extremo (como qualquer outra coisa). Querer achar uma solução mais simples para todos os problemas nem sempre é a melhor saída. Já dizia Albert Einstein:

Faça as coisas o mais simples que você puder, porém não se restrinja às mais simples.

Lição número 5: não tente adivinhar o futuro

Um dos meus professores de faculdade nos contou sobre uma experiência que ele havia feito com outra classe. Ele propôs que os alunos, em grupos, implementassem um sistema qualquer, cuja única restrição era, ao se partir para a fase de implementação, o código deveria refletir exatamente o modelo criado no início do processo, e este, por sua vez, não poderia mais ser alterado! Bem no estilo Waterfall mesmo. Loucura, não? Embora a tarefa não parecesse difícil para os alunos em um primeiro momento, nem é preciso dizer o quanto estavam enganados em relação a isso.

Adivinhem o resultado da experiência? Sistemas que pareciam “faltar uma perna”. Quer dizer, todos os sistemas funcionavam, mas não resolviam os problemas que deveriam. O interessante é que todos os projetos acabaram falhando, apesar de a maioria desses alunos terem escolhido desenvolver algo que conheciam bem (por terem experiências profissionais e tudo mais).

Graças às metodologias ágeis, essa coisa de se tentar prever o futuro está perdendo a força. Acho que todo mundo já entendeu que isso não serve de nada, que mudanças são inevitáveis. O melhor a fazer, então, é saber reagir frente a elas.

Lição 6: aprenda que sempre…

… há algo a aprender.

Habilitando o modo de debug

Existem duas maneiras de se habilitar o modo de debug no Glassfish: através do painel de administração ou durante a inicialização do domínio.

Para habilitar o modo de debug por padrão, através do painel de administração, basta marcar o campo Debug na tela JVM Settings e clicar em Save:

Habilitando o modo de Debug

Basta reiniciar o domínio para ver que o servidor abre a porta 9009, através da qual podemos conectar um debugger:

asadmin start-domain domain1

Eis um resumo da saída ecoada pelo Glassfish:

Starting Domain domain1, please wait.
Log redirected to .../server.log.
Redirecting output to .../server.log
Listening for transport dt_socket at address: 9009
Application server is listening at address 9009 for debugger to attach using transport dt_socket
...

A outra forma de se habilitar o modo de debug é fornecer o parâmetro --debug ao iniciar o domínio. Por exemplo:

asadmin start-domain --debug domain1

Conectando o debugger da IDE ao servidor

Agora, basta usar os recursos de debugging presentes na sua IDE Java para debugar o código. Por exemplo, se você usa o NetBeans 5.5, basta acessar o menu Run – Attach Debugger… e o configurar da seguinte forma:

Anexando o debugger do NetBeans

O procedimento é semelhante em outras IDEs Java.

Pronto! Feito isso, é só colocar os breakpoints e disparar a execução do código problemático.