Posts com o tag ‘ruby on rails’

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

Sexta-feira, 18 de dezembro de 2009 por Fernando Hamasaki de Amorim

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

.

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

Terça-feira, 30 de junho de 2009 por Fernando Hamasaki de Amorim

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.

Lucas Húngaro

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.
.

FISL 10 – Conhecimento e cultura

Segunda-feira, 29 de junho de 2009 por Mauricio de Amorim

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.

FISL 10

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

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

10º Fórum Internacional de Software Livre – fisl10

Segunda-feira, 15 de junho de 2009 por Fernando Hamasaki de Amorim

No final desse mês estaremos no fisl10, o 10º Fórum Internacional de Software Livre. O evento será realizado entre os dias 24 a 27 de junho, em Porto Alegre.

fisl10

O fisl é o maior evento de software livre da América Latina e até a publicação desse post já possui mais de 5.500 inscrições. A Associação SoftwareLivre.org (ASL), que organiza o evento, espera atingir a marca de 8 mil participantes.

Entre os assuntos que serão abordados, estão:

  • Linux, Ubuntu, KDE, BSD
  • Desenvolvimento em Ruby, Java, PHP, Python, Perl e Smalltalk
  • Desenvolvimento de jogos
  • MySQL, PostgreSQL
  • Robótica
  • Segurança
  • Software livre e negócios

Palestrantes como Richard Matthew Stallma, fundador do Movimento Software Livre, do Projeto GNU e da Free Software Fundation (FSF); Peter Sunde, um dos fundadores do site The Pirate Bay; e John “Maddog” Hall, fundador da Linux Internacional são destaques do evento.

A lista completa dos palestrantes, a programação completa, inscrições e outras informações, você encontra no site do fisl10.
.

Gedit com cara de TextMate

Terça-feira, 26 de maio de 2009 por Mauricio de Amorim

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

(mais…)

Como instalar Ruby on Rails no Ubuntu sob VMware Server e Windows XP

Domingo, 17 de maio de 2009 por Mauricio de Amorim

Logo Ruby on Rails

Uma das grandes dificuldades de quem usa a plataforma Windows é montar um ambiente satisfatório para desenvolver aplicações Web com Ruby on Rails, pois nem sempre podemos usar o que está disponível para Mac e Linux. Minha alternativa para resolver de vez estes problemas de incompatibilidade e perca de tempo descobrindo maneiras para ajustar tudo no Windows, foi partir para a utilização de uma máquina virtual com Ubuntu. Em menos de um dia de trabalho entre configurações, downloads e desenvolvimento tive a felicidade de colocar uma aplicação Web com Ruby on Rails no ar. Então nada melhor que compartilhar minha experiência! (mais…)

Ruby in Steel, brincando com Ruby e Rails no Visual Studio 2008

Quarta-feira, 29 de abril de 2009 por Mauricio de Amorim

Para quem ainda está em dúvida se Ruby é legal ou porque ele é legal, e se é mais fácil desenvolver com Rails para Web ou não, aqui estão algumas dicas para fazer algumas “brincadeiras” nas horas de folga. Garanto que estas brincadeiras vão virar um vício em pouco tempo.
Ruby é uma linguagem apaixonante, mesmo para quem está começando, é muito fácil para escrever e a sensação é que as coisas vão fluindo tranquilamente e “sem dor”.

Detalhe, Ruby in Steel é um produto para o Visual Studio da Microsoft, existe a versão comercial, mas nos links abaixo tudo é “free”, de graça, isto mesmo. Claro que é uma versão minimalista com pouco recursos, mas o suficiente para iniciar a transição. Por quê iniciar a transição? Teste Ruby e teste o Ruby on Rails e logo, logo, Terminal será seu nome e Editor de Texto seu sobrenome, IDE será coisa do passado.

IDE Visual Studio 2008 com Ruby

Esta versão do Ruby in Steel inclui a versão Express (gratuita) do Visual Studio 2008.
Ruby in Steel – Personal Edition 2008

O e-book do Huw CollingBourne também é free, e explica Ruby de uma maneira fácil para quem desenvolve em .Net.
The book of Ruby – Jan 2009

Post original:
http://mauriciodeamorim.com.br/2009/04/11/brincando-com-ruby-e-rails-no-visual-studio-2008/

MVC e Ruby on Rails, uma visão simplificada

Segunda-feira, 23 de junho de 2008 por Joca

Quem me conhece sabe que gosto de simplicidade. Dentre as coisas simples que gosto, tenho especial apreço por explicações simples, pois elas ajudam quem nunca teve contato com um assunto a ter uma primeira idéia e, a partir daí, se aprofundar no tema. Recentemente postei uma explição simples das Metodologias Ágeis de Desenvolvimento. Queria fazer o mesmo para dois termos que têm sido muito falados não só nos blogs da Locaweb, como em vários lugares pela internet.

O primeiro é MVC, que significa Model View Controller. Explicando de forma bem simplista:

- Model: modelo dos dados, normalmente um banco de dados, mas é mais que só interface com BD. O recomendado é que toda regra de negócio fique nele. Por exemplo, numa loja, ao gravar um novo pedido, o modelo faz todo o cálculo de frete, checagem de estoque, processamento de pagamento etc.
- View: como os dados serão vistos e como alguém pode interagir com esses dados, normalmente páginas HTML com forms.
- Controller: é quem interpreta eventos que acontecem na View e manipula os dados que estão no Model, normalmente são ações como listar, procurar, alterar, inserir e deletar dados.

O bacana desse modelo de arquitetura de software é a separação entre essas três camadas distintas da aplicação que permite até que pessoas ou equipes diferentes trabalhem em diferentes camadas, sem impacto no trabalho dos outros.

Como sempre, uma imagem vale mais que mil palavras, mesmo as imagens que contém palavras, então:

Sobre o Ruby on Rails, os especialistas aqui na Locaweb são o Akita e o Gilberto, que explicou como criar um ambiente rails no seu PC Windows, além de várias outras pessoas que estão estudando, mas vou dar minha visão simplista:

Ruby é uma linguagem de programação criada no japão em 1994, como já explicou o André aqui (http://tecblog.locaweb.com.br/?p=10). Quem conhece Perl certamente vai gostar de programar em Ruby.

Rails é um framework, ou um ambiente de trabalho, desenvolvido para transformar a programação em Ruby ainda mais simples e divertida. Rails foi criado por David Hansson:

desenvolvedor dinamarquês de uma empresa americana chamada 37signals, para automatizar o trabalho “chato” de desenvolvimento de um novo sistema.

Quando se inicia a programação de um sistema em Rails, o framework já cria o ambiente MVC incluindo as tabelas de banco de dados (Model), o esqueleto dos Viewers e dos Controllers.

Uma das funcionalidades que mais me impressiona no Rails é o Active Record, que mapeia tabelas a classes, linhas de tabelas a objetos e colunas de tabelas aos atributos dos objetos. Essa prática é conhecida como object-relational mapping (ORM), em português mapeamento objeto-relacional, ou seja, mapear objetos à tabelas de bancos de dados relacionais.

ORM não é novidade, mas a implementação feita em Rails, com o ActiveRecord simplificou em muito ORM pois, ao invés de necessitar de um arquivo de configuração para fazer os mapeamentos, ele se baseaia em convenções e em valores default para fazer o mapeamento. Ou seja, é a simplificação do ORM. :)

Aguardem, em breve teremos mais posts sobre Rails e, para quem quiser testar o ambiente Rails que estamos preparando em nossa Hospedagem Linux, basta se inscrever em:

http://blog.locaweb.com.br/archives/263


Switch to our mobile site