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 Snip/**/pets/)*
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]
Fonte: http://ruby-br.org
http://ruby-br.org/?s=git
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
*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 Snip/**/pets/)*
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
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
editor)
* *Windows*: E-texteditor
se aproxima do TextMate para Windows)
* *Linux*: Gedit
como ele se sai bem), Vim
servidores tem Vi ou Vim instalado, vale a pena aprender a
usá-lo), Emacs
interessante)
Escolha seu editor, e bom trabalho!
[Artigo traduzido do blog GuateOnRails]
Fonte: http://ruby-br.org
http://ruby-br.org/?s=git