Setup Rails 3 Project

Included with Haml, jQuery, Postgre, capybara, cucumber, rSpec

1. Create new rails 3 application bypassing rails standard test and prototype framework

   $ rails new [app_name] -JT
   $ cd [app_name]
   

2. Edit bundle Gemfile

   gem 'haml', '>= 3.0.25'
   gem 'jquery-rails', '>= 0.2.6'
   gem 'pg', '>= 0.10.0'
   
   group :development, :test do
     gem 'nifty-generators', '>= 0.4.3'
     gem 'capybara', '>= 0.4.0'
     gem 'cucumber-rails', '>= 0.3.2'
     gem 'rspec-rails', '>= 2.4.1'
   end
   

3. Install gem

   $ sudo bundle install
   

4. Setup database configuration config/database.yml

   common: &common
     adapter: postgresql
     username: user
     password: pass
   
   development:
     <<: *common
     database: development
   
   test:
     <<: *common
     database: test
   
   production:
     <<: *common
     database: production
   

5. Install cucumber

   $ rails g cucumber:install
   

6. Install rSpec

   $ rails g rspec:install
   

7. Generate configuration file by using nifty-generators

   $ rails g nifty:config
   

8. Generate haml layout file by using nifty-layout

   $ rails g nifty:layout --haml
   

9. Install jQuery by using jquery-rails

   $ rails g jquery:install
   

10. Remove default application layout

    $ rm app/views/layouts/application.html.erb
    

11. Add jQuery include tag to app/views/layouts/application.html.haml below stylesheet link tag code

    = javascript_include_tag 'jquery.min.js', 'rails.js'
    

12. Create home controller with index view

    $ rails g controller Home index
    

13. Change home index view into haml

    $ mv app/views/home/index.html.erb app/views/home/index.html.haml
    

14. Edit app/views/home/index.html.haml

    - title 'Home#index'
    %p Find me in app/views/home/index.html.haml
    

15. Create root path by editing config/routes.rb

    #remove default get generated route below
    get "home/index"
    #and change it to
    root :to => "home#index"
    

16. Remove unused file

    $ rm public/index.html
    $ rm public/images/rails.png
    

17. Create database and migrate

    $ rake db:create
    $ rake db:migrate
    

18. To run server

    $ rails s
    

19. To run acceptance test with cucumber

    $ bundle exec cucumber
    

20. To run unit test with rSpec

    $ bundle exec rspec
    

Done, happy coding rails fellow !

Escreva seu próprio código!

Calma ai pessoal, não venho aqui afirmar que sou contra a meta-programação, não é nada disso. O que considero má prática é a ideia de maquiar código html, css e javascript. Sei que o código de uma página HTML cheio de divs não é lá uma coisa bonita de se ver e sei também como é complicado mantê-lo limpo e fácil de entender. Soluções como HAML a primeira vista parece bem interessante, na própria página do projeto nós podemos encontrar um exemplo, digamos assim, tentador:

html.haml

#profile
  .left.column
    #date= print_date
    #address= current_user.address
  .right.column
    #email= current_user.email
    #bio= current_user.bio

html.erb

<div >
  <div class="left column">
    <div ><%= print_date %></div>
    <div ><%= current_user.address %></div>
  </div>
  <div class="right column">
    <div ><%= current_user.email %></div>
    <div ><%= current_user.bio %></div>
  </div>
</div>

Bem mais limpo, bem mais fácil de entender e quem sabe até mais produtivo. Então, por que diabos não uso isso? O que me incomoda é que sempre fica um pouco mais complicado resolver problemas no código gerado, é sempre uma dor de cabeça a mais, é um processo a mais! E outra, pra quê escrever código que me gera um html, se eu sei escrever código html? Não sei se estou conseguindo ser claro, mas apenas o fato de ter que me preocupar se o problema está no haml ou no código html gerado, ou se eu estou seguindo corretamente a sintaxe para que meu código seja corretamente gerado, são preocupações e processos desnecessárias. Quando falo de processos não estou falando apenas do processo humano, mas de processos de maquina mesmo, eu sei muito bem que interpretar um código haml para gerar um html não é um processo significante, mas ainda sim é um processo (tô exagerando?) . O que quero dizer é que evitar processos extras é uma boa prática, eu fico pra morrer quando encontro código estático sendo gerado, tipo, pra quê escrever este código “<%= link_to ‘Back’, sites_path %>” se ele vai sempre gerar o mesmo código html “<a href=”/sites”>Back</a>”, não é mais lógico escrever a versão “final” do código? Só para ressaltar, eu sei que estes pequenos processos A MAIS são insignificantes, porém usá-los frequentemente é no mínimo #$!**0!+?!, tem muita gente por ai usando um clientes.all em uma página que exibe apenas os clientes com débito, mas isso já é assunto pra outro post.

Sobre css, o sass tem atraído a atenção de muita gente. O sass não apenas deixa o código mais legível, mais bonito, o interessante do sass é o uso de variáveis. Sabe aquele cor que sempre repetimos em vários lugares do nosso css, a ideia é armazená-la em uma variável e chamá-la quando preciso, isso também ajuda quando precisamos mudar algum valor de uma propriedade que se encontra em muitos blocos, se esta propriedade estiver associado a uma variável, basta mudar o valor da variável. O sass traz umas coisas bem legais, vale a pena dar uma conferida, mas ele traz também os mesmos problemas do haml apresentados anteriormente, e outra, é bom lembra que hoje em dia até nos mais simples editores de texto encontramos opções de autocompletar e substituir trechos repetidos. A sacada do css é separar estilo de html, é evitar que tenhamos que inserir a propriedade color em todas as tags <p>, simplesmente declarando p{color:gray}. Estou satisfeito com css, não o considero um monstro e até o momento não sinto necessidade de simplificá-lo mais ainda.

Para javascript, temos o recém badalado CoffeScript. Não me aprofundei no assunto, nem mesmo o testei, mas pelo que li ainda não vi vantagem em usá-lo e deixar de escrever meu próprio código javascript. A dica que deixo é: “escreva seu próprio código!”