Rails 4.1 cambios más destacados

Rails 4.0 a Rails 4.1 nuevas incorporaciones.

Ruby on Rails versión 4.1 trae algunas mejoras importantes y otras no tantas, iremos viendo en cada uno de estos cambios en los siguientes puntos de la presente entrada:

Ver una vista preliminar de las plantillas de correos electrónico, ActionMailer Preview
Diferentes plantllas para las vistas para diferentes dispositivos, Variants – Action Pack
Mayor velocidad en el desarrollo, gracias a la gema Spring
Aumento de seguridad en nuestras aplicaciones con dos significativas incorporaciones, config/secret.yml y CSRF script

ActionMailer Preview – Rails 4.1

El primer cambio que veremos de la versión Rails 4.1, es ActionMailer Preview . Incorpora la posibilidad de mostrar el resultado de las plantillas de email que hemos compuesto cuando estamos en modo desarrollo, ello lo conseguimos mediante la obtención de una URL donde poder visualizarlo, Es una URL local, como podría ser:

http://localhost:3000/rails/mailers/usuario_notificar/welcome

Las primeras tres condicionantes de la URL siempre se cumplen, por el contrario las dos últimas tienen que ver con la clase y el método que deseamos ver el resultado final. Cuando generamos nuestra estructura para el funcionamiento de estas dentro de nuestros proyectos Ruby on Rails.

rails generate Mailer UsuarioNotificar welcome

Genera como de costumbre toda la estructura para los correos electrónicos, y como novedad la creación de la carpeta previews, dentro de test/Mailer.

Dentro de los archivos (dentro de la carpeta previews), tenemos nuestra clase UsuarioNotificarPreview que hereda de ActionMailer::Previews, con cada uno de los métodos, en nuestro caso solamente uno, welcome. Esté llamará a la clase y su método correspondiente para mostrar su correspondiente plantilla. En definitiva, es un pequeño viaje intenso, que acaba en la visualización de la plantilla correspondiente. A continuación te detallamos el viaje de ActionMailer::Previews:

URL -> Clase correspondiente preview (/test/previews/*rb) -> 
Método llamado preview -> 
Clase Mailer -> Método Mailer -> por fin la plantilla

Variants – Rails 4.1

Action Pack – Variants, el objetivo es que podamos mostrar diferentes vistas y que el factor para mostrar uno u otra, sea el dispositivo que realiza la solicitud hacia nuestra aplicación.

¿Qué necesitamos para llevar a cabo Variants?

Las expresiones regulares para identificar el dispositivo que requiere una vista de nuestra aplicación ( móvil, Tablet, Ordenador)

class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception

  before_action :dispositivo

private

  def dispositivo
  	case request.user_agent
  		when /iPad/i
  			request.variant = :tablet
  		when /iPhone/i
  			request.variant = :phone
  		when /Android/i
  			request.variant = :tablet
			when /Android/i && /mobile/i
  			request.variant = :phone
  		when /Windows Phone/i
  			request.variant = :phone
  		else
  			request.variant = :desktop	
  	end 
  end
end

Incorporar el código correspondiente dentro de nuestros controladores para que podamos responder con diferentes plantillas, al igual que cuando nuestra aplicación responde en otros formatos (xml, json, js), ahora además le indicaremos el dispositivo, como veremos en el ejemplo
```
respond_to do |format|
  format.html
  format.html.phone
  format.html.tablet
end
```
Crear plantillas para cada una de los dispositivos que deseamos hacer distinción de plantillas
```
Index.html+phone..erb
Index.html+Tablet.erb
Index.html.erb
```
Podemos probarlo con el navegador Chrome y el emulador que nos facilita, con ello podremos ver las diferentes plantillas.

De nuevo para la facilidad de compresión os dejamos una infografía sobre los pasos recorridos.

Gem spring – Rails 4.1

Nueva gema para mejorar el rendimiento cuando nos encontramos desarrollando la aplicación, esta es capaz de disminuir por cinco la velocidad de desarrollo, principalmente en los siguientes puntos:

Ejecución de Migraciones
Velocidad de arranque del servidor
Ejecución de los test
Rails console, Rails generate y Rails runner

Tendremos en nuestro archivo Gemfile la línea correspondiente a la incorporación de la gem spring

gem "spring", group: :development

Los usuario de Windows, tienen otras gemas a su disposición como Zeus, ya que esta no es compatible para el sistema de Microsoft.

La gema Spring tiene una gran ventaja frente a otras (Zeus), y es que se integra perfectamente con Ruby on Rails no necesitamos cambios en nuestros comandos a la hora de ejecutarlo y trabajar con ella, solamente es necesario ejecutar una comando la primera vez que lo empleamos en nuestro sistema. Este se ejecuta en un segundo plano, no afecta en el trato normal con una aplicación web.

bundle exec spring binstub --all

Hay varios comandos interesantes en Ror para tratar con la gema spring desde la consola

Spring stop. Parar la ejecución de la gema spring
Spring status. Ver el estado actual de la gema, si está encendido o apagado

Enum – Rails 4.1

Active Record Enum, a nivel de aplicación tenemos la posibilidad de administrar campos que en nuestra base de datos representan números enteros y a nivel de aplicación podemos identificarlos con estados, con ayuda de los símbolos de Ruby, aunque(repetimos) a nivel de datos físicos en la base de datos seguiremos teniendo valores numéricos. Ejemplo:

Podemos tener un campo artículo con tres estados :borrador, :publicado, :papelera y trabajar con ellos a nivel interno de Rails.Vamos a ver que ventajas y precauciones debemos de tomar.

Ventajas de Enum

Reduce el tamaño de la base de datos, ya que si utilizamos otro tipo de datos como String, evidentemente es más pesado y en consecuencia aumetaría el tamaño de esta.
La legibilidad del programa aumenta, ya que al NO tratar con simples campos númericos, sino con símbolos identificativos conlleva a una mejor lectura.

Precauciones con Enum de ActiveRecord

No alterar los estados, vuelve inestable a Rails. Con alterar nos referimos a cambiar el order, insertar o borrar un estado.
No tener dos campos Enum,si con alguno de ellos compartiendo el mismo nombre, podemos llevar a la inestabilidad de Rails .
Al analizar los datos de nuestra base de datos, tendremos que tener en cuenta que se almacena números enteros.

Class Articulo < ActiveRecord::Base
	enum estado: [:usado, :nuevo, :vendido]
end

Los comandos que podemos emplear para trabajar con los enumeradores en Ror 4.1 son los siguientes, para ello puede ejecutarlos estos desde la consola de Rails

articulo = Articulo.find(1)
articulo.vendido? #Preguntamos si el artículo tiene el estado vendido
#=>false

articulo = Articulo.find(1)
articulo.vendido! #Cambiar al estado vendido
#=>true

articulo = Articulo.find(1)
articulo.estado #Muestra el estado actual del artículo
#=>vendido

Articulo.estados #Muestra todos los estados de campo enum
#=>[:usado, :nuevo, :vendido]

Sí en un futuro tuvieras que ampliar los estados o alterar los nombres, tendremos que realizar un mapa asociando cada estado con el número que representa en la base de datos.

enum estado: {usado: 1, nuevo: 2, vendido: 3}

Secret.yml

Es el lugar donde almacenaremos los datos sensibles de nuestra aplicación. En anteriores versiones de Ruby on Rails teniamos que generar un archivo e introducirlo en la carpeta inicializers. Ahora ya Rails 4.1 lo crea por nosotros en la carpeta config/secrets.yml.

Aquí es donde introduciremos los datos sensibles de nuestra aplicación, tales como KEY API, Heroku, GIT etc… Otra dato interesante es, como podemos recoger los valores almacenados en el archivo secret.yml, del siguiente modo

Rails.application.secret.[KEY_a_recoger]

CSRF(cross site request forgery)- Aumento de la seguridad

La versión Ror 4.1 viene con un aumento en la seguridad contra los ataques CSRF y en concreto con peticiones por script. Si los lectores recuerdan este tipo de ataque se refiere, cuando un usuario está validado en una web, y un hacker conoce este hecho, podrían mandarnos un enlace(oculto), para que realicemos una operación sobre esa web a la que estamos validados y realizar alguna acción que no haríamos si fueramos conscientes.

En concreto el aumento de seguridad viene para peticiones XHR, ya sea con el método get o post, nosotros tendremos que implementar un simple cambio en nuestros test, para dichas peticiones.

:post, :create, format: :js # Versión Rails 4.0
:xhr :post, :create, format: :js #Versión Rails 4.1