Oxente Rails conta com a presença de Locawebers

Entre hoje e amanhã (06/08 e 07/08) acontece o Oxente Rails, o maior evento de Rails do Nordeste do Brasil e que tem a Locaweb como um de seus patrocinadores.

A cidade de Natal sedia o evento, que conta com a presença de pessoas importantíssimas da comunidade Rails, não só do Brasil, mas do mundo todo.

Entre os palestrantes temos os Locawebers:  Fábio Kung, gerente e líder técnico de Cloud Computing na Locaweb, Daniel Cukier, gerente de desenvolvimento de software, Leandro Silva, gerente de desenvolvimento, Rafael Rosa, coordenador do produto Cloud Computing e Nando Vieira, especialista em desenvolvimento de software na Locaweb. Confira lista dos palestrantes.

O site oficial do evento é o http://oxenterails.com e para quem quer acompanhar pelo Twitter, a hashtag é #oxenterails.

Link deste post
Tags: evento, Locaweb, Locawebers, Natal, Oxente Rails, rails, ruby on rails

O que rolou de Ruby e Ruby on Rails no fisl11

Como nas edições anteriores, esse ano no fisl11 tivemos várias palestras relacionadas com Ruby e Rails.

Quarta, 21 de julho

No primeiro dia, mostrei o uso do Spree, uma plataforma completa de comércio eletrônico desenvolvida em Ruby on Rails, como base de um novo sistema de loja virtual da Locaweb.

Nessa apresentação foram mostradas algumas técnicas de metaprogramação Ruby para lidar com as extensões do Spree e organizar melhor seu código.

Os slides da palestra “Locaweb + Spree: transformando código aberto em um projeto comercial” estão disponíveis nesse link:
http://www.slideshare.net/Prodis/locaweb-spree-transformando-cdigo-aberto-em-um-projeto-comercial

Quinta, 22 de julho

Neste dia, Daniel Lopes iniciou o “Mini-curso de Ruby e Rails”, introduzindo a linguagem de programação Ruby e os primeiros passos de Ruby on Rails. Essa primeira parte do curso teve duas horas de duração com a sala lotada.

ler mais

Link deste post
Tags: Comércio Eletrônico, fisl, HoraExtra, Prodis, rails, ruby, ruby on rails, Spree

Random Hack of Kindness

Há duas semanas, participei representando a Locaweb do primeiro Random Hack of Kindess mundial. Formamos um time de 4 pessoas e trabalhamos no  projeto  Fato Urbano. A ideia principal desse projeto é a de ressaltar fatos BONS e/ou RUINS que acontecem na sua cidade. Se você vir alguém jogando lixo no meio da rua, por exemplo, você pode tirar uma foto desse ato “feio” e postar no Twitter usando a hashtag #fatourbano (ou #urbanfact em inglês). Essa foto aparecerá automaticamente no  site do projeto, onde as pessoas podem votar, comentar e compartilhar com amigos.

Para a solução, que foi feita em 1 dia e meio de desenvolvimento, usamos Ruby on Rails para a interface Web, MySql para o banco de dados e Python para o script de backend, que coleta os tweets e alimenta o banco de dados. Nós também usamos a API de Mapas do Google, que gera automaticamente um mapa contendo a localização dos FATOS. Todo o código está disponível nessa conta do github. Nós hospedamos o site em um Servidor Cloud da Locaweb.

Nosso projeto ganhou o prêmio de segundo melhor projeto do evento!

Tiramos algumas fotos, que estão disponíveis nessa conta do flick nessa conta do flickr.

Link deste post
Tags: cloud, Desenvolvimento, hack, rails, random hack of kindness, responsabilidade social, rhok

Utilizando debug em aplicações Rails

Muita gente acha (assim como eu achava há um tempo atrás) que não é possível utilizar debug (ou “depurar”, ou “debugar”) uma aplicação Ruby on Rails. Acredito que isso se deve ao fato de Ruby ser uma linguagem interpretada, diferente de outras linguagens que requerem compilação.

Existe uma forma muito simples de se “debugar” em Rails. Primeiro vamos instalar a gem ruby-debug.

$ sudo gem install ruby-debug

Agora vamos criar uma aplicação Rails de exemplo para utilizar o debug.

$ rails prodis-debug
$ cd prodis-debug
$ rails script/generate scaffold MyModel my_text:string my_value:float
$ rake db:migrate

E ao invés de subir a aplicação com script/server, iniciamos a aplicação em modo debug:

$ rdebug script/server
/Users/Prodis/Blog/code/prodis-debug/script/server:2
require File.expand_path('../../config/boot',  __FILE__)
(rdb:1)

Esse é o momento de adicionarmos o(s) breakpoint(s) desejados, informando o arquivo e a linha do mesmo. Vamos colocar um breakpoint na ação create de MyModelsController:

(rdb:1) break app/controllers/my_models_controller.rb:43
Breakpoint 1 file /Users/Prodis/Blog/code/prodis-debug/app/controllers/my_models_controller.rb, line 43

E usamos o comando cont para prosseguir com o carregamento da aplicação no servidor.

(rdb:1) cont
=> Booting Mongrel
=> Rails 2.3.5 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server

No browser, através do endereço http://localhost:3000/my_models/new, vamos criar um novo registro de MyModel.

Quando clicarmos no botão “Create”, a aplicação irá parar no breakpoint que colocamos na linha 43 de MyModelsController.

Breakpoint 1 at /Users/Prodis/Blog/code/prodis-debug/app/controllers/my_models_controller.rb:43
/Users/Prodis/Blog/code/prodis-debug/app/controllers/my_models_controller.rb:43
@my_model = MyModel.new(params[:my_model])
(rdb:6) 

A partir daqui podemos investigar o código e ter acesso as suas variáveis. Por exemplo, exibindo os valores da variável params:

(rdb:6) p params
{"my_model"=>{"my_text"=>"I am some text", "my_value"=>"50.00"},
"commit"=>"Create", "authenticity_token"=>"qN9mUhJelZD0V/P2CB1fhBkQrIxFvvk+NRkY5m6EFWg=",
"action"=>"create", "controller"=>"my_models"}

Mas a maneira mais fácil de inspecionar variáveis é pelo irb, que irá se manter no contexto atual onde a aplicação está parada.

(rdb:6) irb
irb(#):001:0> params
=> {"my_model"=>{"my_text"=>"I am some text", "my_value"=>"50.00"},
"commit"=>"Create", "authenticity_token"=>"qN9mUhJelZD0V/P2CB1fhBkQrIxFvvk+NRkY5m6EFWg=",
"action"=>"create", "controller"=>"my_models"}
irb(#):002:0>

Saindo do irb (com o comando exit), nós voltamos para o ambiente de debug. Há uma série de comandos úteis para se utilizar. Um deles é o list, que exibe o trecho de código onde a aplicação está parada e indicando sua linha exata através de uma seta:

(rdb:6) list
[38, 47] in /Users/Prodis/Blog/code/prodis-debug/app/controllers/my_models_controller.rb
38    end
39
40    # POST /my_models
41    # POST /my_models.xml
42    def create
=> 43      @my_model = MyModel.new(params[:my_model])
44
45      respond_to do |format|
46        if @my_model.save
47          flash[:notice] = 'MyModel was successfully created.'
(rdb:6)

Para avançar até a próxima linha, usamos o comando next:

(rdb:6) next
/Users/Prodis/Blog/code/prodis-debug/app/controllers/my_models_controller.rb:45
respond_to do |format|
(rdb:6)

Para listar todos os comandos disponíveis, basta entrarmos no help:

(rdb:6) help
ruby-debug help v0.10.3
Type 'help ' for help on a specific command

Available commands:
backtrace  delete   enable  help    next  quit     show    trace
break      disable  eval    info    p     reload   source  undisplay
catch      display  exit    irb     pp    restart  step    up
condition  down     finish  list    ps    save     thread  var
continue   edit     frame   method  putl  set      tmate   where 

(rdb:6)

Também podemos visualizar a ajuda de um comando específico:

(rdb:6) help next
n[ext][+-]?[ nnn]	step over once or nnn times,
'+' forces to move to another line.
'-' is the opposite of '+' and disables the force_stepping setting.
(rdb:6) 

E para continuar a execução da aplicação, usamos o comando continue (ou um dos seus álias c ou cont)

(rdb:6) continue

Processing MyModelsController#create (for 127.0.0.1 at 2010-03-20 12:20:54) [POST]
Parameters: {"my_model"=>{"my_text"=>"I am some text", "my_value"=>"50.00"},
"commit"=>"Create", "authenticity_token"=>"qN9mUhJelZD0V/P2CB1fhBkQrIxFvvk+NRkY5m6EFWg="}
MyModel Create (0.5ms)   INSERT INTO "my_models" ("my_text", "created_at", "updated_at", "my_value")
VALUES('I am some text', '2010-03-20 15:45:19', '2010-03-20 15:45:19', 50.0)
Redirected to http://localhost:3000/my_models/4
Completed in 1464995ms (DB: 1) | 302 Found [http://localhost/my_models]

Existe também uma outra maneira de se “debugar” com a gem ruby-debug. Nós podemos colocar uma instrução debugger (que na verdade é um método) em qualquer lugar do código para marcar como breakpoint. O Railscast #54 Debugging with ruby-debug mostra os passos de como fazer isso.

Eu particularmente gosto de configurar os breakpoints direto no Terminal, evitando assim ter que colocar qualquer informação de debug no código.

Esse esquema de debug não se restringe somente à aplicações Rails. Você pode muito bem utilizá-lo com código Ruby diretamente. Por exemplo, o código abaixo é do arquivo some_class.rb:

#lib/some_class.rb
class SomeClass
  def some_method
    # do something here
  end

  def other_method
    # do another thing here
  end
end

É só utilizar o comando rdebug passando o nome do arquivo:

$ rdebug lib/some_class.rb
/Users/Prodis/Blog/code/prodis-debug/lib/some_class.rb:2
class SomeClass
(rdb:1) 

Para informações mais detalhadas sobre a gem ruby-debug, veja a documentação completa.

Post original:
http://prodis.pro.br/2010/03/20/utilizando-debug-em-aplicacoes-rails

.

Link deste post
Tags: Debug, Desenvolvimento de Software, linguagens de programação, Prodis, rails, ruby, ruby on rails, rubyonrails

Métodos que retornam mais de um valor em Ruby

Nas últimas semanas, a equipe que eu trabalho estava desenvolvendo um web service onde havia a necessidade de renderizar o retorno de uma lógica de negócio em representações XML. Digo representações (no plural), pois para um retorno com sucesso a representação seria uma e para retorno com erro a representação seria outra.

Por exemplo, um retorno com sucesso:

<natural-person>
   <name>Prodis</name>
   <cpf>01234567890</cpf>
</natural-person>

E um retorno sem sucesso:

<error>
   <description>CPF inválido.</description>
</error>

Como era um web service em REST, para sucesso retornamos o código de status HTTP “200 OK” e, dependendo do não sucesso da operação, o código de status HTTP da resposta poderia ser “400 Bad Request”, “404 Not Found” ou qualquer outro código 4xx ou 5xx que melhor se adequasse.

Mantendo um controller magro, a idéia era somente instanciar uma classe de negócio, chamar um método e renderizar o retorno. Algo como:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    natural_person = business.search_by_cpf params[:cpf]

    # TODO: Renderizar pessoa física ou mensagem de erro
  end
end

A partir daqui a equipe iniciou uma discussão sobre a melhor forma de se obter o(s) retorno(s) esperado(s). O controller precisava saber se a consulta havia sido feita com sucesso, para renderizar um objeto NaturalPerson retornando o código de status HTTP 200, ou se a consulta não tivesse sucesso, renderizar a mensagem de erro retornando um código de status HTTP 4xx adequado.

Como “bons programadores .NET e Java”, a primeira coisa que pensamos foi lançar uma exceção customizada caso a consulta não tivesse sucesso, capturar essa exceção no controller e, através das informações de descrição de erro e código de status HTTP contidas nessa exceção, renderizar o retorno adequado.

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new

    begin
      natural_person = business.search_by_cpf params[:cpf]

      render natural_person, 200
    rescue BusinessException => e
      render e.error, e.status_code
    end
  end
end

A gente não tinha visto muito código Ruby utilizando begin rescue, então essa solução não nos pareceu muito “Ruby way”. Achamos melhor pedir a opinião de alguém com mais experiência em Ruby. Perguntamos ao Rafael Rosa, que nos disse que cada vez que lançamos uma exceção em Ruby “alguma coisa ruim acontece no servidor” e consequentemente a aplicação ficará mais lenta.

Ele indicou um post falando a respeito:
http://www.simonecarletti.com/blog/2010/01/how-slow-are-ruby-exceptions

Rafael Rosa nos sugeriu retornar um array de duas posições: uma com o código de status HTTP e outra com o objeto a ser renderizado.

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    result = business.search_by_cpf params[:cpf]

    render result[1], result[0]
  end
end

Resolveu, mas o código não ficou muito intuitivo. A partir daí imaginamos algumas outras soluções.

Retornar um hash:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    result = business.search_by_cpf params[:cpf]

    render result[:data], result[:status_code]
  end
end

Criar uma classe de retorno:

class SomeBusinessResult
  attr_accessor :status_code, :data
end

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    result = business.search_by_cpf params[:cpf]

    render result.data, result.status_code
  end
end

Posteriormente, o Rafael Rosa também sugeriu essa última opção, mas criando uma Struct ao invés de uma classe.

Então eu sugeri o método search_by_cpf retornar dois valores. Todos da equipe me perguntaram: “Como assim retornar dois valores?”. Falei que em Ruby um método pode retornar vários valores, que vi isso no livro The Ruby Programming Language.

O código do controller ficou bem mais intuitivo:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    status_code, data = business.search_by_cpf params[:cpf]

    render data, status_code
  end
end

O método search_by_cpf está retornando tanto o código de status HTTP quanto os dados para serem renderizados:

class SomeBusiness
  def search_by_cpf(cpf)
    # Lógica de negócio aqui
    return 200, natural_person
  end
end

Note que mesmo a linha 4 sendo a última linha de instrução do método, o retorno de mais de um valor obrigatoriamente precisa utilizar o comando return.

Quando há mais de um valor de retorno para um método, os valores são colocados implicitamente dentro de uma array e essa array fica sendo o único retorno do método.

O mesmo resultado seria obtido dessa forma:

class Business
  def search_by_cpf(cpf)
    # Lógica de negócio aqui
    [200, natural_person]
  end
end

Quem está consumindo um método que retorna mais de um valor, pode utilizar o recurso de atribuição paralela do Ruby para distribuir os valores de retorno em variáveis distintas, como é o caso no nosso controller:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    status_code, data = business.search_by_cpf params[:cpf]

    render data, status_code
  end
end

O dinamismo do Ruby lhe oferece várias opções para você encontrar soluções para o mesmo problema ou questão. Cabe a você decidir qual melhor abordagem para seu tipo de problema. O interessante é você conhecer essas opções para facilitar a sua decisão.

Post original:
http://prodis.pro.br/2010/02/20/metodos-que-retornam-mais-de-um-valor-em-ruby

.

Link deste post
Tags: Desenvolvimento de Software, Exception, linguagens de programação, Prodis, rails, REST, ruby, ruby on rails

Serialização de objetos em JSON com Ruby on Rails

Em um post anterior mostrei como serializar objetos em JSON utilizando .NET. Agora vamos fazer a mesma coisa com Ruby on Rails.

Vamos utilizar como exemplo uma classe de modelo chamada SomeFake:

class SomeFake < ActiveRecord::Base

end

Utilizando essa migration:

class CreateSomeFakes < ActiveRecord::Migration
  def self.up
    create_table :some_fakes do |t|
      t.string :text
      t.float :value
      t.timestamps
    end
  end

  def self.down
    drop_table :some_fakes
  end
end

No script/console vamos criar uma instância do modelo SomeFake com os seguintes dados:

>> fake = SomeFake.create :text => "I am a sample text.", :value => 150.85
=> #<SomeFake id: 1, text: "I am a sample text.", value: #<BigDecimal:18ac9f0,'0.15085E3',8(12)>,
created_at: "2009-12-13 19:43:28", updated_at: "2009-12-13 19:43:28">

Então queremos serializar a variável fake em JSON para obter o seguinte resultado:

{"id":1,"text":"I am a sample text.","value":150.85}

Para fazer isso, vamos chamar o método to_json na variável fake (estou usando o comando print para uma exibição melhor no console do JSON gerado):

>> print fake_json = fake.to_json
"{"some_fake": {"updated_at": "2009-12-13T19:43:28Z", "text": "I am a sample text.",
"id": 1, "value": 150.85, "created_at": "2009-12-13T19:43:28Z"}}"

O resultado que obtemos não é exatamente igual ao que estávamos querendo.

Primeiro, o nome do nosso modelo foi serializado como raiz do objeto em JSON. Isso aconteceu porque por padrão em uma aplicação Rails, a opção ActiveRecord::Base.include_root_in_json é configurada para true no arquivo config/initializers/new_rails_defaults.rb. Nós podemos alterar essa opção para false nesse arquivo, o que afeta a serialização em JSON de toda a aplicação, ou podemos alterá-lo no próprio script/console para nossos testes:

>> ActiveRecord::Base.include_root_in_json = false
=> false

Agora nosso objeto serializado fica assim:

>> print fake_json = fake.to_json
"{"updated_at": "2009-12-13T19:43:28Z", "text": "I am a sample text.", "id": 1,
"value": 150.85, "created_at": "2009-12-13T19:43:28Z"}"

A segunda diferença é que não queremos que os atributos de timestamps (created_at, updated_at) sejam serializados. Então vamos dizer para o método to_json não serializar esses atributos, utilizando a opção except:

>> print fake_json = fake.to_json(:except => [:created_at, :updated_at])
"{"text": "I am a sample text.", "id": 1, "value": 150.85}"

Para fazer o inverso, transformar dados em JSON para um objeto, criamos uma nova instância da classe SomeFake e chamamos o método from_json passando a variável fake_json como parâmetro:

>> other_fake = SomeFake.new
=> #<SomeFake id: nil, text: nil, value: nil, created_at: nil, updated_at: nil>

>> other_fake.from_json fake_json
=> #<SomeFake id: nil, text: "I am a sample text.", value: #<BigDecimal:1708a04,'0.15085E3',8(12)>,
created_at: nil, updated_at: nil>

Caso você precise serializar objetos em JSON sem os atributos timestamps com frequência, ao invés de sempre passar a opção except para o método to_json, podemos incluir um novo método na classe ActiveRecord::Base que faça a serialização sem esses atributos. Dessa forma, todos os nossos modelos terão essa funcionalidade.

Vamos chamar esse método de to_json_no_timestamps, o qual sua implementação é mostrada abaixo:

class ActiveRecord::Base
  def to_json_no_timestamps(options = {})
    timestamps_options = [:created_at, :updated_at]

    if (options.has_key? :except)
      if (options[:except].class == Array)
        timestamps_options = options[:except] | timestamps_options
      else
        timestamps_options < < options[:except].to_sym unless options[:except].nil?
      end
    end

    options[:except] = timestamps_options

    to_json options
  end
end

E então basta chamar nosso novo método em uma instância de qualquer modelo:

>> fake = SomeFake.first
=> #<SomeFake id: 1, text: "I am a sample text.", value: #<BigDecimal:1712798,'0.15085E3',8(12)>,
created_at: "2009-12-13 19:43:28", updated_at: "2009-12-13 19:43:28">

>> print fake_json = fake.to_json_no_timestamps
"{"text": "I am a sample text.", "id": 1, "value": 150.85}"

Post original:
http://prodis.pro.br/2009/12/13/serializacao-de-objetos-em-json-com-ruby-on-rails

.

Link deste post
Tags: ActiveRecord, JSON, linguagens de programação, Prodis, rails, ruby, ruby on rails, Serialização

Locaweb dedica dia ao Software Livre

Aqui na Locaweb utilizamos alguns projetos de Software Livre para auxiliar na criação de nossos produtos. Além de utilizarmos esses softwares, tentamos sempre que possível contribuir para a evolução dos projetos.

Pensando nisso, decidimos na última sexta-feira dedicar um dia inteiro de alguns desenvolvedores à contribuição ao Software Livre.

Desta vez, o projeto escolhido foi o Gitorious. O gitorious é um gerenciador de projetos git (uma versão livre do Github). Cerca de 12 desenvolvedores entraram em uma sala de reunião e seguiram uma série de tarefas pré-definidas em um backlog. Estas tarefas foram geradas a partir de problemas reais sentidos por clientes do gitorious (no caso os próprios desenvolvedores), além de sugestões de features que poderiam ser implementadas.

Alguns exemplos de histórias implementadas:

• Apresentar o conteúdo do arquivo README na página incial do projeto.
• Bug-Fix: Authorized_Keys deve ser gerado com permissão certa.
• Refatorações e melhoria na cobertura de testes

A empresa também patrocinou refrigerante e pizza para deixar o clima mais descontraído.

O resultado está publicado no próprio gitorious no branch do Fabio Hisamoto.

Link deste post
Tags: ferramentas, gitorious day, linguagens de programação, Linux, rails, ruby, ruby on rails

Pagamento Certo e Sedex para E-commerce Spree

Spree é uma ferramenta de e-commerce, open source, desenvolvida em Ruby on Rails. A licença do Spree é New Free BSD, desta forma podemos utiliza-lo para fins comerciais.

Recursos do Spree:

• Projeto extensível;
• Suporta a última versão do Ruby on Rails;
• Upgrades Simples;
• Utiliza o framework jQuery;
• Suporte para múltiplos idiomas;
• Suporta UPS, FedEx e USPS;
• Utiliza o ActiveMerchant que permite o acesso a mais de 50 diferentes gateways de pagamento e serviços, incluindo Paypal e Authorize.net;
• Suporte a taxonomia, permitindo ao lojista categorizar seus produtos de forma complexa;
• Página de checkout única, minimizando uma possível confusão do cliente;
• Suporte para envio de e-mail de confirmação de compra;
• Segue as melhores práticas de design RESTful;
• Permite ao lojista ter o controle do seu estoque de produtos;
• Framework Blueprint and Sass para personalização de CSS;
• Suporta a customização para taxa de vendas;
• Motor de busca amigável;
• Google Analytics;

Através da administração o usuário poderá configurar opções de entrega, formas de pagamento, variantes para produtos, cadastro de produtos, entre outras funcionalidades. Veja a demo do Spree.

Pagamento Certo no Spree

Utilizamos a gem do Pagamento Certo desenvolvida pelo Akita. Com isso criamos uma extension do Pagamento Certo que faz a “ponte” para ligar as duas coisas. A extension modifica o processo de checkout para utilizar automaticamente o serviço Pagamento Certo.

Correios no Spree

A extension dos Correios foi desenvolvida, inicialmente, para efetuar o cálculo de frete por Sedex. A proposta é disponibilizar todas as outras formas de entrega que os Correios oferecem (Sedex, Sedex 10, e-Sedex e PAC), apenas com a criação de novos Calculators. Atualmente o cálculo de frete é efetuado consumindo um Webservice SOAP.

Para mais informações de como instalar o Spree com as extensions do Pagamento Certo e dos Correios, siga as instruções da Wiki.

Link deste post
Tags: Correios, e-commerce, linguagens de programação, Pagamento Certo, rails, ruby, ruby on rails, Spree

Gem Hirb, alegria aos olhos do desenvolvedor

No desenvolvimento com Ruby on Rails por inúmeras vezes precisamos abrir o terminal para checar os registros de um determinado objeto. Dependendo da quantidade de registros do objeto sua visualização no terminal fica um pouco confusa.

Neste exemplo utilizo um projeto de testes que é o cadastro de restaurantes. Veja a saída no terminal quando acesso o script/console e executo o comando Restaurante.all:

Para alegrar os olhos do desenvolvedor, temos a gem hirb que faz a formatação dos dados no terminal. Vamos instalar a gem. Para isso execute o comando:

sudo gem install hirb

Com a gem instalada temos duas possibilidades de utilização.

Adicionando a gem no terminal

Abra o terminal no diretório do projeto desejado e execute o comando:

script/console

Em seguida:

require ‘hirb’

E por fim:

Hirb::View.enable

Pronto! Agora basta executar o comando Restaurante.all novamente, que você terá uma saída parecida com esta:

Se utilizado da forma mencionada acima, toda vez que carregar o terminal com script/console para o projeto, será necessário executar os comandos novamente.

Adicionando a gem direto no projeto

Esta opção é a mais fácil.
Abra o arquivo /config/environments/development.rb

No final do arquivo adicione as linhas:

require ‘hirb’
Hirb::View.enable

Pronto! Basta abrir o terminal, dentro do diretório do projeto e executar o comando Restaurante.all através do script/console, você terá o mesmo retorno mencionado acima, veja:

Ajudou em meu desenvolvimento e espero que ajude o seu!

Post original:

http://www.ortiz.blog.br/dicas/gem_hirb_alegria_aos_olhos_do_desenvolvedor/

Link deste post
Tags: gem hirb, hirb, linguagens de programação, rails, ruby, ruby on rails

Rails Summit 2009: 10 razões para não perder!

1.  É o maior evento de Ruby on Rails da América Latina. Os principais nomes da Rails Conf estarão presentes.

2.  99% dos 550 desenvolvedores presentes no Rails Summit em 2008 classificaram o evento como BOM ou ÓTIMO.

3.  Serão 21 palestras, sendo 11 delas internacionais, além das desconferências e do networking.

4.  Rails 3.0 vem aí. Matt Aimonetti e José Valim apresentarão muitas das novidades previstas.

5.  Os melhores desenvolvedores do mercado apresentarão as principais evoluções técnicas e de metodologias ágeis.

6.  Segundo o Gartner Group, até 2013 haverão mais de 4 milhões de desenvolvedores Ruby. Antecipe-se!

7.  Java + Rails = JRuby. Aprenda a colocar Ruby na sua organização, mesmo ela sendo voltada a Java.

8.  Rails é o framework voltado ao empreendedorismo. Aprenda sobre todas as possibilidades que ele oferece.

9.  Todos os participantes terão internet sem fio, pontos de tomada, almoço, coffee break, tradução simultânea e toda a infra que só os grandes eventos possuem.

10.  Além de tudo o que foi relatado acima, ainda teremos sorteios de uma passagem aérea, netbook e muito mais!

Não perca o Rails Summit Latin America 2009!

Link deste post
Tags: Aplicativo, Desenvolvedores, Desenvolvimento, evento, Instalador de Aplicativos, novidade, programação, promoção, rails, RH

Nova versão do Passenger 2.2.5

A equipe da Phusion acaba de lançar uma nova versão do Passenger [1] , o modulo de deploy para aplicações Ruby on Rails, essa nova versão esta totalmente focada em bugfixes em relação as anteriores.

Pelo ambiente Locaweb ser diferenciado, foi desenvolvido um patch para ser  incluido a essa versão do mod_rails mantendo a compatibilidade para as aplicações que se encontram em produção atualmente.

Para os nossos clientes que utilizam Rails estaremos atualizando os nossos servidores com essa nova versão em alguns dias.

[1] http://blog.phusion.nl/2009/09/01/phusion-passenger-2-2-5-released/

Link deste post
Tags: Hospedagem, linguagens de programação, Linux, passenger, rails, ruby

Acessando SQL Server pelo Rails usando JRuby em 3 passos

Num artigo escrito em março, o Fabio Akita mostrou como fazer acesso a um banco de dados MS SQL Server por uma aplicação Rails. Apresentaremos nesse artigo uma alternativa mais simples, usando JRuby. Dessa forma, não é necessário configurar ODBC da máquina e a solução é exatamente a mesma, independente da plataforma ser Linux, Windows ou Mac.

Quem nunca trabalhou com Java ou JRuby terá um pouco mais de trabalho para configurar seu ambiente. Estamos supondo que a instalação da JDK já foi feita. Para instalar o JRuby, basta acessar o site do projeto, baixar e descompactar o arquivo em alguma pasta da sua máquina. Na ocasião desse artigo, baixamos a versão 1.3.1 do JRuby. Uma vez que o executável do JRuby esteja instalado na máquina juntamente com a JDK, o jruby deverá também estar incluído no seu PATH. Além disso, você precisa instalar o Driver JDBC para SQLServer no seu JRuby. Para isso, basta baixar o driver. O driver vem dentro de um arquivo .ZIP – o usado por nós foi o da versão 1.2.2. Coloque o arquivo jtds-1.2.2.jar no diretório /lib da sua instalação do JRuby.

A partir daí basta seguir os seguintes passos para criar uma aplicação Rails

1. Execute os comandos:
   • jruby -S gem install rails
   • jruby -S gem install activerecord-jdbc-adapter
   • jruby -S rails testesqlserver
     
2. Edite o arquivo config/database.yml e coloque o seguinte conteúdo no banco de development:
   adapter: jdbc
url: jdbc:jtds:sqlserver://seu.servidor.sql.server.com/suabase
driver: net.sourceforge.jtds.jdbc.Driver
username: usuario
password: senha
3. Entre no diretório testesqlserver e execute os comandos:
   • jruby -S script/generate model MyTable name:string
   • jruby -S rake db:migrate

Se tudo correu bem até aqui, nesse ponto a migration vai criar a tabela my_tables no seu banco de dados. Isso significa que sua conexão já está funcionando. Não fizemos muitos testes de performance para saber se esse tipo de configuração pode ser usado em aplicações críticas, mas algumas funções básicas funcionaram muito bem:


>> (1..10).each do |t|

?> a = MyTable.new

>> a.name = "#{t}"

>> a.save

>> end

=> 1..10

>> MyTable.find(:all)

=> [#<MyTable id: 2, name: nil, created_at: "2009-07-23 18:46:35", updated_at: "2009-07-23 18:46:35">, #<MyTable id: 3, name: "1", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 4, name: "2", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 5, name: "3", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 6, name: "4", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 7, name: "5", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 8, name: "6", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 9, name: "7", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 10, name: "8", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 11, name: "9", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 12, name: "10", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">]

>> MyTable.find(:all).each do |m|

?> m.delete

>> end

=> [#<MyTable id: 2, name: nil, created_at: "2009-07-23 18:46:35", updated_at: "2009-07-23 18:46:35">, #<MyTable id: 3, name: "1", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 4, name: "2", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 5, name: "3", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 6, name: "4", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 7, name: "5", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 8, name: "6", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 9, name: "7", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 10, name: "8", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 11, name: "9", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">, #<MyTable id: 12, name: "10", created_at: "2009-07-23 18:49:22", updated_at: "2009-07-23 18:49:22">]

>> MyTable.find(:all)

=> []

Link deste post
Tags: linguagens de programação, rails, ruby, ruby on rails, sql

fisl10 – TDD e Rails: Mais rápido, mais forte e melhor

A primeira apresentação que assisti no fisl10 foi muito boa. Lucas Húngaro mostrou formas de criar aplicações Ruby on Rails com testes, passando um pouco da sua experiência em desenvolvimento Web.

A palestra foi dividida em quatro partes: Fundamentos, Abordagens, Como eu desenvolvo com testes no Rails e Dicas. Mas separei aqui em mais duas: Boas Práticas e Maus Sinais.

Fundamentos

• TDD, BDD e suas suas diferenças.

Abordagens

• Outside-in: perspectiva dos usuários, testes de fora para dentro. São os testes de aceitação, mostram onde chegar.
• Inside-out: perspectiva do desenvolvedor, testes de dentro para fora. São os testes unitários, mostram como chegar.
• Atenção para não duplicar testes. Por exemplo, quando testar validações no model, não testar novamente essa validação no teste do controller que usa esse model.

Como eu desenvolvo com testes no Rails

• Testes unitários somente para models, testes funcionais mínimos e testes de aceitação guiando seu design de alto nível.
• Não fazer testes para helpers: se há uma complexidade em um helper que precise de um teste, essa lógica não deveria estar na View. Os helpers devem contém formatação e não lógica de negócio.
• Processo ideal: criar uma feature no Cucumber e vai descendo do alto nível (browser, session/routes, view) para os níveis mais baixos (controllers, models).

Dicas

• Use factories para fazer testes.
• Especifique os casos de falha, não crie testes somente para a execução perfeita da funcionalidade.
• Os testes precisam revelar o comportamento e a intenção. Testes com nomes de métodos ficam esquisitos, coloque no nome do teste o comportamento que você está testando.
• Testes não precisam ser totalmente DRY (Don’t Repeat Yourself), pois devem ser muito fáceis de entender, somente “batendo o olho”.
• Use com moderação objetos de substituição (mocks, stubs, proxies, etc).
• Não utilize mocks como stubs.
• Não confie cegamente em métricas: é muito fácil criar testes que não testam nada e que aumenta a cobertura de testes.

Boas práticas

• Não substitua (com mocks, por exemplo) o objeto que você está testando.
• Crie wrappers para objetos que você não é dono, ao invés de tentar modificar os objetos de terceiros nos seus testes, já que no Ruby você tem o poder para alterar tudo.
• Teste também o que não deve acontecer, sendo explícito a respeito disso.

Maus sinais

• Métodos de setup longos: você está testando muita coisa ao mesmo tempo e seu design provalmente está acoplado.
• Falta de testes de integração:  você irá perder a sincronia com as alterações que são feitas nos testes unitários.

.
Grande parte do que foi passado na apresentação  se aplica em qualquer plataforma onde você esteja desenvolvendo orientado a testes.

O arquivo PDF com slides da apresentação você pode baixar aqui. O que achei muito legal desses slides é que eles vêm comentados com o texto de base para a apresentação, ou seja, praticamente você pode “ler” a apresentação que foi feita.
.

Link deste post
Tags: bdd, cucumber, dry, fisl, fisl10, linguagens de programação, mock, Prodis, rails, ruby, ruby on rails, stub, tdd, Testes

FISL 10 – Conhecimento e cultura

Com a presença de mais de 8 mil pessoas, e grandes nomes como Richard Stallman, fundador do Movimento Software Livre, Jon “Maddog” Hall Presidente fundador da Linux Internacional, Peter Sunde um dos fundadores do The Pirate Bay, Chris diBona responsável pelo Software Livre no Google, Chris Hofmann diretor de engenharia e projetos especiais da Mozilla Foundation, Nick Nguyen responsável pelos Add-ons Mozilla, entre outros, o FISL 10 foi um grande sucesso, contando até com a presença de nosso Presidente Luís Inácio Lula da Silva.

Em resumo, com palestras de diversos níveis técnicos e didáticos, das quais tive a oportunidade de acompanhar, destaco as seguintes:

• Fábio Akita – Características e recursos do Ruby on Rails para incrementar o Blog em 15 minutos de DHH; (slide, código)
• Lucas Húngaro – TDD e Rails: Mais rápido, mais forte e melhor; (pdf)
• Bernardo Heynemann e Gabriel Falcão – Testes de aceitação com Pyccuracy;
• Leonardo Rochael - IPython para principiantes;
• Fábio Berbert de Paula – Como ingressar no mercado usando software livre;
• Camila Dias – MySQL (resumo da palestra, slide)
• Marco Gomes – Construindo uma empresa de serviços WEB baseada em software livre e colaboração;
• Guilherme Chapiewski – Uso do software livre e introdução à metodologias ágeis (slide)
• Nelson Lago – Empreender com software livre.

A grande lição que transmito com esta jornada, vai além dos conceitos técnicos, a vivência e adquirição de conhecimento trazidos das palavras comunidade, comunicação e colaboração, mostram que o ponto principal a ser focado é a cultura, então seja no desenvolvimento de software, seja na aplicação de metodologias ágeis ou na vida em geral, compartilhe o conhecimento, exponha suas idéias, seus códigos, pois a humanidade não só ganha com isso, mas ela evolui. Então, eis algumas dicas:

Não importa o seu nível de conhecimento – sempre existirá o experiente, o intermediário, o iniciante e o curioso, então compartilhe o que você sabe, crie um blog, participe de fóruns, contribua com algum projeto de código aberto (open source), nem que seja para informar que uma tradução não está correta, que faltou um ponto ou uma acentuação, pois desta maneira você contribuirá para que um curioso se torne um iniciante, um iniciante se torne um intermediário e assim por diante;
Documente suas dificuldades – quando sentir alguma dificuldade na resolução de um problema, na melhorar maneira de aplicar um padrão de projeto, documente como você resolveu e publique seus passos, pois esses passos poderão contribuir para que outros alcancem o mesmo resultado de forma mais rápida;
A melhor forma de aprender é ensinar – seja voluntário, ao explorar uma nova ferramenta, tecnologia, conceito, compartilhe com seus colegas, passe a informação adiante, faça uma apresentação, monte um grupo de estudos. Com certeza o maior beneficiado com isto é aquele que compartilha, pois enraíza o conhecimento;
E por fim, comunique-se – e-mail, twitter e afins, são excelentes ferramentas, mas eu falo de comunicação olhos nos olhos, pergunte o nome do colega ao seu lado, do vizinho à sua frente, sim, aquele que talvez trabalha a anos no mesmo ambiente que o seu, mas você sequer conhece o timbre de voz dele. Descubra com qual tecnologia ele trabalha e se existem formas de ambos se ajudarem, de contribuírem para algo melhor. A comunicação é o elo entre comunidade e colaboração, e ela pode resolver problemas numa velocidade muito maior que qualquer e e-mail,  sms,  mensagem,  etc.

Post original:
http://mauriciodeamorim.com.br/2009/06/29/uma-grande-semana-no-fisl-10

Link deste post
Tags: fils10, fisl, linguagens de programação, Linux, open source, rails, ruby, ruby on rails, tdd, visão

Gedit com cara de TextMate

Para desenvolver com Ruby on Rails em Linux uma boa alternativa para editores de texto é o Gedit com alguns plugins. Longe de ficar igual ao TextMate, mas digamos que assim dá um “gostinho a mais” para escrever alguns códigos, logicamente o intuito aqui não é mudar a “cara” do Gedit somente, mas sim utilizar algumas ferramentas para tornar mais ágil o desenvolvimento, como atalhos, auto-complentar de textos, busca rápida de arquivos dentro do projeto, etc. Existem vários desenvolvedores que estão contribuindo para melhorar o Gedit, então dei uma vasculhada e montei uma configuração interessante para quem está iniciando com Ruby on Rails em Linux.

Estou usando a versão 2.24.2 do Gedit no Ubuntu 8.10 com o tema Mac Graffite.

Plugins instalados por padrão
Vamos começar atualizando os plugins que já estão instalados por padrão.

sudo apt-get install gedit-plugins

ler mais

Link deste post
Tags: Gedit, linguagens de programação, Linux, rails, ruby, ruby on rails, TextMate