Começando aplicações Rails versus Django

No post anterior, foi mostrado como criar ambientes de desenvolvimento Rails e Django, comparando o RVM (Ruby Version Manager) com o PIP (Python Install Packages).

Este artigo dá um pequeno passo adiante, mostrando as similaridades e diferenças durante a criação aplicações usando estes dois frameworks web.

Não se preocupe se não leu o artigo anterior, este post mostrará todos os passos necessários para criar as aplicações em Rails e em Django

Criação do Projeto Rails

Instalar RVM:

Desta forma, o RVM é instalado no diretório ~/.rvm, como pode ser notado abaixo:

É necessário configurar o PATH adicionando a seguinte linha no ~/.bash_profile.

Para atualizar o PATH, pode-se simplesmente abrir um novo terminal, ou executar
source ~/.bash_profile

Instalar o Ruby (instale a versão que for aplicável ao seu projeto).

Criar um ambiente "ambiente_app_contatos" baseado no Ruby 1.9.2

Uma forma de saber quais ambientes estão disponíveis para usar com o RVM é listar o conteúdo do diretório ~/.rvm/gems:

O RVM possui também vários comandos utilitários. Por exemplo, para saber qual ambiente está atualmente em uso:

Instalar Rails

Criar a aplicação de Contatos.

O argumento -T serve para pular a criação dos testes de unidade. Existem várias frameworks de teste que podem ser usadas com o Rails (UnitTest, RSpec, Cucumber, etc...), elas podem ser adicionadas no projeto num momento posterior.

Veja a estrutura do projeto criado pelo Rails:

Criar um arquivo .rvmrc para carregar o ambiente correto quando navegar para o diretório da aplicação

O comando acima cria um arquivo .rvmrc no diretório do projeto. Ao entrar no diretório (por exemplo cd /path/to/app_contatos_rails), o ambiente correto é carregado:

Uma vez criado o projeto, é possível executar comandos rails de dentro do diretório da aplicação, por exemplo:

• rails console ou rails c, para iniciar o interpretador de comandos;
• rails server ou rails s para iniciar o servidor web;
• rails dbconsole ou rails db para iniciar o console do banco de dados (por padrão o SQLite).

Criação de um projeto Django

A primeira diferença que vamos ao trabalhar com Django em relação ao Rails é que, enquanto o Ruby poderia ser instalado usando o próprio RVM, a instalação do Python deve ser feita sem contar com a ajuda do gerenciador de pacotes VirtualEnv.

O VirtualEnv nada mais é que um arquivo virtualenv.py, que deve ser executado por um interpretador Python previamente instalado. Como normalmente as distribuições Linux já vêm com o Python, este fato acaba sendo transparente, mas pode-se rodar o apt-get (ou yum, ou rpm) para verificar a versão instalada ou mesmo atualizar para uma versão mais recente:

Não é obrigatório, mas para fins de melhor organização, a criação de ambientes python será feita dentro de um diretório .virtualenv

Como se pode ver, o virtualenv cria uma instalação python no diretório ambiente_app_contatos, contendo apenas o pip e o easy_install, que serão usados para gerenciar a instalação de novos pacotes.

Para ativar este ambiente, é necessário carregar o arquivo bin/activate

Note que o terminal passa a indicar qual ambiente python está atualmente ativado! Chega a hora de instalar o Django, usando o pip:

E com o Django instalado, vamos criar a aplicação. Enquanto no Rails a aplicação é criada em um único comando (rails new) - criando toda a estrutura para rodar um webserver e acessar um banco de dados, juntamente com a estrutura da aplicação - em Django, isto ocorre em duas etapas:

1) python django-admin.py startproject

Ao criar o projeto são gerados os arquivos manage.py, settings.py e urls.py. Com esta estrutura mínima, já é possível executar alguns comandos, por exemplo, para iniciar um webserver (python manage.py runserver) ou acessar um banco de dados (python manage.py dbshell).

Para acessar um banco de dados, antes é necessário completar a configuração no arquivo settings.py. No trecho abaixo, foi ajustada uma configuração para sqlite, persistindo dados num arquivo contatos.sqlite.

Com a configuração ajustada, basta executar python manage.py dbshell para iniciar uma sessão com o banco de dados.

2) python manage.py startapp

Por fim, após a criação do projeto, podemos proceder com a criação da aplicação

Como se vê, a estrutura inicial de uma aplicação Django é bem mais simples que a de uma aplicação Rails, contendo apenas 3 arquivos relevantes - models.py, tests.py e views.py.

No Django, não existe similar ao arquivo .rvmrc (vimos na primeira parte deste post que a presença deste arquivo no diretório da aplicação rails permite o carregamento automático do ambiente ruby adequado). Portanto, ao iniciar uma nova sessão de terminal, será necessário ativar novamente o ambiente. Isto pode se tornar um inconveniente.

Um artifício engenhoso pode ser tirar vantagem pelo fato de o rvm estar instalado, e criar um arquivo .rvmrc no diretório do projeto django, contendo o comando para ativação do ambiente virtualenv.

Veja como esta "malandragem" funciona bem:

Conclusão

Através deste artigo, busquei apontar que, apesar de serem grandes as diferenças entre projetos Rails e Django, existem muitas funcionalidades e formas de trabalho comuns, que justificam aprender os frameworks em paralelo.

Ambos os frameworks oferecem facilidades para rodar interpretadores de comandos Ruby/Python; para iniciar websersers; e para iniciar sessões com o banco de dados, via terminal - tarefas que fazem parte da rotina do desenvolvimento de uma aplicação web.

As diferenças começaram a ficar bastante evidentes. A anatomia de uma aplicação Rails, por exemplo, é relativamente complexa: em um único comando (rails new) é criada toda a infra-estrutura de suporte do projeto (para rodar o webserver e o banco de dados), juntamente com a estrutura da própria aplicação. Em Django, isto é feito em duas etapas - e ainda assim, a quantidade de artefatos gerados pelo Django é bem menor.

Não é minha intenção afirmar que uma abordagem é melhor que a outra - são apenas diferentes, e essas diferenças serão abordadas em futuros posts.

No próximo post, avançaremos mais um passo, mostrando os arquivos Gemfile, usado no Rails em conjunto com o Bundler; e o arquivo requirements, usado em conjunto com o PIP no Django; ambos para gerenciamento das dependências da aplicação.

Ainda no roadmap próximo, será mostrado como criar models, e como utilizar migrations para versionar a evolução do schema de banco de dados em ambos os frameworks.