ruby on rails: um estudo de viabilidade em ambientes empresariais
DESCRIPTION
Apresentação de pesquisa onde é feita uma revisão bibliográfica sobre a linguagem de programação Ruby e o arcabouço Ruby on Rails, os quais são utilizados para o desenvolvimento ágil de aplicações para plataforma web. Nesta são analisados diversos requisitos necessários para o desenvolvimento de aplicações eficientes e de forma produtiva.TRANSCRIPT
Ruby on Rails: Um estudo de viabilidade em ambientes empresariais
Trabalho de Conclusão de Curso
Aluno: Rodrigo de Jesus Recio Professor Orientador: Rodrigo Assira@ Dias
Fundação Armando Alvares Penteado -‐ FAAP Faculdade de Computação e Informá@ca
Problema
• O arcabouço Ruby on Rails é maduro para a u@lização no desenvolvimento de aplicações corpora@vas?
• Quais suas vantagens em comparação a seus concorrentes?
Obje@vo
• Ajudar na escolha de um arcabouço para desenvolvimento de aplicações web
• Comparar a linguagem e o arcabouço com seus principais concorrentes no mercado
• Analisar aspectos como produ@vidade, confiabilidade e desempenho
Agenda
• A linguagem Ruby
• O arcabouço Ruby on Rails – Arquitetura – Convenções
A Linguagem Ruby
• Uma linguagem de programação interpretada
• Idealizada em 1993 por Yukihiro Matsumoto
• Baseada no Python e Perl • Suporta múl@plos paradigmas de programação: funcional, orientado a objetos, impera@vo e reflexivo
• Possui sistema de @pos dinâmico
Ruby on Rails
• Arcabouço que permite desenvolver aplicações web apoiadas por banco de dados
• Suporta proto@pação de componentes através de geradores de código
• Favorece convenção no lugar de configuração
Ruby on Rails
• Possui mecanismo de persistência e mapeamento objeto-‐relacional
• Possui sistema de gerenciamento de versões de bancos de dados
• É baseado na arquitetura Modelo-‐Visão-‐Controlador (MVC)
Componentes
• Ac@ve Record (Modelo)
• Ac@on Pack – Ac@on Controller (Controlador) – Ac@on View (Visão)
• Ac@on Mailer
• Ac@ve Support (estende bibliotecas da linguagem Ruby)
Arquitetura MVC
Rails e MVC
Convenções Nomeação de Modelo
Tabela produtos
Arquivo app/models/produto.rb
Classe Produto
Nomeação de Controlador
URL hfp://endereco.com/loja/listar
Arquivo app/controllers/loja_controller.rb
Classe LojaController
Método (ação) listar
Nomeação de Visão
URL hfp://endereco.com/loja/listar
Arquivo app/views/loja/listar.html.erb
Agenda
• Ac@ve Record • Ac@on Pack • Migra@ons
• Segurança
Ac@ve Record
• Componente usado na camada de Modelo (MVC)
• Mecanismo de persistência e mapeamento objeto-‐relacional
• Alterna@va ao modelo de programação centrada de banco de dados
Exemplo de programação centrada de BD
Exemplo de classe modelo referente a tabela com as colunas nome e id
Exemplo de u@lização
Ac@on Pack
• Gerencia recepção de solicitações (ação a ser executada) do navegador e a resposta (página a ser visualizada) correspondente
• Componente usado nas camadas Controlador e Visão
• Controlador é implementado através de subclasse de Ac#onController::Base
• Visão implementada através de Embedded Ruby (ERB)
Exemplo: Controlador e Visão
URL: hfp://exemplo.com/blog/index
Migra@ons
• Mecanismo de versão de banco de dados • Uma subclasse de Ac#veRecord::Migra#on define como fazer e desfazer alterações em um schema de banco de dados
• Cada versão do banco tem um migra@on correspondente
• É possível alternar entre versões de banco usando o comando rake db:migrate VERSION=XXXX
Segurança
Possíveis Vulnerabilidades e Melhores Prá@cas
Segurança: Sessão
• Chave de sessão é armazenada em um cookie no navegador
• Cifrada usando HMAC a par@r de uma chave secreta e os dados armazenados na sessão
• Recomendado chave secreta grande, Rails u@liza 30 caracteres
Segurança: Sessão
• Não é indicado armazenar dados importantes na sessão
• É indicado u@lizar a chave da sessão do usuário para iden@ficação e armazenar os dados no lado do servidor
• É recomendado reiniciar sessão após usuário efetuar logout
Possível vulnerabilidade: Cross-‐Site Scrip@ng (XSS)
• Inserção de código HTML ou JavaScript por usuários maliciosos em páginas vistas por outros usuários
XSS -‐ Prevenção
• No caso onde o usuário não pode inserir nenhum código HTML, usar o método “h(string)” para filtrar cada entrada do usuário e remover código HTML
XSS -‐ Prevenção
• No caso onde HTML é permi@do como entrada, mas não JavaScript, u@lizar o método “sani@ze(string)”:
• Filtra códigos maliciosos em unicode, ascii e hexadecimal
Agenda -‐ Desenvolvimento
• Ruby versus Outras Linguagens • Ac@ve Record versus Hibernate • Ac@on Pack versus JavaServer Faces • Conclusão
Ruby vs outras linguagens
Ruby versus Outras Linguagens
• Baseado no estudo An Empirical Comparison of C, C++, Java, Perl, Python, Rexx and Tcl de Lutz Prechelt que dividiu as linguagens nos grupos script e não script e o ar@go C++, Java, Python versus Ruby de David Howard
Resultado
• Linguagens interpretadas tendem a ter um ciclo de desenvolvimento mais rápido
• Java é bem mais rápido que Ruby
• Sistema de @pos dinâmico de Ruby proporciona maior produ@vidade porém aumenta o risco de ocorrer uma exceção em tempo de execução
Resultados
• O sistema de @pos está@co de Java proporciona um código mais confiável porém diminui a produ@vidade
• Ruby tem um consumo de memória bem menor que Java
Ac@ve Record versus
Hibernate
Ac@ve Record vs. Hibernate
• Gerador de código do Rails permite proto@pação do modelo e de um Migra#on referente a este modelo
Modelo e migra@on gerados
Modelo equivalente em Java • Devem ser implementados manualmente a classe
Modelo e arquivo XML de mapeamento com o banco
Mapeamento XML do Hibernate
Armazenando dados
Ac8ve Record Hibernate
Resultado
Vantagens
• O gerador de código do Rails permite um desenvolvimento mais veloz
• Não é necessário escrever códigos que representam os atributos na classe Modelo
Desvantagens
• Não ter uma representação do modelo relacional na classe Modelo pode tornar-‐se uma dificuldade em projetos mais complexos, onde existam algumas centenas de tabelas e colunas no banco de dados
Ac@on Pack versus
JavaServer Faces
JavaServer Faces (Controlador)
• Ações e condições de acionamento devem ser especificadas manualmente no arquivo faces-‐config.xml:
Ac@on Pack: Ac@on Controller (Controlador)
• Ações são definidas no arquivo config/routes.rb de forma mais abrangente (convenção no lugar de configuração):
Ac@on Pack: Ac@on View (Visão)
• Camada de visão implementada em Embedded Ruby (ERB), exemplo:
JavaServer Faces
• U@liza elementos de marcação está@ca similar ao HTML:
Resultado Vantagens
• Configuração das ações do Rails pode ser feita de forma mais fácil e flexível
Desvantagens
• Não possui uma sintaxe de marcação está@ca similar ao HTML
Conclusão
• Ruby acelera o desenvolvimento e aumenta a produ@vidade
• Ac@ve Record é mais produ@vo em projetos simples mas pode tornar-‐se mais trabalhoso em projetos mais complexos
• O Rails permite gerenciar de forma controlada as alterações de banco de dados proporcionando mais organização e flexibilidade ao desenvolvimento
Conclusão
• JavaServer Faces possui uma sintaxe mais clara e fácil de manter na camada de Visão do que o Rails que mescla código Ruby com HTML
• O Rails não é a prova de falhas, porém é possível prevenir contra possíveis vulnerabilidades de segurança
Ruby on Rails: Um estudo de viabilidade em ambientes empresariais
Trabalho de Conclusão de Curso
Aluno: Rodrigo de Jesus Recio Professor Orientador: Rodrigo Assira@ Dias
Fundação Armando Alvares Penteado -‐ FAAP Faculdade de Computação e Informá@ca