Arquivo para a categoria ‘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

.

Locaweb dedica dia ao Software Livre

Terça-feira, 15 de dezembro de 2009 por roberto.klein

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.
2009-12-11 13.13.56
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.
2009-12-11 13.17.43

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.
A14E22E7-E35C-414E-BC52-12542C1E519D
O resultado está publicado no próprio gitorious no branch do Fabio Hisamoto.

Pagamento Certo e Sedex para E-commerce Spree

Sexta-feira, 23 de outubro de 2009 por rodrigo.ortiz

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.

Gem Hirb, alegria aos olhos do desenvolvedor

Quarta-feira, 14 de outubro de 2009 por rodrigo.ortiz

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:

Terminal sem a utilização do hirb

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:

Terminal iniciando o hirb

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:

Terminal com hirb configurado no /config/environments/environments.rb

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/

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

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…)

RailsConf’09: Pandemia de conhecimento

Terça-feira, 12 de maio de 2009 por Erich Machado

O 3o. dia da RailsConf (2o. dia de palestras) foi um dia muito agitado. Tivemos palestras de grandes nomes do desenvolvimento de software, como Neal Ford e Robert Martin.

A palestra do Neal Ford e seu colega, Paul Gross, foi muito interessante. É impressionante ver como eles conseguiram administrar bem o (curto) tempo que tiveram e passar a mensagem de forma eficiente. Em um evento como esses uma boa parte dos palestrantes acaba perdendo um pouco do foco e tenta passar mais informação do que o que cabe na agenda.

Eles falaram de um grande projeto realizado pela consultoria em que trabalham, ThoughtWorks, e sobre as coisas que aprenderam com ele.

Aqui vão alguns conselhos:

  • Lute para manter sua suíte de testes rápida.
  • Invente coisas novas sempre que precisar.
  • Escreva testes inteligentes (eles quiseram dizer que o teste tem que ter um propósito maior do que simplesmente adicionar cobertura ao código).
  • Escale sua infra-estrutura de desenvolvimento da mesma forma com que você escala a sua infra-estrutura de produção.
  • Evite fazer design adiantado. Faça apenas do que precisa ser implementado no momento.
  • Adicione complexidade gradualmente.
  • Não use banco de dados como fila de mensagens (principalmente porque isso pode deixar o DBA muito bravo).
  • Defina bem quais são as regras e os limites do seu projeto, por exemplo, em que situações será permitido utilizar mocks e stubs para realizar testes.
  • Divirtam-se

Para manter a velocidade dos testes funcionais eles utilizaram e recomendam o DeepTest. Para os testes de aceitação em grande escala, utilizaram o Selenium Grid.

Além das recomendações, a dupla também compartilhou as suas impressões com relação ao trabalho em equipe e sobre tecnologia. Sobre trabalhar em equipe:

  • Software tem mais a ver com comunicação do que com tecnologia.
  • Ter a equipe trabalhando junto, no mesmo local, é muito bom.
  • Programação pareada é excelente.

Neal Ford disparou uma piadinha dizendo que “programação pareada dissemina conhecimento mais rápido do que a gripe suína” (a palestra foi bastante descontraída).

Além disso, com relação a lidar com tecnologia:

  • Escalar é difícil, não importa qual tecnologia se esteja utilizando.
  • Rails pode escalar! (isso não é mais novidade para a comunidade, mas é importante reforçar)
  • Atualizar o sistema é difícil. Para eles, isso significou arcar com o custo de 6 semanas de um desenvolvedor para migrar do Rails 1.2.3 para o 2.2.

A palestra teve muito mais conselhos e exemplos, alguns usando a analogia do jogo de “papel, pedra e tesoura”. Os slides estão disponíveis aqui para quem quiser conferir.

RailsConf’09: painel do primeiro dia

Quarta-feira, 6 de maio de 2009 por Hisamoto

O RailsConf’09 começou de fato hoje, ontem foi o dia dos tutoriais, o Erich e eu assistimos as palestras, e agora tá rolando o Birds of Feathers, fizemos uma pequena pausa para escrever o post do dia de ontem que ficamos devendo e o painel do primeiro dia.

O keynote do evento foi do DHH, que falou sobre as mudanças que virão com o Rails 3 e sobre o segredo da produtividade dos desenvolvedores. O que achamos de mais importante, é que de fato o Rails aumenta a velocidade de desenvolvimento, mas se o desenvolvedor não for comprometido com a qualidade do código, renegociando e discutindo com o cliente as features que deverão ser entregues, os ganhos de produtividade com a tecnologia são perdidos.

Em seguida assistimos a excelente apresentação do David Chelimsk,Don’t mock yourself“. Ele mostrou o que são mocks e stubs, as diferenças entre eles, como usá-los de maneira apropriada e no final apresentou um novo projeto, ainda em desenvolvimento, o sttuble.

Ao mesmo tempo, ocorreu um painel com perguntas e respostas sobre o github. Na mesa estavam: Chris Wanstrath (GitHub), Tom Preston-Werner (GitHub), PJ Hyett (GitHub), Scott Chacon (GitHub) e Jon Maddox (Mustache, Inc). Eles responderam algumas questões sobre a estrutura de servidores do github, das features implementadas nos últimos meses e também sobre o novo plugin que integra o mercurial com o git.

A próxima apresentação foi de Ryan Singer da 37signals, que falou sobre os Fundamentos de UI para programadores:

  • Do ponto de vista do cliente, a interface é o programa inteiro
  • Comece pela interface, não pela implementação
  • A interface determina detalhes da implementação
  • Comece por um modelo que permita uma implementação e que faça sentido para os clientes
  • Domain Driven Design: os dois principais padrões são “model driven design” e “ubiquitous language“. A essência do livro está na forma como desenvolvedores e clientes podem colaborar para tornar o software melhor através de um modelo que faça sentido para todos.
  • Contraste: atrativo para os olhos, usar o contraste para determinar a importancia dos elementos da tela, pois isso impede que o leitor tenha que decidir o que é importante na interface que está sendo apresentada. A própria exibição já diz isso.
  • Ações: toda ação tem um princípio, um meio e um fim. Divida toda a ação nessas três partes e deixe isso claro na forma como a interface funciona.
  • Dividir as telas usando as convenções de REST.
  • Nomear os arquivos CSS e JavaScript usando as mesmas convenções dos templates (REST também).

Referência: “The Visual Display of Quantitative Information

De tarde, tivemos a apresentação do Ilya Grigorik (AideRSS Inc.), com o título: “Building a Mini-Google: High-Performance Computing in Ruby“, que falou sobre um algoritmo de classificação e sua implementação em Ruby, a apresentação foi baseada a partir de uma sequência de posts de Michel Nielsen.

Por último, vimos a apresentação do Scott Chacon (GitHub) sobre o git, “Smacking Git Around – Advanced Git Tricks“. A apresentação foi muito densa e apresentada rapidamente (o Scott Chacon fala numa velocidade impressionante!), e precisaremos revisar o material apresentado para escrever um post mais detalhado.

Referências:  apresentaçãoadvanced-git-cheat-sheet.


Switch to our mobile site