Escolhendo o melhor editor para Ruby on Rails
O editor de textos é o nosso grande amigo de trabalho. Se ele não for eficiente e eficaz, certamente irá complicar ainda mais nossa vida, trazendo uma série de dificuldades - por isso sua escolha é importante.
Na hora de escolher qual será seu fiel escudeiro editor para trabalhar com Ruby on Rails (ou mesmo Ruby), alguns itens importantes devem ser levados em consideração. O blog Guate On Rails elaborou uma interessante lista de itens que devem ser verificados na escolha do editor. Veja se não está na hora de abandonar o bloco de notas:
1. Coloração de sintaxe para Ruby/Rails
Com isto queremos dizer qeu seu editor deve fornecer uma forma simples de oferecer coloração ao código de arquivos do tipo *.rb, *.rhtml, *.html.erb, *.js, *.yml e *.json. Se o seu editor não pode fazer isso, ou se para fazer isso você deve gastar mais de 5 minutos, é hora de dizer-lhe tchau.
2. Auto-Completar Código
Bem, não estamos falando de que se você escrever uma parte de uma função, o editor retorne todas as funções da API. Estamos falando que ao digitar alguns poucos caracteres (como @ja) o editor possa de forma automática ou com uma combinação de teclas retornar @javier_e_o_maximo. Isto deve-se ao fato de que Rails trabalha numa base de constante chamadas a simbolos, variáveis de instância, nomes de classes e métodos. E você não acredita quanto tempo pode perder buscando um erro causado por uma letra errada na chamada de uma variável ou função.
3. Fragmentos de Código (Code Snippets)
Uma das principais razões pela qual um editor é ou não é adequado para Ruby on Rails. Seu editor deve permitir-lhe escrever algo como:
vu + TAB ou vu + CTRL + ENTER ou vu + SPACE
ou algo parecido com isso, devendo retornar como resultado
validates_uniqueness_of :nome_do_campo, :message=>”Este valor já está em uso”
dando depois a possibilidade de modificar FACILMENTE (uma tecla) :nome_do_campo e “Este valor já está em uso”. Isto é conhecido como “placeholders”.
A criação e modificação desses fragmentos de código deve fazer parte do editor, ou ter uma maneira fácil de se poder faze-lo. Se você leva mais de 60 segundos para adicionar, modificar ou eliminar um fragmento de código, seu editor está longe de ser indicado.
NOTA: A adição ou modificação de fragmentos não deve exigir que você reinicie seu editor.
4. Fácil navegação entre Arquivos
Devido a forma como Rails organiza seus arquivos, existe a necessidade de navegar rápida e repetidamente entre muitos deles. Estes arquivo normalmente estão relacionados entre sí, por exemplo se estou trabalhando numa view chamada mostrar_clientes.html.erb é certo que vou querer trabalhar também no controller clientes_controller.rb e no model cliente.rb. O editor deve propiciar a mudança entre eles de maneira rápida e fácil, em especial sem a necessidade de usar o mouse para poder mudar de arquivo ou buscá-los. Também deve incluir em seus requisitos que o editor permita visualizar uma árvore de diretórios de seu projeto; não vão acreditar o quanto é frustrante não poder acessar rapidamente um determinado diretório, ou pior, ter que usar o gerenciador de arquivos de seu sistema operacional para chegar até eles.
5. Buscas em todo o projeto
Simples, mas extremamente necessário, a possibilidade de poder buscar um simbolo dentro de todos os arquivos, no interior de uma pasta específica e/ou de suas subpastas.
6. Não necessitar de 4GB de RAM para rodar
Exagero, mas não estou mentindo. Existem editores que pedem mais recursos que um simulador de vôo. Se quiser trabalhar tranquilamente, escutando sua música favorita e deixando uma mensagem no Twitter, por favor mantenha distância deste tipo de editor.
Bom, parece que é isso. Cobrimos as bases de um bom editor de Rails, e qualquer coisa muito além disso tem a ver com gosto pessoal ou vantagem competitiva. Abaixo, veja alguns exemplos de editores que cobrem estes requisitos e um pouco mais.
- Apple: TextMate (O Rails nasceu neste editor)
- Windows: E-texteditor (O que mais se aproxima do TextMate para Windows)
- Linux: Gedit (Não acreditam como ele se sai bem), Vim (Todos os servidores tem Vi ou Vim instalado, vale a pena aprender a usá-lo), Emacs (Também interessante)
Escolha seu editor, e bom trabalho!
[Artigo traduzido do blog GuateOnRails]
Veja também:
Comentários
7 Comentários para Escolhendo o melhor editor para Ruby on Rails
-
Daniel Docki on
qui, 16th abr 2009 12:33
-
João on
qui, 16th abr 2009 3:49
-
Thiago Pradi on
qui, 16th abr 2009 8:04
-
Felipe Coury on
sex, 17th abr 2009 4:00
-
Rafael Pinese on
dom, 19th abr 2009 6:06
-
Usando o Vim como IDE Rails | Ruby Brasil on
ter, 21st abr 2009 8:02
-
Marcio Goularte on
seg, 26th abr 2010 6:58
Uso o TextMate, mas ainda não sei como configurar ele para usar tudo em que pode me ajudar, sabe aonde posso achar? dicas, tutoriais como configurar um ambiente eficaz no TextMate para RoR?
@Daniel,
Talvez essa lista de comandos Rails no TextMate ajude:
http://blog.nanorails.com/articles/2006/06/23/textmate-rails-cheat-sheets
Falows
João Pereira
Pra quem quiser iniciar no Emacs, recomendo os meus dotfiles: http://github.com/tchandy/emacs-rails/tree/master
Uso Emacs full time com rails e recomendo
tanto que o próprio Matz foi quem fez o mode de Ruby pro Emacs…
Outra opção para o Linux que promete é o RedCar (clone do TextMate): http://www.redcareditor.com.
Abraços!
No site do akita tem um bom tutorial de como configurar o Vim para Windows. Vale a pena conferir!.
http://www.akitaonrails.com/2009/1/3/rails-on-vim
[...] post dessa semana, falamos sobre como escolher um editor para Ruby/Rails, e uma das opções para ambiente Linux era o Vim, presente em praticamente todas as [...]
Para Windows recomendo o Aptana RadRails
http://www.radrails.org/
Diga-nos o que pensa...
e se você pocura uma imagem para colocar em seu comentário, procure o gravatar!





