Metodologías y técnicas ágiles más populares

• Kanban, Andrew J. Davison
• Scrum, Ken Schwaber & Jeff Sutherland
• Extreme Programming, Kent Beck
• Lean Software Development, Mary Poppendieck

DHH

• David Heinemeier Hansson
  • DHH más simple
  • Creador de Rails
• Rails
  • Framework open source para desarrollo de aplicaciones web
  • Creado en 2004
  • Su primer versión liberada (1.0) fue en 2005
  • Actualmente en la versión 4.0

Símbolos

• Son como variables prefijados con : (dos puntos)
  • Ejemplos: :action, :line_items, :+
• No es necesario declararlos
• Se garantiza que son únicos
  • No es necesario asignarles ningún valor

Veamos un ejemplo

:uno.object_id  # siempre devolverá lo mismo
"uno".object_id # siempre devolverá diferente

Control de acceso

• Al diseñar la interfaz de una clase es importante definir qué publicaremos al mundo
• Permitir demasiado acceso a nuestras clases, incrementará el riesgo de acoplamiento de la aplicación
  • Los usuarios de una clase que se expone demasiado podrían confiar en detalles de implementación en vez de su interfaz lógica
• Ruby provee control de acceso a los métodos (que son quienes permitirían alterar el estado de un objeto)
• Una regla importante es:
  • Nunca exponer métodos que puedan dejar un objeto en estado inválido

Niveles de protección

• Públicos: los métodos públicos pueden invocarse por cualquiera (no hay control de acceso). Los métodos son públicos por defecto excepto initialize que siempre es privado.
• Protegidos: pueden invocarse sólo por objetos de la clase que lo define y sus subclases. El acceso queda en la familia.
• Privados: estos métodos no pueden ser invocados con un receptor explícito: el receptor es siempre el objeto actual, mejor conocido como self. Esto significa que tampoco puede invocar el método privado de otra instancia de la misma clase.

Acceso a los hashes

• En el ejemplo anterior se utilizan strings como claves

Ejemplo con símbolos

# En ruby >= 1.9
h = { dog: 'canine', cat: 'feline' }

# En ruby < 1.9
h = { :dog => 'canine', :cat => 'feline' }

• Comparado a los arreglos, los hashes tienen una ventaja: se indexan con objetos
• A partir de la versión 1.9 además se recuerda el órden en que fueron insertados los elementos
  • Cuando se itera sobre las entradas de un hash se respeta el orden de inserción

La solución

• Podemos ordenar un poco la idea anterior
  • Hash.new puede recibir como parámetro el valor usado para incializar cada valor del Hash. (por ejemplo cuando se accede a un valor que no existe aún en el Hash)

La misma idea más ordenada

def count_frequency(word_list)
    counts = Hash.new(0)
    for word in word_list
        counts[word] += 1
    end
    counts
end

Ver el ejemplo completo en la carpeta samples/05/words_frequency

Introducción

En samples/05/words_frequency/top_five usamos:

for i in 0...5
    word = top_five[i][0]
    count = top_five[i][1]
    puts "#{word}: #{count}"
end

En cualquier lenguaje esto es natural

Mucho más intuitivo es:

top_five.each do |word, count|
    puts "#{word}: #{count}"
end

# o más simple:
top_five.each { |word, count| puts "#{word}: #{count}" }

Los iteradores each y collect

• El iterador each es el más simple
  • Solo invoca yield para cada elemento
• El iterador collect también conocido como map
  • Invoca yield para cada elemento. El resultado lo guarda en un nuevo arreglo que es retornado

Ejemplos

[ 1, 3, 5, 7, 9 ].each {|i| puts i }

['k','h','m','t','w'].collect {|x| x.succ }

Usando Enumerator como objetos

• Sabemos que es posible usar each_with_index en Array

Ejemplo

result = []
[ 'a', 'b', 'c' ].each_with_index do |item, index| 
    result << [item, index] 
end

Los bloques pueden ser Closures

• Recordamos haber mencionamos que los bloques pueden utilizar variables que están dentro del alcance del bloque
• Veremos ahora un uso diferente de un bloque haciendo esto

Ejemplo

def n_times(thing)
    lambda {|n| thing * n }
end
p1 = n_times(10)
p1.call(3)
p1.call(4)
p2 = n_times("Hola ")
p2.call(3)

Composición de módulos

Creamos nuestra clase Enumerable

class VowelFinder
    include Enumerable
    def initialize(string)
        @string = string
    end
    def each
        @string.scan(/[aeiou]/i) do |vowel|
            yield vowel
        end
    end
end
vf = VowelFinder.new "El murcielago tiene todas"
vf.inject(:+)

Lo mismo hacemos con otras colecciones

[ 1, 2, 3, 4, 5 ].inject(:+)
( 'a'..'m').inject(:+)

Creamos el módulo Summable

module Summable
    def sum
        inject(:+)
    end
end

Lo aplicamos a las clases del ejemplo

class Array; include Summable; end
class Range; include Summable; end
class VowelFinder; include Summable; end

[ 1, 2, 3, 4, 5 ].sum
('a'..'m').sum
vf.sum

Variables de instancia en mixins

• Sin embargo, este uso es riesgoso
• Los nombres de las variables pueden colisionar con otro nombre de la clase u otros módulos.
• Un programa que caiga en este escenario dará resultados erróneos y difíciles de rasterar

Solución

• La mayoría de las veces, los modulos Mixins no usan variables de instancia, sino accessors
• En caso de necesitarlo, utilizar nombres que se prefijen con el nombre del módulo por ejemplo

Resolución de nombres ambiguos de métodos

• ¿Cómo se resuelve el nombre de un método que es el mismo en la clase, que es implementado en la superclase y además definido en uno o varios módulos incluidos?
  • Primero se busca si la clase del objeto lo implementa
  • Luego en los mixins incluidos por la clase. Si tiene varios módulos, el último será el considerado
  • Luego en la superclase

Usando rangos como condiciones

• Generalmente usamos rangos como secuencias y dependiendo del tipo del rango podíamos pedir: min, max, include, etc
• Ahora veremos una forma de utilizar los rangos como condiciones, de forma tal que el objeto rango mantendrá el estado de las comparaciones que macheen desde un valor (el inicial del rango) hasta el final (del rango)

Dos ejemplos

100.times {|x| p x if x==50 .. x==55 }

while line = gets
    puts line if line =~ /start/ .. line =~ /end/
end

Expandiendo collecciones en llamadas a métodos

• Es la idea inversa a la explicación de splat previa

Ejemplo

def five(a, b, c, d, e)
    "I was passed #{a} #{b} #{c} #{d} #{e}"
end

five(1, 2, 3, 4, 5 )
five(1, 2, 3, *['a', 'b'])
five(*['a', 'b'], 1, 2, 3)
five(*(10..14))
five(*[1,2], 3, *(4..5))

Haciendo más dinámicos los bloques

• Al igual que en el caso anterior de splat, podemos necesitar especificar que uno de los parámetros a un método es un bloque

En vez de

(1..10).collect { |x| x*2}.join(',')

Podemos usar

b = -> x { x*2}
(1..10).collect(&b).join ','

Operadores

Otro ejemplo con <<

class ScoreKeeper
    def initialize
        @total_score = 0
        @count = 0
    end

    def <<(score)
        @total_score += score
        @count += 1
        self
    end

    def average
        fail "No scores" if @count == 0
        Float(@total_score) / @count
    end
end

scores = ScoreKeeper.new
scores << 10 << 20 << 40
puts "Average = #{scores.average}"

Operadores

Incluso con []

class SomeClass
    def []=(*params)
        value = params.pop
        puts "Indexed with #{params.join(', ')}"
        puts "value = #{value.inspect}"
    end
end

s = SomeClass.new
s[1] = 2
s['cat', 'dog'] = 'enemies'

Or

• El operador || y el método or funcionan similar
  • Retornan el primer valor si es verdadero, sino el segundo. Ambos son iguales salvo por la precedencia or es de menor precedencia que ||

Ejemplo

nil || 99    # => 99
false || 99  # => 99
"cat" || 99  # => "cat"
b = (false or true)
b = false or true # Check b, Why??

• Es muy común utilizar la expresión: ||= para setear un valor si no fue seteado: var ||= "default value"

La clase Exception

• Ruby define una jerarquía de excepciones que son subclase de Exception
• Esta jerarquía simplifica el manejo de excepciones
  • Al lanzar una excepción, es posible hacerlo con cualquiera de las subclases de Exception o con una clase propia que sea subclase de StandardError o alguna de sus hijas.
• Toda excepción tiene asociado un mensaje y una traza de ejecución
  • Si definimos excepciones propias, podemos agregar información específica

Manejo de excepciones

Analizamos el siguiente código

require 'open-uri'

web_page = open("http://pragprog.com/podcasts")
output = File.open("podcasts.html", "w")
while line = web_page.gets
    output.puts line
end
output.close

• ¿Qué sucede si ocurre un error en la mitad de la transferencia?
  • No queremos guardar una página por la mitad en el archivo de salida

Manejo de excepciones

Agregamos el manejador de excepción

require 'open-uri'

page = "podcasts"
file_name = "#{page}.html"
web_page = open("http://pragprog.com/#{page}")
output = File.open(file_name, "w")
begin
    while line = web_page.gets
        output.puts line
    end
    output.close
rescue Exception
    STDERR.puts "Failed to download #{page}: #{$!}"
    output.close
    File.delete(file_name)
    raise
end

Jerarquía de Exception

Exception
    StandardError
        ArgumentError
        FiberError (1.9)
        IndexError
            KeyError (1.9)
            StopIteration (1.9)
        IOError
            EOFError
        LocalJumpError
        NameError
            NoMethodError
        RangeError
            FloatDomainError
        RegexpError
        RuntimeError
        SystemCallError
            system-dependent exceptions (Errno::xxx)
        ThreadError
        TypeError
        ZeroDivisionError

Jerarquía de Exception

Exception
    fatal
    NoMemoryError
    ScriptError
        LoadError
        NotImplementedError
        SyntaxError
    SecurityError 
    SignalException
        Interrupt
    SystemExit
    SystemStackError

Asegurando la ejecución

• Varias veces necesitamos ejecutar determinado código al finalizar un método de forma segura, es decir independientemente de si se produce un error en la mitad
  • Por ejemplo, tenemos un archivo abierto, que necesitamos sea cerrado antes de finalizar el bloque
• La cláusula ensure cumple esta función
• El código bajo ensure se ejecutará siempre, haya sido una ejecución exitosa o con algún problema

El else de rescue

• El else aplica cuando ninguno de los rescue manejan la excepción
• Tener cuidado porque ensure ejecutará siempre, incluso cuando no se produce un error

Ejemplo

f = File.open("testfile")
begin
    # .. process
rescue
    # .. handle error
else
    puts "Congratulations-- no errors!"
ensure
    f.close
end

Ejemplo de raise

raise
raise "Missing name" if name.nil?
if i >= names.size
    raise IndexError, "#{i} >= size (#{names.size})"
end
raise ArgumentError, "Name too big", caller

• Generalmente no se incluye la traza en librerías

Introducción

• Unit testing es testing que se focaliza en pequeños bloques (o unidades) de código
  • Típicamente se testean métodos individuales o líneas complejas de un método
  • Se contrasta con otras estrategias de testing que ven al sistema como un todo
• Los sistemas de hoy día se desarrollan en capas donde cada una debería poder confiar en que la capa de abstracción utilizada se desempeña correctamente, sin errores.
  • Un error en capas inferiores, causaría errores de propagación a capas superiores

¡Lo probamos con los dientes!

• Usando irb

Escribiendo un programa de test

require 'roman'
r = Roman.new(1)
fail "'i' expected" unless r.to_s == "i"
r = Roman.new(9)
fail "'ix' expected" unless r.to_s == "ix"

• Ruby ya incorpora un framework de tests de unidad:
  • Hasta 1.8 era Test::Unit
  • A partir de 1.9 es MiniTest

Refactorizando el test

Para no repetir los asserts, podemos:

require_relative 'roman'
require 'minitest/autorun'
require 'minitest/unit'
class TestRoman < MiniTest::Test
  NUMBERS = [
             [ 1, "i" ], [ 2, "ii" ], [ 3, "iii" ],
             [ 4, "iv"], [ 5, "v" ], [ 9, "ix" ]
            ]
  def test_simple
    NUMBERS.each do |arabic, roman|
      r = Roman.new(arabic)
      assert_equal(roman, r.to_s)
    end
  end
end

• Podemos testear muchas cosas, por ejemplo el constructor de la clase Roman

Testeamos el rango de Roman

Verificamos si se lanzan las excepciones

require_relative 'roman'
require 'minitest/autorun'
require 'minitest/unit'
class TestRoman < MiniTest::Test
    def test_range
        # no exception for these two...
        Roman.new(1)
        Roman.new(4999)
        # but an exception for these
        assert_raises(RuntimeError) { Roman.new(0) }
        assert_raises(RuntimeError) { Roman.new(5000) }
    end
end

• Analicemos qué más testear en la clase Roman que genera números hasta 4999. Ver carpeta samples/10/romans

Introducción

• Una gema es un formato simple para publicar y compartir código Ruby.
• Cada gema tiene un nombre, versión y plataforma.

Comandos básicos

• Instalar una gema: gem install rake
• Buscar una gema: gem search sinatra
• Listar gemas instaladas: gem list

Introducción

• Mantiene un entorno consistente para las aplicaciones ruby
• Asegura que la aplicación que lo use tenga las dependencias necesarias para que se ejecute sin errores.
• Bundler es una gema: gem install bundler

Ejemplo

Definimos las dependencias en el archivo Gemfile

source 'https://rubygems.org'

gem 'sinatra'

Luego instalamos las dependencias con bundle install o simplemente bundle

Comandos

• Instalar dependencias: bundle install
• Actualizar dependencias a sus últimas versiones: bundle update
• Ejecutar un script en el contexto del bundle actual: bundle exec
• Ver las gemas instaladas en el bundle actual: bundle list
• Ver donde está ubicada una gema: bundle show NOMBRE_GEMA

Gemfile

• Se escribe con una DSL propia de bundler (extraida de Rubygems)
• Puede incluir cualquier código ruby!
• La sentencia gem indica una dependencia y acepta los siguientes parámetros:
  • versión, por ejemplo: '>= 1.1.0', '~> 3.1.2'
  • github (construir la gema a partir de un repositorio en github): github: 'sinatra/sinatra'
  • path: para una gema local

Ejemplo

source 'https://rubygems.org'
gem 'sinatra', github: 'sinatra/sinatra'
gem 'activerecord', '~> 3.1.0'

Usando bundler

• Con declarar las dependencias en el Gemfile no basta, hay que invocar a bundler.
• Hay dos formas:

Bundler requiere los archivos

require 'bundler'
Bundler.require

Bundler configura, pero los require son explícitos

require 'bundler'
Bundler.setup
require 'sinatra'

Introducción

• Es un protocolo de red de la capa de aplicación
• Se ha convertido en el principal protocolo de comunicación entre clientes y servidores
• Cuando un cliente (un browser, una aplicación web, un servicio) quiere interactuar con un servidor sobre HTTP le envía un mensaje (Request)
• Luego, cuando el servidor termina de procesar el Request puede comunicar información al cliente creando un mensaje HTTP propio (Response).

Requerimiento HTTP

• Start line: Es la primera línea del Request. Identifica el Verbo HTTP, a que recurso acceder y denota la versión de HTTP a usar.
• Headers: Proveen información adicional acerca del Request. Ejemplos de headers son: los valores de las cookies para el dominio, el tipo de contenido a aceptar, etc.
• Message Body: Puede contener datos binarios o de texto. Por ejemplo, cuando se sube una imagen a facebook, los datos binarios de la foto son enviados en este campo. Este campo no es obligatorio.

Respuesta HTTP

• El Response usualmente contiene la siguiente información:
  • status: si el Request del cliente fue exitoso, si ocurrió un error, etc.
  • headers: por ejemplo que tipo de contenido se envía al cliente, etc.
  • body: por ejemplo, un documento HTML

Introducción

• Es una DSL para desarrollar aplicaciones y web services en Ruby basado en Rack (Recordar este término, lo nombraremos mucho de aquí en adelante)
• Hace énfasis en el desarrollo minimalista, ofreciendo sólo lo que es esencial para manejar Requests HTTP y entregar Responses a los clientes.
• Tiene una sintaxis simple
• No es un framework:
  • No tiene un ORM
  • No tiene archivos de configuración
  • No hay estructura de archivos
• No fuerza a implementar MVC ni ningún otro patrón

Ejemplo

• Creamos un directorio e inicializamos con bundle init

El Gemfile

source 'https://rubygems.org'
gem 'sinatra'

El server

require 'bundler'
Bundler.require

get '/' do
    'hello world'
end

Y cómo lo testeamos?

• Para testear aplicaciones sinatra usaremos una gema llamada rack-test
• Para testear el ejemplo, haremos un request GET / y esperaremos que nos devuelva un código de estado 200 (OK) y que el body sea 'hello world'

Y si queremos usar mintest/spec

require_relative 'server'
require 'minitest/autorun'
require 'minitest/spec'

include Rack::Test::Methods

def app
    Sinatra::Application
end

describe 'my example server' do
    it 'should succeed' do
        get '/'
        last_response.status.must_equal 200
        last_response.must_be :ok?
        last_response.body.must_include 'hello world'
    end
end

Rutas en Sinatra

• En sinatra una ruta es la dupla de un método HTTP, con un patrón de URL
• A cada ruta se le asocia un bloque
• Las rutas se machean en el orden en que fueron definidas
• Los patrones de rutas podrán:
  • Incluir parámetros nombrados: accesibles usando el hash params o como un parámetro del bloque
  • Utilizar argumentos splat: accesibles mediante params[:splat] o parámtros del bloque
  • Expresiones regulares
  • Incluir parámetros de consulta: ?some_param=value&other=other_value

Ejemplos de rutas: verbos

require 'bundler'
Bundler.require

get '/' do
  'This is GET'
end

post '/' do
  'This is POST'
end

put '/' do
  'This is PUT'
end

patch '/' do
  'This is PATCH'
end

delete '/' do
  'This is DELETE'
end

Ejemplos de rutas: patrones con parámetros

get '/hello/:name' do
    # matches "GET /hello/foo" and "GET /hello/bar"
    # params[:name] is 'foo' or 'bar'
    "Hello #{params[:name]}!"
end

# O usando variables de bloque
get '/hello/:name' do |n|
    # matches "GET /hello/foo" and "GET /hello/bar"
    # params[:name] is 'foo' or 'bar'
    # n stores params[:name]
    "Hello #{n}!"
end

Ejemplos de rutas: patrones con splats

get '/say/*/to/*' do
    # matches /say/hello/to/world
    params[:splat] # => ["hello", "world"]
end

get '/download/*.*' do
    # matches /download/path/to/file.xml
    params[:splat] # => ["path/to/file", "xml"]
end

# O usando variales de bloque
get '/download/*.*' do |path, ext|
    [path, ext] # => ["path/to/file", "xml"]
end

Ejemplos de rutas: patrones basados en regexp

get %r{/hello/([\w]+)} do
    "Hello, #{params[:captures].first}!"
end

# O usando variables de bloque
get %r{/hello/([\w]+)} do |c|
    "Hello, #{c}!"
end

Ejemplos de rutas: con parámetros de consulta

get '/posts' do
    # matches "GET /posts?title=foo&author=bar"
    title = params[:title]
    author = params[:author]
end

Ejemplo de condiciones propias

set(:probability) do |value| 
    condition { rand <= value }
end

get '/win_a_car', :probability => 0.1 do
    "You won!"
end

get '/win_a_car' do
    "Sorry, you lost."
end

Sinatra: valor de retorno

• El valor de retorno de un bloque de ruta determina al menos el cuerpo de la respuesta que se le pasa al cliente HTTP o al siguiente middleware en la pila de Rack.
• Lo más común es que sea un string, como en los ejemplos anteriores.

Sinatra: características (continuación)

<html>
  <head>
    <title>Welcome</title>
  </head>
  <body>
    Hello, <%= @name %>!
  </body>
</html>

Templates: cambiando el directorio de las vistas

set :views, settings.root + '/templates'

• Es importante recordar que los templates deben referenciarse siempre con símbolos, aun si se encuentran en un subdirectorio (en este caso usar: :subdir/template o 'subdir/template'.to_sym). Debe siempre usarse un símbolo sino se toma el string y renderiza directamente.

Filtros: before y after

• Filtros: Los filtros before son evaluados antes de cada petición dentro del mismo contexto que las rutas. Pueden modificar la petición y la respuesta. Las variables de instancia asignadas en los filtros son accesibles por las rutas y las plantillas (idem con after):

Ejemplo

before do
  @nota = 'Hey!'
end

get '/' do
  @nota #=> 'Hey!'
end

Helpers

• Helpers: Son métodos que pueden ser usados en los bloques de rutas y los templates.

Ejemplo

helpers do
  def bar(name)
    "#{name}bar"
  end
end

get '/:name' do
  "#{bar params[:name]}"
end

Sesiones

• Sessions: Una sesión es usada para mantener el estado a través de distintas peticiones. Cuando están activadas, proporciona un hash de sesión para cada sesión de usuario:

Ejemplo

enable :sessions

get '/' do
  "value = " << session[:value].inspect
end

get '/:value' do
  session[:value] = params[:value]
end

Redirecciones

• Redirecciones del navegador: Podés redireccionar al navegador con el método redirect:

Ejemplo

get '/foo' do
  redirect to('/bar')
end

get '/bar' do
  'Hello!'
end

Manejo de errores

• Manejo de errores: Los manejadores de errores se ejecutan dentro del mismo contexto que las rutas y los filtros before, lo que significa que podés usar, por ejemplo, haml, erb, halt, etc.

Ejemplo

not_found do
  'Ruta no encontrada'
end

error do
  # env['sinatra.error'] contains error
  'Disculpá, ocurrió un error horrible' 
end

Configuración

• Es posible correr, por única vez, código de incialización
• Es posible hacerlo dependieno del ambiente indicado con la variable de entorno RACK_ENV

Configuración: Ejemplos

configure do
    # setting one option
    set :option, 'value'

    # setting multiple options
    set :a => 1, :b => 2

    # same as `set :option, true`
    enable :option

    # same as `set :option, false`
    disable :option

    # you can also have dynamic settings with blocks
    set(:css_dir) { File.join(views, 'css') }
end

configure :production do
    # Sólo aplica al ambiente :production
end

Configuración: accediendo a los valores

• Lo valores seteados con set pueden accederse con settings

Ejemplo

configure do
    set :foo, 'bar'
end

get '/' do
    settings.foo? # => true
    settings.foo  # => 'bar'
    ...
end

Ambientes

• Se utilizan 3 ambientes predefinidos:
  • production
  • test
  • development
• Los ambientes se setean mediante la variable del entorno RACK_ENV
• El ambiente por defecto es development
  • En este ambiente, los templates se recargan en cada requerimiento
  • Los manejadores de not_found y error son especiales dado que muestran el stacktrace
• En los ambientes production y test los templates se cachean por defecto

Ejemplo de ambientes

• La aplicación se inicia seteando la variable RACK_ENV de la siguiente forma:
  • RACK_ENV=production ruby my_app.rb

Ejemplo

get '/' do
    if settings.development?
        "development!"
    else
        "not development!"
    end
end

Rack y Sinatra

• Sinatra se apoya en rack, una interface con el webserver modular
• La capacidad más importante de rack es la de soportar middlewares
  • Esto es, componentes que operan entre la aplicación y el web server monitoreando o manipulando los reqs/resp HTTP proveyendo así de varios tipos de funcionalidades comunes
• En sinatra, es simple utilizar los middlewares Rack con el método use

Ejemplo de uso de middleware rack

# Agregando al Gemfile gem 'rack-contrib'
require 'bundler'
Bundler.require

use Rack::Deflater

get '/hello' do
    'Hello World'
end

• Ahora las respuestas se comprimen con gzip

Lectura

• Active Record provee una completa API para acceder a los datos de una base de datos

Ejemplos

# return a collection with all users
users = User.all

# return the first user
user = User.first

# find all users named David who are Code Artists and 
# sort by created_at inreverse chronological order
users = User.where(name: 'David', 
                   occupation: 'Code Artist').
                   order('created_at DESC')

Validaciones

• Active Record permite validar el estado de un modelo antes de que sea escrito a la base de datos
• Existen varios mecanismos para validar y chequear que ciertos atributos no sean blanco, no vacío, únicos, tener un formato específico, etc.
• Las validaciones deben ser consideradas a la hora de persistir datos en la base de datos
  • Por ello, los métodos como create, save y update consideran las validaciones.
  • Retornan false cuando la validación falla y no actualizan el dato en la base de datos
  • Todos estos métodos tiene sus correspondientes con bang! (create!, save!y update!) que son estrictos en cuanto a lanzar una excepción ActiveRecord::RecordInvalid cuando la validación falla.

Introducción

• Garantizan que se guarden datos válidos en la base de datos
• Hay alternativas:
  • Con validaciones en la DB como restricciones o store procedures, dificultan la portabilidad de la aplicación a otros motores. Además no es simple realizar los tests de la aplicación. Sin embargo, no es unamala práctica aplicar restricciones en la base de datos
  • Del lado del cliente usando por ejemplo JS. Pero esta funcionalidad no aplica a todos los usuarios, dado que un navegador puede no diponer de JS o un usuario mal intencionado podría enviar datos no validados de forma intencional
  • Validaciones en el controlador podría ser una alternativa. Sucede que el testeo de los controladores se complejizaría. Por otra parte es una buena idea mantener los controladores bien delgados

¿Cuándo ocurren las validaciones?

• Crear y guardar un objeto emite un INSERT a la DB
• Actualizar un objeto emite un UPDATE a la DB
  • Antes de estas acciones, se realizan las validaciones. Si alguna de las validaciones falla entonces el objeto será marcado como inválido y ActiveRecord no realizará el INSERT o UPDATE
• Hay muchas formas de cambiar el estado de un objeto en la DB. Algunos métodos realizarán validaciones, pero otros no, significando que podrían guardarse datos inválidos en la DB

¿Cuándo ocurren las validaciones?

Métodos que realizan validaciones

create
create!
save # Puede recibir validate: false
save!
update
update!

Métodos que NO realizan validaciones

decrement!
decrement_counter
increment!
increment_counter
toggle!
touch
update_all
update_attribute
update_column
update_columns
update_counters

#valid? e #invalid?

• Independientemente de los métodos antes mencionados que lanzan las validaciones, puede utilizarse valid? e invalid? para lanzar las validaciones

Ejemplo

class Person < ActiveRecord::Base
    validates :name, presence: true
end

Person.create(name: "John Doe").valid? # => true
Person.create(name: nil).valid? # => false

Los errores

• Una vez que se realizaron las validaciones, AR almacenará los errores en errors.messages, una colección de errores indexada por el campo con errores
• Por definición un objeto será valido si la colección de errores es vacía luego de correr las validaciones
• Notar que un objeto creado con new que técnicamente es erróneo, no muestra errores porque aún no se han corrido las validaciones

Helper: acceptance

• Se utiliza específicamente en aplicaciones WEB donde se espera que un checkbox sea tildado por el usuario
• No es necesario que la base de datos tenga un atributo, sino que el helper creará un campo virtual para este propósito

Ejemplo

class Person < ActiveRecord::Base
  validates :terms_of_service, acceptance: true
end

Helper: validates_associated

• Valida las asociaciones relacionadas al objeto
• No debe utilizarse en ambas partes de una asociación porque puede terminar en loop infinito

Ejemplo

class Library < ActiveRecord::Base
    has_many :books
    validates_associated :books
end

Helper: confirmation

• Se utiliza cuando dos campos de texto deben contener el mismo dato: por ejemplo que las direcciones de mail y su confirmación sean similares
• El campo de confirmación no debe existir, sino que crea un campo virtual llamado _confirmation
• El chequeo es realizado sólo si el campo _confirmation no es nil, por lo que debe asegurarse su exsistencia

Ejemplo

class Library < ActiveRecord::Base
    validates :email, confirmation: true
    validates :email_confirmation, presence: true
end

Helper: exclusion/inclusion

• Se utilizan para validar la (ex/in)clusión de valores admisibles

Ejemplo

class Library < ActiveRecord::Base
    validates :subdomain, 
        exclusion: { in: %w(www us ca jp)
end

class Coffee < ActiveRecord::Base
    validates :size, 
        inclusion: { in: %w(small medium large),
        message: "%{value} is not a valid size" }
end

Helper: format

• Validan el formato con una expresión regular que se especifica usando la opción with:

Ejemplo

class Product < ActiveRecord::Base
    validates :legacy_code, format: { 
        with: /\A[a-zA-Z]+\z/,
        message: "only allows letters" }
end

Helper: length

• Valida la longitud de un campo de diversas formas

Ejemplo

class Person < ActiveRecord::Base
    validates :name, length: { minimum: 2 }
    validates :bio, length: { maximum: 500 }
    validates :password, length: { in: 6..20 }
    validates :registration_number, length: { is: 6 }
end

Helper: uniqueness

Más ejemplos

class Holiday < ActiveRecord::Base
    validates :name, uniqueness: {
        scope: :year,
        message: "should happen once per year" }
end

class Person < ActiveRecord::Base
    validates :name, 
        uniqueness: { case_sensitive: false }
end

Validaciones condicionales

• Algunas situaciones ameritan validar si un predicado es verdadero
• Esto es posible con las opciones :if y :unless que reciben: Proc, un string o arreglo
  • Un símbolo: invocará un método del modelo
  • Un string: se interpreta como código rubu como por ejemplo validates :surname, presence: true, if: "name.nil?"
  • Un Proc: permite escribir código inline en vez de delegarlo a un método
  • Un arreglo: combina multiples condiciones. Por ejemplo: if: ["market.retail?", :desktop?]

Introducción

• Las asociaciones simplifican la interacción entre modelos relacionados

Asumamos los siguientes modelos

class Customer < ActiveRecord::Base
end

class Order < ActiveRecord::Base
end

Introducción

• Si Los clientes pueden tener varias órdenes, sin asociaciones, la forma de relacionarlos sería:

El problema

@order = Order.create(
    order_date: Time.now, 
    customer_id: @customer.id)

# Para eliminar un cliente con sus ordenes:
@orders = Order.where(customer_id: @customer.id)
@orders.each do |order|
    order.destroy
end
@customer.destroy

La solución

class Customer < ActiveRecord::Base
    has_many :orders, dependent: :destroy
end

class Order < ActiveRecord::Base
    belongs_to :customer
end

# Crear una orden:
@order = @customer.orders.create(order_date: Time.now)

# Eliminar un cliente:
@customer.destroy

Asociación has_one

• Arma una relación uno a uno con otro modelo pero con una semántica diferente a la de belongs_to
• Esta asociación se utiliza para denotar relaciones uno a uno únicamente

Ejemplo

Proveedores con una cuenta

Asociación has_many :through

class Physician < ActiveRecord::Base
    has_many :appointments
    has_many :patients, through: :appointments
end

class Appointment < ActiveRecord::Base
    belongs_to :physician
    belongs_to :patient
end

class Patient < ActiveRecord::Base
    has_many :appointments
    has_many :physicians, through: :appointments
end

Más gemas

• Además de la gema de rails, el comando rails new agrega otras gemas:
  • sqlite3 - adaptador para bases de datos SQLite
  • sass-rails - habilita el uso de sintaxis SCSS para los estilos
  • uglifier - compresor de JavaScript
  • coffee-rails - habilita el uso de sintaxis CoffeeScript para JavaScript
  • jquery-rails - agrega la librería JavaScript jQuery
  • turbolinks - técnica que acelera la carga de páginas web
  • jbuilder - utilidad para la codificacion de datos en JSON

Puede que no se utilice ni SQLite, SCSS, jQuery u otras gemas, pero la mayoría de los desarrollos las utilizan y por ello se consideran

El detalle del requerimiento

Cliqueando sobre el nombre del archivo, y luego sobre la solapa Headers, se visualiza el detalle del requerimiento y su respuesta

Analizamos lo que muestra el navegador

• Que el requerimiento se compone de:
  • Un request a la URL http://localhost:3000/about.html
  • Que el método HTTP empleado fue GET
  • Los headers del request incluyendo cookies y el identificador del UA
• La respuesta se compone de:
  • El código de estado: 200 OK o 304 Not modified
  • Los headers de la respuesta: incluyendo fecha y hora, así como el identificador del servidor
  • HTML

Ahora podemos analizar cómo el requerimiento a http://localhost:3000/ devuelve dos entradas por el redirect

Analizamos ahora desde el lado del servidor

• Hasta ahora vimos las herramientas que disponemos desde el navegador
  • Pero no podemos visualizar qué es lo que sucede en el servidor

La ventana de consola del servidor muestra:

Started GET "/" for 127.0.0.1 at ...

• Es importante destacar que no hay logs para los archivos servidos desde la carpeta public/

MVC

El siguiente gráfico muestra qué sucede en el servidor durante el ciclo request-response

Algunos expertos opinan que la arquitectura de la web no se ajusta al original diseño de MVC creado para aplicaciones visuales de escritorio

Rails console

• IRB solamente evalúa expresiones que son definidas por la API de ruby
• IRB no conoce las clases de rails
• Rails console carga toda la aplicación rails en una consola IRB

Ejemplo

$ bundle exec rails console
Loading development environment (Rails X.Y.Z)
irb(main):001:0> 

Notamos que se cargó el ambiente de development

Rails logger

• Las aplicaciones rails envían información de diagnóstico a un archivo de log
• Dependiendo del ambiente en el que corre la aplicación, el log será:
  • log/development.log
  • log/production.log
• En el ambiente de desarrollo, todo log escrito en el archivo es además enviado a la consola de donde se corre el comando rails server
• Además de los logs por defecto de rails, podemos usar nosotros logger

Referencias

• Learn Ruby on Rails
• Rails Guides
• Rails Documentation
• Rails Beginner Cheat Sheet
• Railscasts
• Uso de concerns: como poner a dieta los modelos regordetes