Libro Rails (2)

Versión 0.583

1) Temario: 1) Temario: 2) Motivación ¿Qué es Rails? ¿Por qué utilizar ruby on rails para mi aplicación? Deventajas de utilizar Ruby on Rails ¿Cómo está estructurado este libro? Sección I 3) Instalando las herramientas OSX Linux En Linux y OSX 4) Estructura de un proyecto en rails 5) Creando nuestra primera página web con rails Consola secuestrada. Creando nuestra primera página Introducción a controllers Errores de novato Introducción a las vistas Cómo convertir esta página en la página principal Creando nuestra segunda página Creando la ruta Creando un método en el controller Creando la vista. Agregando un link a una página interna interna 6) Agregando imágenes a nuestra primera página Los Assets El asset path Incorporando imágenes El método asset_path El método image_tag 7) Nuestra primera página con layout.

El Layout Incorporando CSS Incorporando Javascript Incorporando imágenes (u otros assets) dentro del CSS y del JS ¿Qué es la precompilación de assets? El entorno La carpeta assets de vendor Agregando una carpeta nueva al asset_path Verificando Verifi cando el asset_path Incorporando tipografías locales Consecuencias de Sprockets Incorporando bootstrap. CDN Descargando los CSS Glyphicons Vistas parciales Cargando el navbar de bootstrap como una vista parcial Cargando un layout distinto Desafío 8) Creando un formulario de registro El tag form Revisando los parámetros enviados Guardando los datos Creando el primer modelo Corriendo las migraciones Rails console Creando un usuario Leyendo los usuarios desde la base de datos Guardando los usuarios dentro de rails Cambiando la página de inicio Desafío 9) Formulario 2.0 Creando un proyecto nuevo Enviando un formulario por POST

MVC in a nutshell Form y action El método form_tag Mostrando los resultados del formulario Guardando los resultados Redirect_to Variables flashs Mostrando todos los usuarios en la base de datos Desafío 10) El gemfile Sección II 11) Deployment en Heroku Tipos de hosting Servidor propio Hosting clásico VPS PAAS Instalando el Toolbelt de heroku Claves SSH Repositiorio GIT Configurando GIT Creando el repositorio git Subiendo la aplicación a Heroku Creando el proyecto en heroku Setup del proyecto para deployment Subiendo los cambios a producción Razones por las que el paso de deployment puede fallar Revisando errores Sobre la precompilación de assets Migrando la base de datos de producción Cambiando el nombre de la aplicación en Heroku Desafío 12) Configurando el dominio (o subdominio) Configurando dominios cuyas autoridades no soportan redireccionamiento redireccionamiento tipo CName Tips de mantención

Entrar a la consola del proyecto en producción Ver los últimos logs Dejar una consola con los logs corriendo Descargando la base de datos de heroku Desafio Sección III 13) SQL PostgreSQL Instalando PostgreSQL en OSX Instalando PostgreSQL en Linux Entrando a PSQL Insensible a las mayúsculas Creando usuarios Cambiando la clave Dando acceso de superusuario Listando a todos los usuarios creados en la base de datos. Creando una base de datos Listando una base de datos. Botando una base de datos Conectándose a una base de datos Manejo de tablas Introducción a tipos de datos. Creando una tabla Manipulando valores de una tabla Insertando valores Leyendo valores de una tabla. Actualizando valores valores de una tabla Borrando datos de una tabla Modificando una tabla Agregando una columna Removiendo una columna Constraints Evitando valores nulos El constraint Unique La clave primaria

Creando una tabla con primary key Ordenando los resultados. Mostrando los resultados ordenados por edad Mostrando los resultados ordenados por nombre alfabéticamente pero en reverso. Limitando la cantidad de resultados Conteo Select distinct Distinct y count Guía de ejercicios Peliculas CRUDS Sorting Conteo Productos 14) SQL con más de una tabla Integridad referencial Ambiguedad en los nombres nombres Joins Tipos de joins Left Outer Join Right Outer Join Full Outer Join Tipos de relaciones Relaciones de uno a uno Relaciones de 1 a n Relaciones de n a n La clave foránea Ejercicios Shopping movieDB Relaciones n a n Exportando datos 14) Modelando con SQL

Modelando un blog Ejercicio Modelando Tinder Ejercicios de diagrama Ejercicios de SQL Modelando un carro de compras Ejercicio Sección IV: Backend 15) Rails con PSQL Instalando postgre en un proyecto existente Creando un proyecto con postgreSQL El error de socket 16) Los modelos en rails Los modelos como mapas a los objetos (ORM) Creando modelos Convención de nombres Creando un modelo vacío Creando un modelo con diversos campos Migraciones El archivo schema.rb Creando migraciones. Agregar una columna Remover una columna Generadores mágicos Revirtiendo una migraciones Enmendando un error. Cuidado con los branches Botón de autodestrucción Destruir un modelo Agregando un campo extra. Con helper Sin helper Correr las migraciones Revisar las migración generada Probar un modelo

Creando una FK con índice. Getters y setters El archivo seed Atributos virtuales Ejercicio 17) Reglas del negocio Protegiendo la integridad de los datos Validando Validan do la presencia de un campo Validando Validan do que el campo sea único Validaciones Validaci ones custom Valores iniciales Callbacks Ejercicios 18) Relaciones entre modelos Relaciones 1 a 1 Borrando una relación en cascada. Graficando las relaciones Relaciones de 1 a n El método build Múltiples relaciones de 1 a n Has many :through Relaciones n a n 19) Testing unitario de modelos Los fixtures Estructura de un test de modelo Formas de escribir un test El método assert Corriendo tests Cargando los fixtures en los tests 20) Creando un Blog Construyendo el modelo Construyendo los tests Test para modelo sin campo presente Test para modelo con campo único

Test para probar la relación Test de pertenencia Test para diferencias de tiempo Desafios 21) MVC Arquitectura REST Sca!old Strong parameters Nota sobre las migraciones Probando los strong params 22) El archivo de rutas a fondo Introducción al archivo de rutas El archivo routes.rb Rake routes Rutas sin parámetros Ruta con controller Rake routes a fondo Prefix: El prefijo Verb, el verbo URI pattern URI Controller#Actio Controller#Action n El archivo routes a fondo ruta sin controller Cambiando el prefijo Crear una ruta con un parámetro Rutas anidadas Crear una ruta que recibe dos parámetro Query strings Resources member vs collection member Collection 23) Rutas anidadadas y métodos REST anidados

Introducción a rutas anidadas Creando un sca !old anidado Testeando una ruta anidada Obteniendo y mostrando los resultados. El detalle del tweet Formulario para un nuevo tweet Creando el método create Manejando el redireccionamiento del create. 22) Relaciones n a n Implementando relaciones has_and_belongs_to_many Borrando la asociación: Testeando la relación Implementando relaciones con has_many :through Has_many through vs Has_and_belongs_to_ Has_and_belongs_to_many many Ejercicio practico de uso 24) Haciendo un cloudtag Creando datos para la nube de tags Creando el controller y cargando los datos para hacer la nube de tags Creando la vista con la nube de tags 25) Devise Empezando con devise Creando el modelo de devise Ingreso, registro y salida login or logout El objeto current_user Modificando los formularios de ingresar y registro Agregando un dato al modelo de usuarios usuarios Bloqueando el acceso 26) Devise avanzado Agregando el rol rol de usuario Agregando el campo Enums al rescate Testeando los accesos Códigos completos:

Tests Pages Controller Fixture de usuario Generando los controllers de devise Cambiando la página despues de registrarse Cambiando la página después de ingresar Configurando action_mailer para enviar correos con gmail Protegiendo las claves con dot-env Configurando Heroku para dot-env Quiz 27) Autorización con CanCanCan ¿Cuándo no utilizar CanCanCan? Instalando CanCanCan El árbol de habilidades Revisión de habilidades Bloqueo Manejo de conexiones no autorizadas Testeando las habilidades Habilidades basadas en la propiedad Habilidades en recursos anidados 28) Polimorfismo 29) Subiendo archivos con carrirewave Instalando carrierwave Generando el uploader Probando desde rails console. Creando una formulario con archivos 30) Amazon S3 Configuración para la gema de carrierwave-aws IAM Agregando las claves claves de entorno a heroku heroku 31) Optimización n+1 queries en ruby on rails ¿Cuándo ocurre el problema de n+1 queries ? 32) Javascript, jQuery y Turbolinks Como organizar nuestro javascript:

Turbolinks Ejemplos de uso 33) Manejo de gráficos Haciendo los queries Generando los gráficos 34) Fullcalendar Agregando el plugin plugin Cargando el fullcalendar 35) Envió de correos con Action Mailer Intro Creando nuestro mailer Modificando el mailer y como probarlo Crear un método para dar la bienvenida a quien se registra en nuestra pagina Enviando el correo usando ActionMailer y Gmail ActionMailer y Devise Devise Primera Opción: creando el controlador de devise para el usuario Segunda Opción: modificando el modelo de usuario ActionMailer y ActiveJob: deliver_now deliver_now,, deliver_later? ActiveJob y deliver_later deliver_later 36) Testings automatizado con Guard Instalar Guard en nuestro proyecto Configurar Guard Configurar Minitest-Reporters Correr Guard para automatizar el testing 37) Rails y Nginx con Passenger en Ubuntu: Preparando nuestro entorno de producción (DigitalOcean). Introducción Acerca de esta guía. Convenciones. Paso 0 – Como acceder a nuestro servidor Invalid Locale Warning Configurar el timezone en nuestro servidor Acerca del usuario usuario Root

¿Cómo ingresar sin tener que ingresar la clave cada vez que nos queremos conectar a nuestro servidor? Paso 1 – Instalación de RVM Paso 2 – Instalación de Ruby y de Rails Paso 3 – Instalación de Nginx y Passenger Ahora que tenemos el servidor preparado preparado podemos instalar Nginx Nginx con Passenger: Passenger: Paso 4 – Habilitando Passenger en Nginx Paso 5 – Instalación y configuración de Postgres. Instalación Creación de un usuario en postgres Creación de la base de datos Paso 6 – Crear un Server Block Paso 7 – Ultimos detalles Extras 38) Deployment con Capistrano. Introducción Acerca de esta guía. Convenciones. Paso 0 – La Aplicación Paso 1 – Añadir Capistrano a nuestra app. Paso 2 – Preparación de nuestro proyecto Paso 3 – Tareas personalizadas Paso 4 – Conectando el servidor con el repositorio Añadir la llave en Github Github Añadir la llave en Bitbucket Bitbucket Paso 5 – Deploy! Cómo se hace? y qué hace? Ahora que sabemos cómo y qué hace Capistrano Capistrano haremos un un deploy de nuestra app

2) Motivación ¿Qué es Rails? Rails en un framework especializado en la construcción de aplicaciones web, su principales ventajas es que es sólido, rápido y escalable. La versión actual de Ruby on Rails es 4.2 Rails no es lo mismo que Ruby, Ruby es un lenguaje de programación orientado objetos y Rails es un conjunto de herramientas construídas en Ruby para la construcción de aplicaciones web.

¿Por qué utilizar ruby on rails para mi aplicación? Ruby on Rails es impresionantemente efectivo para la construcción de aplicaciones web, con sólo un par de líneas de código puedes tener una mini aplicación web funcionando, además traer un conjunto de herramientas permite construir aplicaciones complejas y escalarlas a niveles enterprise con equipos de programación relativamente pequeños. Por otro lado también es sorprendemente rápido para la construcción de prototipos, para una persona entendida en el tema es posible crear un prototipo funcional de un proyecto y dejarlo subido en internet en sólo un par de horas.

Deventajas de utilizar Ruby on Rails Es un framework complejo y ruby no es tan masivo como otros lenguajes como PHP por lo que cuesta un poco más encontrar programadores, sin embargo tiene una muy buena comunidad y es fácil encontrar documentación y componentes para todo lo que necesitas, además día a día el mundo de la informática a empezado a reconocer las ventajas de ruby on rails y ha empezado a migrar a este maravilloso framework. Otro aspecto a considerar es la curva de aprendizaje de este framework que es bastante dura. Ruby on Rails tiene muchas componentes que vamos a dicutir a lo largo de este libro y muchas cosas dan la impresión de funcionan solas y por arte de magia y es por eso que es difícil de aprender pero muy poderoso cuando se le domina. Finalmente está el tema del rendimiento, Ruby on Rails es un framework con muchas componentes por lo mismo tiene un gran footprint, o sea que es pesado, y eso conlleva a que se necesitan servidores más potentes para atender la misma cantidad de usuarios, por otro lado es bastante más sencillo construir aplicaciones que en otros framework.

Tanto Ruby como Ruby on Rails están pensandos en la felicidad del programador en lugar de la eficiencia del programa.

¿Cómo está estructurado este libro? Este libro cumple dos funciones, en primer lugar es una guía práctica de aprendizaje y en segundo contiene los pasos necesarios para construir diversos proyectos tipos de los cuales se pueden sacar varias ideas para emprendimientos emprendimientos.. Este libro se compone en 5 grandes secciones. Front-end con rails:

Donde aprenderemos todo lo necesario para crear páginas web con rails, y a manejar correctamente el asset_path, crear pequeños formularios y entender los conceptos básicos de MVC. Deployment con heroku:

Donde aprenderemos a subir aplicaciones a la web, y aprenderemos a configurar una página .com o cualquier otro tipo de dominio. SQL y modelado de bases de datos

Donde aprenderemos a manejar bases de datos en la suficiente medida para entender como funciona Rails, como realiza las consultas y como optimizarlas. Back-end con Rails

Donde aprenderemos a construir aplicaciones web con bases de datos y autenticación de usaurios con controles de acceso y sistemas de pago. Deployment con Amazon y VPS

Finalmente aprenderemos como subir nuestra aplicación a entornos enterprise como Amazon y VPS y configurar nuestros propios servidores ocupando NginX.

Sección I Front-end No todo lo que brilla es oro

3) Instalando las herramientas OSX Uitlizando la versión de ruby que viene instalada de fábrica instalaremos Homebrew, un administrador de paquetes para OSX. Para eso abriremos la terminal y pegaremos lo siguiente:

1

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/i

Linux No es necesario instalar ningún administrador de paquetes, al mayoría de las distribuciones viene con alguno incluído, ubuntu ocupa apt-get

En Linux y OSX Ahora instalaremos RVM, un programa que nos permite tener instalada diversas versiones de ruby y actualizarlo sin dolor, existen otros como Rbenv y chruby, las diferencias son menores y sólo afectarán en la última parte de deployment así que para uniformar el proceso recomendamos a todos instalar RVM. Correr este comando sólo en OSX

1

brew install rvm

Correr este comando sólo en Linux

1

apt-get install rvm

Es importante leer siempre los logs de la instalación para asegurarnos que haya terminado exitosamente o poner los comandos que nos pida en caso de que no. Con RVM instalado y los logs leídos (y asegurado de que todo terminó OK) ahora hay que reiniciar la terminal, luego podremos correr:

1

rvm install 2.2.3

Nuevamente esperaremos que termine de correr, esto puede demorar ya que necesita compilar los binarios de ruby. Una vez terminado el proceso debemos verificar que quedó instalado, esto lo podemos hacer con el comando:

1

rvm list

Eso nos muestra todas las versiones de ruby instaladas con RVM, de las cuales podemos escoger una con:

1

rvm use 2.2.3

O podemos establecer nuestra versión por defecto con:

1

rvm --default use 2.2.3

Para asegurarnos que estamos sobre la versión correcta debemos correr el comando:

1

ruby -v

Finalmente instalaremos rails con:

1

gem install rails

Las gemas que se instalan dependen de la versión de ruby, si cambiamos la versión tendremos que instalar rails nuevamente. Rails trabaja por defecto con SQLite es cuál es suficiente para construir prototipos pero queda corto a la hora de construir aplicaciones potentes, durante el capítulo de Heroku veremos como instalar la gema de postgreSQL

Preguntas 1. ¿Qué es RVM? 2. ¿Cómo mostramos todas las versiones que tenemos instaladas de ruby?

3. ¿Cómo cambiamos la versión que estamos ocupando de ruby? 4. ¿Con que motor de base de datos trabaja rails por defecto?

4) Estructura de un proyecto en rails Archivo

Para qué sirve

G emfile

Administrar librerías depencias del proyecto

Gemfile.lock

Muestra todas las dependencias, generado a partir del Gemfile

README.rdoc

Para documentar el proyecto

Rakefile

Para crear tareas rake

app

Toda la aplicación, assets, vistas, controllers y modelos van dentro

bin

Contiene los binstubs, los cuales son wrappers sobre gemas ejecutables

config

Directorio con archivos de configuración de rails, los entornos y la base de datos

config.ru

Contiene la configuración de Rack

db

Continee la información de la base de datos, el archivo de sqlite3 y las migraciones

lib

Modulos para la aplicación

log

Registro de los errores

public

Assets públicos

test

Scripts para tests automatizados

tmp

Para archivos temporales necearios durante la ejecución de rails

vendor

Assets de terceros

5) Creando nuestra primera página web con rails Objetivos 1. Aprender a crear un proyecto en rails desde cero 2. Definir la página de inicio de un proyecto rails 3. Conocer el lenguajes de templates erb 4. Crear accesos a nuevas páginas

Rails es un framework MVC, esto quiere decir que divide la información a lo largo de 3 capas principales, el modelo, la vista y el controlador. En este capítulo abordaremos las componentes de vista y controlador creando una página estática con Ruby on Rails. Para empezar desde el terminal crearemos nuestro primer proyecto una simple página estática pero sobre rails.

1

rails new landing1

Luego entraremos a la carpeta del proyecto y corremos el servidor.

1 2

cd landing1 rails s

Para verificar que todo funcione abriremos el navegador y entramos a la página

localhost:3000

Consola secuestrada. Mientras esté corriendo el servidor en la consola, esta estará secuestrada.

Esto quiere decir que no la podemos seguir utilizando para lanzar comandos y por lo tanto t enemos que abrir un tab nuevo para poder seguir trabajando. Para terminar el servidor, o sea cerrarlo sin cerrar el tab podemos utilizar programa devolviendonos el control para poder ejecutar comandos.

ctrl + c y eso terminará el

Creando nuestra primera página Introducción a controllers Para empezar con rails vamos a partir creando una página estática, para eso vamos a crear un controller que por ahora lo entenderemos como un grupo de páginas. Por ejemplo, si creamos el controller grupo1, nuestras páginas serían: localhost:3000/grupo1/inicio localhost:3000/grupo1/formulario Tanto los controllers como los modelos y vistas (los cuales veremos despúes) se pueden crear manualmente o con el generador de rails. Para crear un controller con el generador tenemos que escribir:

1

rails g controller nombre_grupo pag1 pag2 pag3 ...

Por ejemplo si queremos crear únicamente la página inicial (index), lo hacemos de la siguiente forma:

1

rails g controller pages index

Es convención de rails que los controller siempre tengan un nombre plural, y hace sentido pensando en que son un grupo de páginas. Obtendremos como resultado en el mismo terminal:

create route invoke

app/controllers/pages_controller.rb get 'pages/index' erb

create

app/views/pages

create

app/views/pages/index.html.erb

invoke create invoke

test_unit test/controllers/pages_controller_test.rb helper

create

app/helpers/pages_helper.rb

invoke

test_unit

invoke invoke create invoke create

assets coffee app/assets/javascripts/pages.coffee scss app/assets/stylesheets/pages.scss

Esto nos muestra todos los archivos creados y modificados, por ahora nos interesan sólo dos, el archivo de rutas route get 'pages/index' y la línea que dice donde se creó la vista app/views/pages/index.html.erb Antes de proceder a explicar las vistas y el archivo de rutas, veamos lo creado, para poder hacerlo, podemos acceder a la página que creada a través de la URL: http://localhost:3000/pages/index

Esto sólo funcionará si el servidor está corriendo (hay una consola con el código.

Errores de novato

rails s y si no hay errores en

1) No tener el server corriendo Revisar rails s 2) No haber cargado el server en la carpeta correcta Volver a la terminal ver donde está corriendo el server 3) Haber creado el controller con nombre en singular Podemos destruir el controller con

rails destroy controller pages

Introducción a las vistas Actualmente sólo tenemos un título y un párrafo pero aquí es donde podemos empezar a agregar nuestro contenido. Para eso podemos abrir el archivo app/views/pages/index.html.erb y modificar el HTML, incluso podemos escribir ruby, esto lo podemos hacer gracias al lenguaje de template de ruby llamado erb, por eso el formato del archivo es .html.erb Para escribir ruby tenemos que hacerlo dentro de las expresiones en <%= %> y <% %>, la primera expresión se ocupa para mostrar el contenido, el segundo sirve para evaluar, miremos los siguientes ejemplos:

1 2 3

<% a = 2 %> <%= a %> <%= b = 2 %>

Esto mostraría dentro del navegador 2 2 el primer dos correspondiente al valor de 2, y el segundo al valor de b, pero la primera expresión no se muestre porque <% %> no incluye el signo igual =

¿Esto quiere decir que podemos enviar ruby al navegador del cliente?

No, todo el contenido del archivo será transformado a HTML por rails antes de enviarlo, por lo que el navegador jamás ve nada relacionado con rails.

Cómo convertir esta página en la página principal

Si con nuestro navegador entramos a la dirección localhost:3000 veremos el aviso de rails, pero que pasa si queremos que la página que acabamos de crear sea la página principal, para eso tenemos que modificar el archivo config/routes.rb el cual es el encargado de manejar todos los enrutamientos. Dentro del archivo config/routes.rb encontraremos una línea comentada que dice:

1

# root 'welcome#index

Esta línea es un recordatorio de rails que nos dice como podemos definir una página inicial, para utilizarla vamos a descomentarla (remover el ‘#’) y luego apuntar al controller y la página respectiva, o sea en nuestro caso debería decir:

1

# root 'pages#index'

Si ahora entramos a localhost:3000 veremos la misma página.

Creando nuestra segunda página Ya no podemos ocupar le gnerador de controllers puesto que ya tenemos el controller generado y no queremos sobreescribir los archivos. Una solución sería ccrear un segundo controller pero no es necesario crear un controller por página. Para crear una seguna página vamos a: 1. Crear una ruta a la pagína 2. Crear un método en el controller 3. Crear la vista. 4. Agregar el link a la página nueva. (esta parte no es estrictamente necesesaria) Para nuestra prueba vamos a crear la página about (nosotros)

Creando la ruta Para agregar la ruta nueva debemos abrir el mismo archivo de rutas que abrimos anteriormente config/routes.rb dentro de el agregaremos un get, sin los comentarios que vienen por defecto el archivo de rutas, este se debería ver así:

1 2 3 4 5

Rails.application.routes.draw do get 'pages/index' get 'pages/about' root 'pages#index' end

Existe un comando que nos permite verificar las rutas creadas, este comando se llama rake routes y lo tenemos que correr en alguna terminal que no esté secuestrada dentro de la carpeta del proyecto. Al realizar rake routes, obtendremos:

Prefix Verb URI Pattern

Controller#Action

pages_index GET

/pages/index(.:format) pages#index

pages_about GET

/pages/about(.:format) pages#about

root GET

/

pages#index

Más adelante de este libro analizaremos más a fondo esta información, por ahora sabemos que es correcta porque se incluyó dentro del columna que dice URI Patten la página /pages/about , y con esto terminamos el paso de agregar la ruta de la página. Si nos hubiésemos saltado este paso, (o comentamos el get ‘pages/about’ que pusismos en el archivo config/routes.rb e intentamos entrar a la página obtendríamos este error.

Cada vez que tengamos un error de rutas, sabemos que el archivo culpable es routes.rb. Ahora si intentamos saltarnos el paso 2, y entrar directamente a la página localhost:3000/pages/about veremos el siguiente error.

The action ‘about’ could not be found for PagesController O sea nos fala la acción.

Creando un método en el controller Anteriormente habíamos hablado del controller, pero asumimos que funcionaba de forma mágica, ahora vamos a tener que modificarlo para agregar una página nueva, para eso abriremos el archivo app/controllers/pages_controller en el editor, y veremos:

1 2 3

class PagesController < ApplicationController def index end

El PagesController, es un controller que hereda de ApplicationController, dentro de el cada método llama a su respectiva vista, pero lo hace de forma implícita, esta vista se encuentra dentro de views/pages/index.html.erb Entonces si ya tenemos una ruta para about el paso siguiente es agregar un método (que es lo mismo que una cción) dentro de la clase:

1 2

def about end

Creando la vista.

Con la ruta y el método del controller creado ahora procederemos a crear el archivo views/pages/about.html.erb y dentro de el podemos agregar lo que queramos. Finalmente podemos acceder a la página nueva si entramos

localhost:3000/pages/about

Agregando un link a una página interna Rails crea variables para todas nuestras páginas internas, para poder ver como se llaman esas variables tenemos que ocupar rake routes

Prefix Verb URI Pattern

Controller#Action

pages_index GET

/pages/index(.:format) pages#index

pages_about GET

/pages/about(.:format) pages#about

root GET

/

pages#index

La columna que dice prefix son los nombres de la variable, bueno casi, es un prefijo porque hay dos, aquellas que terminan en path y contienen la ruta relativa, y aquellas que terminan en url que contienen la ruta absoluta. Si queremos ver el link tenemos que recordar que la variable está en ruby, así que tenemos que imprimirla en la vista ocupando la zanahoria <%=

1

<%= pages_about_path %>

Otra forma de hacer lo mismo es ocupando el helper link_to de la siguiente forma:

1

link_to "abouts", pages_about_path

El helper se transformará en un

apuntando a la página respectiva.

y dentro de la vista de abouts_us podemos agregar un link a la página principal de la siguiente forma:

1

link_to "home", index_about_path

Preguntas 1. ¿Si tenemos un error del tipo el método no existe, donde está el problema?

2. ¿Si tenemos un error del tipo el template falta, donde está el error? 3. ¿Si tenemos un error del tipo la ruta no existe, donde está el error? 4. ¿Qué quiere decir agregar una acción?, en qué archivo va? 5. ¿Para qué sirve el formato .erb? 6. ¿Cuál es la diferencia en <%= %> <% %>? 7. ¿Qué tipo de navegador se necesita para ver un proyecto con ruby on rails? 8. ¿Cuántas páginas puede tener un controller? 9. ¿Qué comando muestra todas las rutas que existen en rails? 10. ¿Cómo se crea un controller con tres páginas? 11. ¿Cómo se destruye un controller? 12. ¿Cuál es la diferencia entre pages_index_path y pages_index_url? 13. ¿Qué hace el método link_to?

6) Agregando imágenes a nuestra primera página Objetivos 1. Aprender a incorporar imágenes a un sitio web 2. Introducir el concepto de asset path

Los Assets Los assets son todas las imágenes, sonidos, tipografías, películas, hojas de estilos y archivos javascript que insertemos en nuestra página web. En rails los assets se deberían encontrar divididos en dos carpetas principales, la primera está dentro de app/assets y la segunda dentro de vendor/assets. La primera sirve para nuestros assets, la segunda para las librerías de terceros, o sea lo que descarguemos de internet.

El asset path Cuando uno está empezando a programar en Rails el asset path es la primera gran pesadilla, por no saberlo manejar bien uno puede demorar horas en simplemente cargar una imagen o un CSS, por lo mismo vamos a estudiarlo para evitar conflictos futuros. ¿Qué es el asset path? El asset path es una lista de todos los directorios donde se encuentran los assets, cuando queremos cargar una imagen o cualquier tipo de assets simplemente le decimos a rails que lo busque dentro del asset_path

Incorporando imágenes En una página web normal podemos ingresar imágenes de ruta relativa (dentro de nuestro computador) simplemente usando el tag:

Pero esto no lo podemos hacer en rails, bueno realmente podemos hacer algo como:

Pero, siempre y cuando tengamos una imagen dentro de la carpeta /assets/images/ y funcionará sólo en el entorno local y fallará cuando queramos correr nuestra aplicación en un servidor, por lo mismo no lo debemos hacer. La forma correcta de incluir imágenes en rails es ocupando los métodos image_tag y asset_path

El método asset_path El método asset_path sirve para todos los tipos de assets así que partiremos explicando este. Para utilizar asset_path, el cuál es un método de rails, tenemos que utilizar el formato erb, o sea incorporar la zanahoria <%= %> dentro del tag de HTML o sea quedaría así:

Hay que tener cuidado con un par de cosas, primero, la imagen si tiene que existir dentro de la carpeta /app/assets/images/, pero además debemos tener mucho cuidado con la sintaxis de asset_path, la zanahoria (<%= %>), esta debe estar pegada a la primera comilla y el cierre de la zanahoria debe estar pegada a la segunda, esto para evitar dejar espacios vacíos en el nombre del archivo que no forman parte del nombre.

El método image_tag Hay una forma más breve de incluir imágenes, pero no aplica a los otros assets, y esta es ocupando el método image_tag. Para incorporar la misma foto que incorporamos previamente sería con: <%= image_tag 'imagen-prueba.png' %>

image_tag además puede recibir otros parámetros como el id o la clase. <%= image_tag 'imagen-prueba.png', class:"img", id:"img-1"%>

Una ventaja de ocupar image_tag es que automáticamente genera un atributo alt utilizando el nombre del archivo. Obviamente que para que cualquiera de estas soluciones funcione tenemos que estar ocupando la extensión erb, o sea nuestro archivo debe ser .html.erb (por defecto en ruby)

7) Nuestra primera página con layout. Objetivos 1. Aprender a utilizar la página maestra 2. Profundizar en el concepto de asset path 3. Descubrir como manejar diversos CSS y javascript en una aplicación rails 4. Entender el proceso de precompilación de assets 5. Aprender a reutilizar código con las vistas parciales 6. Saber cambiar el layout de los controllers y métodos

El Layout Si observamos detenidamente las vistas nos daremos cuenta que no están completas, no tienen la estructura típica de un documento HTML, y es así, ¿de adonde sale el título de la página? Dentro de la carpeta views existe una subcarpeta llamada layouts, estas son las páginas maestras, podemos tener varias pero por defecto es una sola y esta se llama application.html.erb Y si modificamos el layout modificaremos todas las otras vistas simultaneamente, probemos que esto sea cierto. Al abrir el layout veremos lo siguiente:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Basic <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true %> <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %> <%= csrf_meta_tags %> <%= yield %>

Esta es la página maestra y en ella podemos definir el contenido y estilo que queramos compartir a lo

largo de todas las páginas de nuestra aplicación. Para probar que así sea cierto vamos agregar el siguiente texto antes de la instrucción yield

1 2

HOLA !!! Modificando el layout

y luego si abrimos las páginas veremos que en ambas dice el texto

Entonces como cambiamos el estilo de nuestro sitio?, para eso tenemos que agregar CSS

Incorporando CSS Los archivos CSS son fáciles de incorporar, simplemente debes colocarlo dentro de la carpeta apps/assets/stylesheets, todos los archivos de ahí se cargaran en cada página gracias a que dentro de nuestro layout viene incorporada la siguiente línea.

1 2

<%= stylesheet_link_tag 'application', media: 'all', 'dataturbolinks-track' => true %>

Esa línea lo que hace es cargar el archivo app/assets/stylesheets/application.css el cuál además de un par de comentarios contiene:

1 2 3 4

* *= require_tree . *= require_self */

En primer lugar hay que aclarar que estas líneas están comentadas al estilo CSS para evitar que la página web las cargue, puesto que require no es un instrucción de CSS válida, pero en este archivo si puede haber CSS.

Cabe destacar que este archivo recibe el nombre de manifiesto, y cada una de las líneas require dentro recibe el nombre de directivas.

Lo siguiente que vemos es require_tree, esta es la línea responsable de cargar recursivamente, tanto directorios como subdirectorios, todos los CSS dentro de esta carpeta. En este archivo el orden de carga importa y si fuera necesario establecer un orden de carga este se puede especificar en este mismo archivo a través de la instrucción require y nombrando los css, por ejemplo:

1 2 3 4 5 6 7

/* *= *= *= *= *= */

…

require reset require layout require chrome require_tree . require_self

Mientras que require_self carga el CSS (si es que hay) contenido dentro del archivo application.css en la posición mencionada, en el ejemplo, primero se cargaría el archivo reset, luego layout y luego chrome y finalmente todo el resto, si hubiese CSS dentro de este archivo application.css quedaría al final. Para probarlo vamos a definir un CSS sencillo, al que vamos a llamar style.css, y tiene que estar dentro de la carpeta app/assets/css

1 2 3 4 5 6 7

body{ background-color:#ddd; font-color:#333; width:80%; margin:20px auto; font-family: 'helvetica'; }

Si ahora cargamos nuestra página veremos que el fondo es gris, los márgenes y que la tipografía cargó.

La librería encargada de procesar estas directivas y convertir todos los CSS (y otros assets) en único archivo recibe el nombre de Sprockets

Incorporando Javascript Con respecto a este punto no nos extenderemos puesto que funciona exactamente igual que los CSS, la diferencia es que la línea que carga todos los js dentro del layout es:

1

<%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>

El archivo cargado por defecto es app/assets/javascript/application.js misma forma que application.css. Dentro del archivo se encuentra lo siguiente:

1 2 3 4

//= //= //= //=

y funciona de la

require jquery require jquery_ujs require turbolinks require_tree .

O sea rails incluye la librería de jQuery, y además, incluye la librería jquery_ujs que sirve para trabajar con javascript no intrusivo, además incluye turbolinks del cual hablaremos más adelante.

Incorporando imágenes (u otros assets) dentro del CSS y del JS Los assets incorporados dentro de los archivos CSS están sujetos a las mismas condiciones que los que ya hemos visto, pero para poder ocupar el método asset_path dentro de estos necesitamos que estos archivos además contengan la extensión .erb. O sea por ejemplo si tenemos un archivo style.css el cual pone una imagen como background de fondo, entonces debemos nombrarlo style.css.erb y luego dentro de la url(fondo1.png) cambiarlo por

1

url('<%= asset_path fondo1.png %>')

Es muy importante que nos fijemos bien en la sintaxis de nuestro archivo CSS. Si bien CSS es tolerante a fallos debido al principio de graceful degradation, la precompilación de archivos CSS no es tan tolerante y un punto y coma sobrante causara problemas a la hora de enviar nuestro proyecto a producción.

¿Qué es la precompilación de assets? La precompilación de assets es un proceso por el cual los assets son preparados para producción. 1. Preprocesadores Transforma los lenguajes a su forma compartible, por ejemplo los archivos co !escript se convierten en javascript, los archivos SASS se convierte en CSS. 2. Concatenados

Todos los CSS se juntan en un CSS final, t odos los JS se juntan en un JS final, esto reduce el número de requests hechos al servidor traduciéndose en una página más rápida

3. Minificados Tanto al CSS final como al JS final se le remueven todos los caracteres innecesarios, como por ejemplo los saltos de líneas y los espacios, eso se traduce en archivos de menor peso y por lo mismo páginas más rápidas. 4. Fingerprint Consiste en agregar una secuencia de números para convertir el nombre de un asset en un nombre único y realizar de forma más sencilla el caching de los assets.

El entorno En ruby on rails existen distintos entornos de funcionamiento, por defecto son tres, desarrollo, testing y producción. En algunas ocasiones es útil agregar un 4º llamado staging. La razón por la que existen diversos entornos es porque tienen distintos funcionamientos, cuando trabajamos en nuestro computador quremos ver los errores con el mayor detalle posible, pero cuando nuestra aplicación está online y la está ocupando una persona externa y sucede algún error queremos estar seguros de que no expondremos una falla de seguridad de nuestro sistema y por lo mismo en rails se enconden los errores en modo de producción. El modo testing sirve para correr pruebas, lo ocuparemos más adelante en este libro. El modo staging se agrega cuando se quiere un paso previo a producción (a veces con clientes reales, o a veces solo homologando el ambiente para prueba) y prevenir errores inesperados al dar el paso a producción.

Cuando uno trabaja en el entorno de desarrollo no se realizan todos los procesos de precompilación de assets, sólo se realiza el preprocesado para poder utilizar sass y co!eescript, el resto de los procesos sólo se procesan cuando pasamos al entorno de producción o si modificamos nuestro entorno de desarrollo para que lo haga.

Los archivos donde se especifica esta configuración se encuentran en config/enviromments, estos archivos también permiten modificar otros comportamientos como por ejemplo si se deben mostrar los errores. Podemos correr rails en modo de producción dentro de nuestro computador cargado el server con el parámetro -e production

1

rails s -e production

Pero esto nos generará conflictos ya que todavía no tenemos configurado algunos archivos, así que el intentar cargar la página obtendremos el siguiente error.

Missing `secret_token` and `secret_key_base` for 'production' environment, set the se values in `config/secrets.yml`

En los capítulo de heroku tanto como en los últimos capítulos de este libro hablaremos con más detalle del paso a producción.

La carpeta assets de vendor Rails trae tres carpetas de assets incluídas en el asset_path, hasta el momento sólo hemos mencionado la que se encuentra dentro de app, pero dentro de la carpeta vendor y dentro de la carpeta lib también es posible agregar assets. La idea es que la carpeta app/assets contenga los assets específicos del proyecto, la carpeta vendor contenga los assets de librerías de terceros, como por ejemplo los de bootstrap, y finalmente la carpeta lib para otros casos.

Cuando colocamos los assets en otras carpetas el require_tree no es suficiente para cargarlos, ya que este tree se refiere al de app/assets/stylesheets, entonces además tenemos que mencionarlos dentro del archivo, veremos un caso específico de esto en el ejemplo de bootstrap.

Agregando una carpeta nueva al asset_path Es posible agregar nuevas carpetas al asset_path ocupando el archivo /config/initializers/assets.rb

1

Rails.application.config.assets.paths << Rails.root.join('mis_assets', 'assets')

También para hacer más fácil las referencias puedes agregar subcarpetas

1 2

Rails.application.config.assets.paths << Rails.root.join('mis_assets', 'assets', Rails.application.config.assets.paths << Rails.root.join('mis_assets', 'assets',

Verificando el asset_path Rails tiene una consola que nos permite verificar este tipo de configuraciones, para entrar a ella dentro de la carpeta del proyecto tenemos que escribir rails c o rails console y luego podemos verificar nuestros assets con:

1

Rails.application.assets

Esto nos devolverá una lista con todas las carpetas que se encuentra dentro del asset_path Si realizamos un cambio dentro del archivo de configuración es necesario salir de la consola y volver a entrar para poder ver los cambios.

Incorporando tipografías locales Para incorporar tipografías todavía nos falta aprender una cosa más, a manipular que archivos y que carpetas son parte del asset_path, para esto vamos a modificar el archivo /config/initializers/assets.rb y dentro de la clase vamos a agregar lo siguiente:

1 2

Rails.application.config.assets.paths << Rails.root.join('app', 'assets', 'fonts' Rails.application.config.assets.precompile += %w( *.svg *.eot *.woff)

Finalmente cuando se modifica el archivo application.rb o cualquier initializers debemos reiniciar el servidor, y con eso ya deberíamos tener acceso a nuestras tipografías.

Consecuencias de Sprockets Al unirse todos los CSS y cargarse en cada página podemos tener consecuencias indeseadas, especialmente cuando tenemos plantillas que cargan diversos archivos CSS en cada páginas. Para enfrentar este problema hay dos posibles soluciones, la primera consiste en darle un namespace a la página, la segunda en utilizar un layout distinto, ahora abordaremos la solución del namespace y más adelante en este capítulo estudiaremos como incorporar diversos layouts. Para dar un namespace a la página lo que debe hacerse es ocupar el hash params dentro de la vista, este hash contiene información general que se realiza en cada request, una información importante que tiene es el nombre del controller y del método llamado, estos se guardan bajo las claves de controller y action y los podemos ocupar en las vistas, en el layout y en el controller.

1

params[:controller]

Utilizando el hash params podemos generar un namepsace a cada vista, simplemente agregado ese dato a la clase body dentro del layout.

1 2 3 4 5 6 7 8 9 10 11 12 13

Namespace Trick :) <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %> <%= csrf_meta_tags %> <%= yield %>

De esta forma si cargamos alguna página dentro del controller pages, obtendremos

Podemos hacerlo aún más específico utilizando

1 2 3

<%= yield %>

En ese caso si cargamos el método landing dentro de pages obtendremos

Queda un paso que en teoría es sencillo, ahora cada CSS que sea específico a una grupo de página debe tener junto a cada marca un .nombre-controller y cada CSS específico a una sóla página debe contener un .nombre-controller .nombre-acción

Incorporando bootstrap. Hay varias formas de incorporar bootstrap, la primera y más sencilla es ocupar el CDN.

CDN El CDN consiste en 2 CSS, uno el base, y el otro el tema junto con los JS para alguna de las funcionalidades.

Estos debemos copiarlos dentro de nuesta página maestra en views/layouts/application.html.erb

1 2 3 4 5 6 7 8

Pero para copiarlo bien tenemos que tener en cuenta la carga de nuestros CSS, los CSS de bootstrap debemos cargarlo antes de nuestros CSS para poder modificarlo (o si no bootstrap rescribirá nuestros cambios) y los JS debemos cargarlo después de la instrucción javascript_include_tag pues esta instrucción es la que carga jQuery en nuestro sitio y los JS de boostrap depende de jQuery. Entonces nuestro layout con bootstrap quedaría así:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Basic2 <%= yield %>

Descargando los CSS Es posible descargar los CSS de boostrap dentro de la carpeta vendor/assets, tenemos que tener cuidado de pones los CSS dentro de la carpeta CSS y los JS dentro de la carpeta JS, funciona si los

cruzamos pero la idea es mantener todo ordenado, y si creamos una carpeta nueva tenemos que agregarla al asset_path Entonces primero descargamos los archivos de la página oficial: https://github.com/twbs/bootstrap/releases/download/v3.3.5/bootstrap-3.3.5-dist.zip Copiaremos los archivos CSS en lugar de los .min puesto que rails tiene la capacidad de minificarlos, o sea los archivos bootstrap.css y bootstrap-theme.css van en vendor/assets/stylesheets, luego copiamos el archivo bootstrap.js en vendor/assets/javascript El último paso que nos queda es mencionar dentro del application.css los archivos bootstrap, puesto como habíamos explicado previamente la línea require_tree dentro de app/assets/stylesheets/application.css sólo carga el tree de stylesheets, por lo que debemos hacer el require de forma explícita.

1 2 3 4

*= *= *= *=

require bootstrap require bootstrap-theme require_tree . require_self

De la misma forma debemos hacerlo dentro de app/assets/javascript/application.js Este debería quedar:

1 2 3 4 5

//= //= //= //= //=

require jquery require jquery_ujs require turbolinks require bootstrap require_tree .

Glyphicons Este tema puede ser un poco más complejo porque en primer lugar hay que agregar la carpeta fonts dentro de vendors/assets y copiar los archivos ahí, luego hay que agregar la carpeta fonts al asset_path en el archivo config/initializers/assets.rb

1

Rails.application.config.assets.paths << Rails.root.join('vendor', 'assets', 'fo

En el mismo archivo hay que agregar los nuevos formatos al proceso de precompilación

1 2

Rails.application.config.assets.paths << Rails.root.join('vendor', 'assets', 'fo Rails.application.config.assets.precompile += %w( *.svg *.eot *.woff *.ttf *.wof

y hay que reiniciar el servidor. Pero además tenemos que revisar el archivo css de boostrap y cambiar las referencias desde donde se cargan los fonts, puesto hay que ocupar el asset_path en vez de las rutas que utiliza. Para eso con ctrl+f dentro del archivo podemos buscar el nombre de los fonts, en este caso glyphiconshalflings, y buscar donde se cargan, debería aparecer con url() cerca de la línea 266 encontraremos:

1 2 3 4

src: url('../fonts/glyphicons-halflings-regular.eot'); src: url('../fonts/glyphicons-halflings-regular.eot?#iefix') format('embeddedurl('../fonts/glyphicons-halflings-regular.woff2') format('woff2'), url('../fonts/glyphicons-halflings-regular.woff') format('woff'), url('../font

Ahí es donde tenemos que eliminar el ../fonts y luego envolverlo ocupando <%= asset_path "nombrefuente" %> Debería quedar así:

1 2 3 4 5 6

src: url('<%= asset_path "glyphicons-halflings-regular.eot" %>'); src: url('<%= asset_path "glyphicons-halflings-regular.eot?#iefix" %>') format url('<%= asset_path "glyphicons-halflings-regular.woff2" %>') format('woff2'), url('<%= asset_path "glyphicons-halflings-regular.woff" %>') format('woff'), url('<%= asset_path "glyphicons-halflings-regular.ttf" %>') format('truetype'), url('<%= asset_path "glyphicons-halflings-regular.svg#glyphicons_halflingsregu

Para probar que funcionó podemos agregar un glyphicon a nuestra vista.

1

hola

Vistas parciales Una vista parcial es una parte de un archivo HTML que simplemente se pone en otro archivo. La vistas parciales se caracterizan son archivos .html.erb pero tienen una carecterística especial, empiezan con el prefijo _ y esto ayuda a los programadores a distinguir que vistas no están completas, o sea son parciales y son para ser insertadas en otros archivos.

Para cargar una vista parcial sólo tenemos que especificar el nombre de un archivo HTML que empieze con el prefijo _

1

<%= render 'layouts/navbar' %>

Las vistas parciales sirven mucho en dos casos, desacoplar y mantener ordenadas las vistas y para evitar repetir código, el primer caso lo estudiaremos en este capítulo, el segundo lo veremos más adelante.

Cargando el navbar de bootstrap como una vista parcial Si queremos desacoplar una vista, o sea por ejemplo si queremos copiar la barra de navegación de bootstrap que consisten en más de 40 líneas de código HTML es mejor copiarlas dentro de una vista parcial y de esa forma no ensuciar el layout, debemos crear un archivo dentro de app/views/layouts que llamaremos _navbar.html.erb , dentro de el copiaremos la barra de bootstrap que aparece en la página.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Brand

"> Efrain (current)

">Gonzalo

Submit

Link

Action

Another action

Something else here

Separated link

y finalmente dentro del layout antes del yield escribiremos <%= render ‘layouts/navbar’ %>

Cargando un layout distinto Cada controller se encarga de cargar el layout, si no se específica uno se carga el layout por defecto, el cuál es application.html.erb Dentro del método correspondiente podemos especificar que layout o cargar, o si no queremos ningún layout también podemos hacerlo

1 2 3

def index render layout: false end

Podemos hacer lo mismo a nivel de controller para todos los métodos internos

1 2 3 4 5 6 7 8

class PagesController < ApplicationController layout false def index end def about end end

Para mostrar un layout distinto es la misma idea, supongamos que queremos hacer un layout distinto para las landings page: A nivel de acción:

1 2 3

def index render 'landings' end

A nivel de controller:

1 2 3 4 5 6 7 8

class PagesController < ApplicationController layout "landing" def index end def about end end

El layout puede tener la estructura que quieras, pero debes recordar el yield o no podras ver el contenido de la vista específica.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Layout Distinto <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %> <%= csrf_meta_tags %> hola <%= yield %>

Desafío Cargar una plantilla de HTML dentro de rails.

Preguntas 1. ¿Para qué sirve el layout? 2. ¿Qué es el asset_path? 3. ¿Qué hace la línea require\_tree? 4. ¿Cómo se puede especificar el orden de carga de un CSS? 5. ¿Cómo se puede cargar una imágen u otro asset dentro de un CSS? 6. ¿Cómo se puede agregar una nueva carpeta al asset path? 7. ¿Para qué sirven los assets dentro de la carpeta vendor? 8. ¿Para qué sirve la línea require_tree dentro del manifiesto? 9. ¿En qué línea del layout se carga jQuery? 10. ¿Por qué los CSS de bootstrap hay que cargarlos antes de stylesheet\_link\_tag? 11. ¿Para qué sirve el rails console? 12. ¿Qué son los vistas parciales?

13. ¿Qué características tienen los archivos que son vistas parciales? 14. ¿Cómo se puede cargar una vista parcial? 15. ¿En qué consiste el proceso de minificado?

8) Creando un formulario de registro Objetivos 1. Introducir el concepto de modelo 2. Aprender a crear un formulario básico

En el capítulo anterior vimos las componentes de vistas y controles de rails, en este capítulo abordaremos la introducción a modelos creando nuestro primer formulario. Para repasar vamos a empezar desde cero. 1) Creamos el proyecto

1

rails new primer_form

2) Cargamos el CDN de bootstrap en el layout.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Basic2

<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-tra <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %> <%= csrf_meta_tags %>

<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.mi integrity="sha512-K1qjQ+NcF2TYO/eI3M6v8EiNYZfA95pQumfvcVrTHtwQVDG+aHRqLi/ETn

<%= yield %>

3) Creamos el controller landing con la págian index

1

rails g controller landing index

El tag form En Ruby on Rails al igual que en HTML podemos agregar formularios utilizando los tags de forms. Para probarlo construiremos un formulario simple dentro del index de la aplicación que ya tenemos definida.

1 2 3 4

Después de guardar, dentro de la página web deberíamos ver un input, y si lo llenamos veremos que por defecto nos redirige a la misma página, pero esta cambiará ligeramente, pues al final de la url aparecerá ?q=hola donde q es el nombre del input y el igual el valor que fue pasado.

Revisando los parámetros enviados Todos los parámetros en rails se pásan a través de un hash llamado params, dentro de la vista podemos mostrar el contenido de este hash con:

1

<%= params %>

Veremos:

Es rails los hash tienen un pequeña diferencia con los de ruby, en estos los accesos con string o con símbolos son exactamente iguales, o sea podemos obtener el valor de q usando params[:q] o params["q"] Entonces si queremos mostrar sólo el valor del email enviado lo podemos hacer con <%=params[:q]%> Ahora sacaremos <%=params%> de la vista por que no tiene sentido mostrar los párametros al usuario.

Guardando los datos Ahora tenemos que lidiar con la base de datos, puesto que para guardar los datos la necesitamos, ruby on rails viene por defecto funcionando con SQLite3 y para este proyecto será suficiente. Para crear una tabla de datos y guardar los usuarios necesitamos crear un modelo, en el patrón MVC cada modelo mapea los datos a su tabla de la base de datos, o sea si creamos el modelo llamado usuario, se creará una tabla en la base de dato llamada usuarios y el modelo nos ayudará a guardar los datos sin tener que usar comandos SQL.

Se recomienda escribir el código en inglés, el inflector de Rails viene configurado por defecto en inglés y por lo tanto puede haber un error en el nombramiento de las tablas al intenta pluralizar bajo las reglas del español

Creando el primer modelo Ppdemos crear el modelo de usuarios desde la terminal con un generador.

1

rails g model user email

Donde user es el nombre del modelo y email un campo que tendrá la tabla. A diferencia de los controllers la convención es nombrar los módelos en singular, puesta esta clase mapea a un elemento (por ejemplo un usuario) con sus datos en la tabla de la base de datos. Al correr el generador obtendremos:

invoke

active_record

create

db/migrate/20151120195902_create_users.rb

create

app/models/user.rb

invoke

test_unit

create

test/models/user_test.rb

create

test/fixtures/users.yml

O sea se genera el modelo User, una migración para crear la tabla users en la base de datos y tests.

Corriendo las migraciones

En rails para modificar la base de datos hay que utlizar una migración, estas son una secuencia de instrucciones que llevan la base de datos de un estado a otro, las migraciones son un tema complejo que abordaremos profundemente en el libro, pero por ahora sólo necesitamos saber como correrlas, para eso vamos a utilizar el comando:

1

rake db:migrate

Obtendremos como resultado:

== 20151120195902 CreateUsers: migrating ====================================== -- create_table(:users) -> 0.0037s == 20151120195902 CreateUsers: migrated (0.0039s) =============================

Después de correr la migración el siguiente paso es probar el modelo.

Rails console Cuando uno crea un modelo lo primero que hacemos es probarlo en la consola de rails, podemos acceder a ella utilizando rails console o rails c , desde consola de Rails donde podemos procesar e insertas datos a la base de datos.

Creando un usuario Cuando uno crea un modelo lo que se crea es una clase con ese nombre, o sea dentro de rails nosotros ahora podemos instanciar un objeto user con:

1

user = User.new

O lo podemos instanciar directamente con un email

1 2

user = User.new(email: '[email protected]') => #
También podemos cambiar el email del usuario simplemente con:

1

user.email = "[email protected]"

Estos datos no persisten en la base de dat os hasta que los guardemos, eso lo podemos hacer con:

1

user.save

Si todo se realizó correctamente obtendremos:

#

(0.6ms)

begin transaction

SQL (1.1ms) , ?, ?)

INSERT INTO "users" ("email", "created_at", "updated_at") VALUES (?

[["email", "[email protected]"], ["created_at", "2015-11-20 20:26:

21.576528"], ["updated_at", "2015-11-20 20:26:21.576528"]] (0.8ms)

commit transaction

=> true

Y ahora ya tenemos datos en nuestra base de datos. También podemos guardar un usuario directamente en la base de datos sin instanciarlo, eso lo podemos hacer con el método .create

1

User.create(email: "[email protected]")

Leyendo los usuarios desde la base de datos Para ver todos los usuarios creados lo podemos hacer con:

1

User.all

Esto gatillará una consulta SQL y nos devolverá un array especial llamado ActiveRecord::Relation pero el cuál a fin de cuentas es un array.

User Load (0.3ms)

SELECT "users".* FROM "users"

=> #, #]>

Como los resultados son una array podemos iterarlo con un .each

1

User.all.each {|u| puts u}

Obtendremos:

1 2 3 4

User Load (0.2ms) SELECT "users".* FROM "users" # # [#
El array al final se obtiene porque el método .each al terminar de iterar devuelve el arreglo original. Para salir de rails console tenemos que escribir

1

exit

Guardando los usuarios dentro de rails Ahora que sabemos lo básico del ActiveRecord podemos guardar el usuario cuando se envíe un formulario. Para eso tenemos que ir al controller de landings, y detectar si se enviaron parámetros en el formulario, si se hizo los guardamos en la base de datos.

1 2 3 4 5 6 7

class LandingsController < ApplicationController def index unless params[:q].blank? User.create(email: params[:q]) end end end

El método .blank? revisa si el parámetro q es nulo o vacío, o sea si hay un valor en el formulario que sea distinto de nulo o vacío guardaremos al usuario con su email en la base de datos.

Cuando se trabaja en la parte de datos, el servidor de rails (rails s) siempre tiene datos útiles, para ver si funcionó podemos revisarlo y veremos:

Started GET "/landings/index?q=gonzalo%40desafiolatam.com" for ::1 at 2015-11-20 14:45:46 -0600 Processing by LandingsController#index as HTML Parameters: {"q"=>"[email protected]"} (0.5ms)

begin transaction

SQL (0.7ms) , ?, ?)

INSERT INTO "users" ("email", "created_at", "updated_at") VALUES (?

[["email", "[email protected]"], ["created_at", "2015-11-20 20:45:

46.740908"], ["updated_at", "2015-11-20 20:45:46.740908"]] (0.6ms)

commit transaction

Rendered landings/index.html.erb within layouts/application (0.8ms) Completed 200 OK in 139ms (Views: 98.5ms | ActiveRecord: 1.9ms)

O sea nos dice que se llamó a la página con el párametro q="gonzalo%40desafiolatam.com luego se insertó en la base de datos, lo que implica que está todo OK. En estos logs debemos tener especial cuidado cuando después de la inserción aparesca rollback transaction en lugar de commit transaction, eso es un indicador de que la operación falló.

Cambiando la página de inicio Es posible convertir a cualquier página en la página de inicio, para eso hay que abrir el archivo config/routes.rb y agregar la línea root 'controller#action' en nuestro caso sería

1

root 'landings#index'

Luego podemos verificar que haya funcionando accediendo con nuestro navegador a localhost:3000' También podemos obeservar que al hacer rake routes aparacerá este cambio:

landings_index GET root GET

/landings/index(.:format)

landings#index

/

landings#index

Desafío Crear un formulario funcional en la plantilla que creamos en el capítulo anterior

y

Preguntas 1. ¿Cuál es la función del modelos en el patrón MVC de ruby on rails? 2. ¿Que contiene el hash params? 3. ¿Cuál es la relación entre el modelo y una tabla en la base de datos? 4. ¿Qué son las migraciones? 5. ¿Cómo corremos una migración? 6. ¿Cómo podemos probar que una migración haya sido exitosa? 7. ¿Cómo instanciamos un usuario nuevo? 8. ¿Cómo instanciamos un usuario que tenga email? 9. ¿Cómo guardamos un usuario con su email en la base de datos? 10. ¿Cómo podemos guardar un usuario sin instanciarlo? 11. ¿Cómo podemos ver todos los usuarios creados? 12. ¿Cómo podemos mostrar todos los usuarios que hay en la base de datos? 13. ¿Cómo podemos entrar a la consola de rails? 14. ¿Cómo podemos salir de la consola de rails? 15. ¿Qué hace el método .blank? 16. ¿Qué implica que aparezca rollback transaction en los logs? 17. ¿Cómo podemos cambiar la página de inicio en rails?

9) Formulario 2.0 Objetivos 1. Introducir el concepto de post 2. Introducir el concepto de MVC

Creando un proyecto nuevo Antes de trabajar en este proyecto vamos a hacer una copia del anterior, (si tienes experiencia con GIT puedes hacer un branch), para eso del terminal en una carpeta anterior a la del proyecto podemos hacer:

1

cp -r nombre_proyecto1 nombre_proyecto2

Donde nombre_proyecto1 es el nombre original del proyecto y nombre_proyecto2 es el nuevo. Una vez dentro nos daremos cuenta si entramos a rails console ` que tenemos los mismos datos, o sea copiaron los usuarios creados en el proyecto anterior, pero eso no se debe a que ambos utilizen las misma base de datos, se debe a que sqlite3 es un archivo que está dentro de la carpeta db y nostoros copiamos, por lo tanto nos trajimos todos los cambios. Podemos probar que estos es así agregando datos en uno solo de los proyectos y luego revisando en el otro, veremos que sólo están en uno, esto no ocurrirá posteriormente cuando trabajemos con PostgreSQL u otro motor de base de datos. Otro cuidado que tenemos que tener es que no podemos tener corriendo dos servidores de rails en el mismo puerto, y como el puerto por defecto es el 3000, debemos bajar el servidor de rails del proyecto anterior con ctrl+c antes de abrir el nuevo. Y obviamente debemos abrir la carpeta correcta en el editor, entonces antes de seguir: ¿Copiaste los archivos a la carpeta nueva? ¿Cerraste el proyecto en el editor, y abriste el nuevo? ¿Bajaste el servidor del proyecto anterior y abriste el nuevo?

Enviando un formulario por POST

Los formularios pueden ser enviados por diversos métodos, los más comunes son GET y POST Cuando se envía un formulario por GET los campos aparecen en la URL, esto es muy útil si se quiere mostrar y poder compartir los resutados, por ejemplo si buscamos algo en google y queremos compartir los resultados de la búsqueda lo podemos hacer copiando la url y envíandosela a alguien, pero cuando se quiere enviar información sensible y no dejar un registro de eso en la URL hay que ocupar el método POST Para enviar un formulario por post tenemos que indicar en el método que es POST.

1 2 3 4

Si ahora probamos el formulario veremos un error que ya hemos visto anteriormente.

No route matches [POST] "/landings/index"

Hacer un match a un ruta requiere tanto de la url como el método, no es lo mismo hacer un get a una página que un post, para probarlo podemos hacer rake routes

Prefix Verb URI Pattern landings_index GET root GET

Controller#Action

/landings/index(.:format) landings#index /

landings#index

Sólo tenemos un acceso GET a /landings/index y ningún acceso post. Para crear una ruta nueva vamos abrir el archivo de rutas en

config/routes.rb

MVC in a nutshell Pero … ¿Por qué necesitamos una URL nueva?, si antes funcionaba con una sola. El concepto para entender bien MVC es que una URL es una acción y una acción nueva requiere una URL nueva, o sea para agregar procesamiento al formulario tenemos que agregar una ruta nueva, esa URL nos llevará a un controller y un método específico y ahí manejaremos la lógica del formulario. Si bien un if dentro del controller nos permitiría manejar múltiples acciones debemos recordar siempre el concepto KISS (Keep it simple and stupid) entonces en lugar de manejar la opción de que si el parámetro viene hacer tal cosas, mejor simplemente separar ambas acciones, una para mostrar el formulario y una para procesarlo.

Existe otra ventaja en este caso específico, si tuviesemos varios landings distintos probablemente no haya ninguna razón para manejar estos formularios de registro de forma distinta, de esta forma al tener acciones separadas evitamos reescribir código. La ruta nueva puede ser por POST o por GET, la diferencia es que por GET los parámetros se envían a través de la URL, en cambio POST se pasa en los headers del request, esto lo estudiaremos con más profundidad en el capítulo de negociación de contenido. Ahora agregaremos la ruta al método nuevo dentro del archivo routes.

1

post 'pages/receive'

Para confirmar que la ruta fue agregada correctamente correremos el comando rake routes en la consola, como resultado deberíamos obtener:

Prefix Verb URI Pattern landings_index GET

Controller#Action

/landings/index(.:format)

landings#index

landings_receive POST /landings/receive(.:format) landings#receive root GET

/

landings#index

La ruta nueva no la podemos probar en el navegador ya que eso sería acceder por GET, pero podemos probarla utilizando el formulario, para eso vamos a necesitar el prefix. Ya habíamos comentado que podemos referirnos a cualquier página de rails ocupando el prefix + _path o prefix + _url el primero es una ruta relativa y para que en un formulario podamos dirigir a una página distinta tenemos que ocupar el atributo action

Form y action 1 2 3 4 5

Email

El método form_tag Otra forma de hacer exactamente lo mismo es ocupando el método form_tag de ruby, no es mucho el código que se ahorra en los casos sencillos, pero no está de sobra saberlo.

1 2 3 4

<%= form_tag landings_receive_path, method: :post, class: 'form' %> <%= label_tag "email", "Email" %> <%= email_field_tag "email" %> <%= submit_tag "Subscribirse" %>

Si ahora intentanmos probar el formulario, obtendremos el siguiente error:

Unknown action The action 'receive' could not be found for LandingsController

La razón de este error es porque todavía no hemos creado el método de receive, es lo que haremos a continuación. Para eso vamos a abrir el controller /app/controllers/landings_controller.rb en el editor de texto, dentro del archivo crearemos el nuevo método.

Mostrando los resultados del formulario 1 2 3 4 5 6 7 8 9

class PagesController < ApplicationController def index end def receive render json: params end end

Cada método muestra por defecto una vista del mismo nombre por ejemplo index carga la vista dentro de views/landings/index.html.erb pero hay una excepción. Si se utiliza la instrucción render o redirect_to, esto nos puede servir para cambiar el comportamiento y en este en lugar de mostrar una vista (o un error porque todavía no hemos creado la vista) nos ayudaría a mostrar los parámetros del formulario recibido.

1 2 3 4 5 6 7 8

{ }

utf8: "!", authenticity_token: "9WFUTrwJgKSCKIKA4lQPsHted6TRWmERCJTY65u+Ix94dFLxPdfY2Xz email: "[email protected]", commit: "Subscribirse", controller: "landings", action: "receive"

Guardando los resultados Si estamos enviando los datos de forma correcta el siguiente paso es guardarlo, ya tenemos el modelo creado, lo que tenemos que hacer es mover la lógica que teníamos en index a receive, quedaría así:

1 2 3 4 5 6 7 8 9 10 11

class LandingsController < ApplicationController def index end def receive User.create(email: params[:email]) render json: params end end

Se deben manejar los errores en caso de inserció esto lo estudiaremos en un capítulo futuro

Redirect_to En lugar de mostrar los resultados del formulario después de crearlo podríamos redirigir al landing (o a otra página al usuario y mostrarle que sus datos fueron guardados con éxito, para eso ocuparemos el método redirect_to, este recibe dos parámetros, el primero es la URL a la que hay que redirigir al usuario y el segundo permite enviar mensajes flash, los mensajes flashs son variables que viven durante un sólo request o sea son para mostrar a la próxima carga de página, ideal para avisos de lo lograste o tal cosa falló.

1 2 3 4 5 6 7 8 9 10

class PagesController < ApplicationController def index end def receive @user = User.new(email: params[:email]) @user.save redirect_to root_path, notice: "Te has registrado" end end

Variables flashs

Nos falta una mejora, siempre existe una posibilidad de que la operación de guardado pueda fallar, en este caso es muy difícil que suceda dada la simplicidad de la operación, pero siempre debemos manejar y reportar los casos de falla.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class PagesController < ApplicationController def index end def receive @user = User.new(email: params[:email]) if @user.save redirect_to root_path, notice: "Te has registrado" else redirect_to root_path, alert: "No hemos podido registrarte, inténtalo de nuevo" end end end

No basta con crear variables flashs, tenemos que mostrarlas, para eso dentro de la vista maestra, o sea layouts/application.html.erb mostraremos las variables flash.

Es una práctica común desde el punto de vista de usabilidad mostrar estas alertas bajo la barra de navegación. Mostrarlas arriba de la barra de navegación haría que se moviera y se vería raro, mostrarlas muy abajo haría que el usuario no las viera.

1 2 3 4 5

<% if flash[:notice] %>
<%= flash[:notice] %>
<% elsif flash[:alert] %>
<%= flash[:alert] %>
<% end %>

Mostrando todos los usuarios en la base de datos Para eso vamos crear una ruta nueva que nos permita rescatar todos los emails ingresados en la base de datos, la llamaremos get_leads, agregamos la ruta al archivo en config/routes.rb

1

get 'landings/get_leads'

Dentro del controller agregaremos el método get_leads y desde ahí obtendremos todos los leads.

1 2 3 4

def get_leads @users = User.all render json:@leads end

Podemos probar entrando a http://localhost:3000/landings/get_leads User.all devuelve todos las filas de la tabla leads dentro de un array (realmente no es una rray pero eso lo estudiaremos más adelante), este array lo vamos a guardar dentro de una variable de instancia, lo cual nos permitirá más adelante mostrar los resultados en una vista pero que por ahora nos limitaremos a mostrar como si fuera un archivo JSON. Ahora para terminar este proyecto haremos la vista de get_leads, para eso tenemos que crear dentro de app/views/pages el archivo get_leads.html.erb pero primero tenemos que decirle al controller que ocupe la vista y para eso removeremos el render.

1 2 3

def get_leads @users = User.all end

Para mostrar los resultados iteraremos todos los leads obtenidos (los users son un array) y por cada uno de ellos mostraremos el email.

1 2 3 4 5

<% @users.each do |u| %>
<%= u.email %>
<% end %>

Más adelante en este libro esstudiaremos el concepto de autenticación y control de accesos para dar acceso restringido a estas secciones exclusivamente a algunos usuarios.

Desafío Modificar el formulario de la plantilla que hicimos previamente para incorporar un formulario que funcione por posts, el usuario debe ser notificado cuando ingresó sus datos y se debe crear una página que permita verificar todos los usuarios ingresados.

Preguntas

1. ¿Cuál es la diferencia entre enviar datos por get o por post? 2. Complete la oración. ¿Una acción nueva requiere de una … 3. ¿Para que sirve el atributo action de los formularios? 4. ¿Cuál es la diferencia entre utilizar el form de HTML y la etiqueta form_tag de rails? 5. ¿Que hace redirect_to? 6. ¿Cuál es la diferencia entre redirect_to y render ? 7. ¿Qué hace render json: params? 8. ¿Qué son las variables flashs? 9. ¿Cuál es la diferencia entre utilizar <%= @users.each do |u| %> y <% @users.each do |u| %>?

10) El gemfile Objetivos 1. Aprender a instalar dependencias en un proyecto rails 2. Manejar las versiones de las dependencias ocupando el gemfile

El gemfile es un archivo que contiene todas las dependencias de un proyecto en Rails estas dependencias reciben el nombre de gemas, con este archivo especificamos que bibliotecas con sus respectivas versiones se deben instalar para poder correr el proyecto. Bundler es un programa que es capaz de leer este archivo e instalar todas las dependencias. para correr el correr el programa simplemente debemos ejecutar bundle .

Ni Bundler ni el gemfile son exclusivos de rrails, sirven para controlar dependencias de cualquier proyecto en ruby.

El gemfile de un proyecto en rails comienza así:

1 2 3 4 5 6

source 'https://rubygems.org' # Bundle edge Rails instead: gem 'rails', github: 'rails/rails' gem 'rails', '4.2.5' # Use sqlite3 as the database for Active Record gem 'sqlite3'

La primera línea especifica de donde deben ser buscadas las gemas, el resto de las gemas se especifca con las instrucción gem, luego el nombre de la gema y como parámetro opcional la versión. Al correr bundle se generará un archivo llamado gemfile.lock, este archivo contiene todas las gemas y dependencias (otras gemas) de un proyecto. Tanto el gemfile como gemfile.lock deben ser añadidos al repositorios pues permiten para otros instalar las mismas libererías de tu proyecto en rails con las versiones específcadas con una sola línea de comando. Podemos especificar una versión en el gemfile con un segundo parámetro.

1

gem 'rails', '3.0.0.beta3'

Se puede pedir que una gema sea mayor que una versión con:

1

gem 'rack',

'>=1.0'

Se puede pedir que la versión a instalar esté dentro de una versión menor de la gema, (o sea que el cambio sea sólo en el segundo decimal)

1

gem 'thin',

'~>1.1'

Preguntas 1. ¿Para qué sirve el Gemfile? 2. ¿Cuál es la diferencia entre el Gemfile y el Gemfile.lock? 3. ¿Qué hace el comando bundle? 4. ¿Qué significa que un cambio de versión sea menor?

Sección II Deployment con Heroku

11) Deployment en Heroku Objetivos 1. Conocer las diferentes alternativas que hay para hacer deployment de una aplicación 2. Instalar y configurar las herramientas necesarias para hacer deployment a Heroku 3. Aprender a hacer deployment en Heroku

Se le llama deployment al proceso de subir la aplicación en modo de producción (o sea lista para atender usuarios reales), mientras que mientras estamos trabajando en nuestros computadores se dice que la aplicación está en modo de desarrollo. Esto no es sólo un decir, rails puede detectar el ambiente que está y correr configuraciones dependiendo del ambiente, por ejemplo en producción podríamos tener funcionando google analytics, mientras que en desarrollo no. Además de estar en proudcción una aplicación requiere de dos cosas, un hosting y un dominio, no son lo mismo y no hay que confundirlos. El hosting es un computador donde la aplicación estará hosteada (subida y corriendo), el dominio es el nombre. Una pequeña aclaración, el dominio no es estrictamente necesario, si tiene un ip fija (cuando pagas por un hosting usualmente te dan una ip) puedes usar esa ip para entrar a la aplicación, sin embargo tus clientes o usuarios no van a recordar ese número, es necesario tener un dominio

Tipos de hosting Hay varias estrategias para subir una aplicación:

Servidor propio Requiere de gran infraestructura o de warehousing (llevar tu computador a un data center), ambas opciones son bastante caras, y a menos que dispongas de los recursos, o sea un requistio importante del cliente y esté dispuesto a pagar por eso se recomineda ignorar.

Hosting clásico Este es el típico hosting que uno arrienda y viene con Cpanel, por lo general son baratos, antes de arrendar uno de estos revisa bien los términos y condiciones y en especial que tengan un buen servicio de soporte y compatibilidad con Rails 4 (muchos no lo tienen) un hosting clásico puede costar desde 10 dólares al año, generalmente cuestan del orden de 20 dólares mensuales, dan poco ram, y además el setup que tienen no está optimizado para Rails, usualmente vienen con Apache y MySQL, pero NginX tiene mejor rendimiento en cuanto a usuarios / costo Rails trabaja igual de bien con MySQL que con PostgreSQL sin embargo en un hosting clásico estás limitado a eso al setup que trae, no puedes crear tu configuración propia

VPS En un VPS te arriendan una máquina virtual, hay de dos tipos arriendas un servidor normal (Linode, Digital Ocean, Etc) o un con escalamiento automático como Amazon. El pro de los VPS es que obtienes un muy buen precio y una buena máquina, además puedes realizar el setup que quieras. El problema con los VPS es que tienes que realizar el setup de forma manual y puede llegar a ser un buen trabajo.

PAAS Existen diversos sistemas PAAS el más famoso es Heroku, de Salesforce, existen otros como Engine Yard, estos sistema te permiten levantar rápido tu aplicación, además heroku tiene planes gratuitos que son suficientes para subir tu primer prototipo y mostrarselo a los primeros clientes. Por lo mismo en este capítulo nos enfocaremos en subir la aplicación a Heroku.

Instalando el Toolbelt de heroku Primero debemos crearnos una cuenta www.heroku.com y luego descargar el toolbelt, el cual nos permitirá lanzar comandos a heroku desde nuestro terminal. El link al toolbelt debería aparecer después de crear la cuenta pero de todas formas puedes descargar el toolbelt directamente desde toolbelt.heroku.com Luego abriremos una nueva terminal y dentro de ella escribiremos:

1

heroku login

Claves SSH Heroku intentará agregar nuestras claves ssh automáticamente, pero para eso supondrá que tu juego de claves se llama id_rsa si no las tenemos al momento de instalarlo debemos crearlas y luego agregarlas, para eso debemos ir a la carpeta .ssh dentro de tu carpeta personal y crear un nuevo juego de claves Revisamos si existe el juego de claves

1

ls ~/.ssh

Las creamos sólo si no existen.

1

ssh-keygen -t rsa

luego podemos agregar las claves SSH automáticamente a heroku con:

1

heroku keys:add

También es posible copiar y pegar el contenido de la clave ssh pública (id_rsa.pub) a través de la interfaz de heroku en la sección de configuración de cuenta.

Repositiorio GIT Configurando GIT 1 2

git config --global user.name "YOUR NAME" git config --global user.email "YOUR EMAIL ADDRESS"

Creando el repositorio git Primero debemos estar trabajando sobre un repositorio GIT si no es así, lo crearemos con:

1

git init

Subiendo la aplicación a Heroku Creando el proyecto en heroku El primer paso es crear un proyecto en Heroku, esto lo podemos hacer a través del panel de control pero es mucho más sencillo realizarlo directamente con bash en la carpeta del proyecto, los únicos requisitos son tener GIT configurado y el toolbelt de H eroku instalado. Entonces sobre un proyecto con repositorio GIT ya inicializado crearemos el proyecto en heroku con el comando:

1

heroku create

Obtendremos algo similar a lo siguiente

Creating fierce-inlet-1619... done, stack is cedar-14 https://fierce-inlet-1619.herokuapp.com/ | https://git.heroku.com/fierce-inlet-161 9.git Git remote heroku added

El nombre del subdominio será distinto.

Setup del proyecto para deployment Ahora debemos cambiar el Gemfile de nuestro proyecto, Aquí hay que remover la línea que dice sqlite3 del gemfile (puesto que heroku no la soporta) y agregar la de postgreSQL y otra que permite obtener los logs y arreglar algunos problemas de assets en producción.

1 2 3

gem 'sqlite3', group: :development gem 'pg', group: :production gem 'rails_12factor', group: :production

Como se hace siempre tras hacer un cambio en el archivo gemfile, debemos correr en el terminal el comando para actualizar nuestras gemas.

Si no agregamos las gemas, o no hacemos bundle, o no hacemos el commit después obtendremos el siguiente error.

remote:

Gem files will remain installed in /tmp/build_f0e176e4ab15d0046ef15

66d12b46eb5/vendor/bundle/ruby/2.0.0/gems/sqlite3-1.3.11 for inspection. remote:

Results logged to /tmp/build_f0e176e4ab15d0046ef1566d12b46eb5/vendo

r/bundle/ruby/2.0.0/gems/sqlite3-1.3.11/ext/sqlite3/gem_make.out remote:

An error occurred while installing sqlite3 (1.3.11), and Bundler ca

nnot remote:

continue.

remote:

Make sure that `gem install sqlite3 -v '1.3.11'` succeeds before bu

ndling. remote:

!

remote:

!

remote:

!

remote:

!

Detected sqlite3 gem which is not supported on Heroku.

remote:

!

https://devcenter.heroku.com/articles/sqlite3

remote:

!

Failed to install gems via Bundler.

remote: remote:

!

Push rejected, failed to compile Ruby app

Esto se debe a que en Heroku no se puede instalar sqlite.

Opcionalmente también podemos especifica la versión de ruby a ocupar en heroku, si no especifica se ocupará la 2.0.

Para especificar la versión de ruby debemos escribir la versión dentro del gemfile como en el siguiente caso:

1 2 3 4 5

source 'https://rubygems.org' ruby "2.2.3"

1

bundle

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails' gem 'rails', '4.2.3'

Luego estos cambios deben ser incorporados en el control de cambios de GIT.

1 2

git add Gemfile git add gemfile.lock

Subiendo los cambios a producción Primero debemos guardar los cambios realizados en GIT con:

1

git commit -m "cambios hechos"

Donde dentro de las comillas deberías especificar los cambios que se han realizado luego debemos enviar los cambios a producción, esto es lo que comunmente se llama deployment.

1

git push heroku master

Razones por las que el paso de deployment puede fallar No guardaste el Gemfile después de las modificaciones No corriste la línea en bash bundle No agregaste a GIT el Gemfile (y el Gemfile.lock) después del bundle Tienes un error en los assets

Revisando errores Si tienes un error en los assets, tenemos que encontrar el error y corregirlo, causas comunes es un archivo con una extensión errada, ej algo.csc (en lugar de css). Para debuggear esto podemos correr la línea:

1

rake assets:precompile RAILS_ENV=Production

No es bueno agregar estos assets al GIT, como vimos previamente esto correrá los preprocesadores sobre los archivos respectivos, luego concatenara los CSS y JS, luego los minificará y finalmente les añadirá un fingerprint, los assets finales quedarán dentro de la carpeta public. Después debemos borrarlos dentro de la misma carpeta, no es una buena práctica agregarlos a GIT.

Sobre la precompilación de assets La precompilación de assets es un proceso por el cual suceden las siguientes cosas:

Migrando la base de datos de producción Recuerda migrar la base de datos de producción cada vez que migres la tuya.

1

heroku run rake db:migrate

Cambiando el nombre de la aplicación en Heroku Si quieres cambiar el nombre de tu dirección entregada por heroku

1

heroku apps:rename nombrenuevo

Desafío Subir al aplicación que creaste en el capítulo anterior a heroku, el formulario debe quedar funcionando.

Preguntas 1. ¿Para qué sirve Heroku? 2. ¿Cuál es la función del toolbelt? 3. ¿Con que comando podemos crear una aplicación nueva en heroku? 4. ¿Qué motor de base de datos ocupa heroku por defecto? 5. ¿Qué cuidados debemos tener en el gemfile antes de pushear a heroku? 6. ¿Qué es el entorno de producción? 7. ¿Cómo podemos especificar la versión de ruby a utilizar?

12) Configurando el dominio (o subdominio) Una URL (Uniform Resource Locator) tiene la siguiente estructura http(s)://subdominio.dominio.dominio nivel superior

Para entenderlo bien vamos a revisarlo en orden de importancia, o sea de derecha a izquierda. Los dominios de nivel superior (ejemplo los .com, .cl, .mx) son entregados a diversas autoridades a lo largo del mundo, estas autoridades se dedican a administirar y vender los dominios. Los dominios son el nombre, es lo que uno le compra a las diversas autoridades a los largo del mundo, algunas autoridades venden solo el suyo, otras como godaddy venden de múltiples tipos. El valor de un dominio depende de múltiples factores pero principalmente depende de que tan solicitado es, hoy en día es casi imposible tomar un dominio de 4 letras, y mucho menos uno que tenga sentido, dominios de estos tipos se transan por millones de dólares. Otros dominios pueden costar incluso de 5 dólares con un cupón de descuentos, fatwallet es una buena página para buscar cupones. Una vez que tienes el dominio puedes proceder a configurarlo, y puedes agregar todos los subdominios que desees. Entonces que es el subdominio?, es lo que antecede al dominio, el más famoso de todos es www, pero puedes configrar el que quieras. Una vez comprado el dominio lo importante es configurarlo para realizar un redireccionamiento tipo Cname, algunos sistemas de los administradores no lo permiten, GoDaddy lo permite, Nic Chile por ejemplo no, ya veremos como resolver eso más adelante. En la dirección de redireccionamiento tenemos que ingresar el nombre de la aplicación. Además de eso en la línea de comando dentro de la carpeta de la aplicación debemos agregar.

1

heroku domains:add nombre_dominio

si quieres agregar el www debes agregar también

1

heroku domains:add www.nombre_dominio

Si la configuración es sólo para un subdominio es posible

1

heroku domains:add nombre_subdominio.nombre_dominio

Para probarlo simplemente entra a la página configurada. Recuerda que la propagación de nombres es lenta y por lo tanto puede demorar de 1 a 48 horas. (normalmente es una hora).

Configurando dominios cuyas autoridades no soportan redireccionamiento tipo CName Es posible lograrlo a través de un plugin de Heroku, hay dos buenos para realizar esto, son técnicamente lo mismo, PointDNS y Zerigo, ambos tienen planes gratuitos al día de hoy, pero son empresas tecnológicas y esa situación podría cambiar en el futuro, Heroku es una empresa de buenas prácticas y no realiza cobros indebidos o sin previo aviso. La configuración es sencilla: 1. Debes instalar el plugin desde el dashboard de heroku 2. Luego dentro de la página del plugin debes buscar los dns, 3. Utiliza los dns encontrados para ponerlos en la página de la autoridad 4. Debes configurar la página del plugin para que apunte a la aplicación con el nombre respectivo. 5. Igual que cuando configurabas el .com tienes que utilizar heroku domains:add nombre_dominio.cl

Tips de mantención Entrar a la consola del proyecto en producción 1

heroku run rake console

Ver los últimos logs muy útil cuando tienes errores en la versión remota pero en la local funciona bien

1

heroku logs

Dejar una consola con los logs corriendo 1

heroku logs -t

Descargando la base de datos de heroku Es posible descargar la base de datos de heroku a tu computador, y utilizarla como respaldo o, mejor aún utilizarla para trabajar con datos reales y sin el miedo de destruir datos importantes. El requisito es tener instalado postgres en el computador, puesto que ese es el sistema de bases de datos que ocupa Heroku. Paso 1: realizar una copia de la base de datos en amazon.

1

heroku pg:backups capture

Paso 2: recuperar desde amazon (ahí quedan alojadas) la base de datos

1

curl -o latest.dump `heroku pg:backups public-url`

Esto descargará un archivo que se llama latest.dump en la carpeta donde hayas lanzado la línea de comandos. Paso 3: cargar la base de datos descargada a tu sistema.

1

pg_restore --verbose --clean --no-acl --no-owner -h localhost -d nombreDeLaBaseD

Desafio Comprar un dominio .com y configurar la aplicación creada en el capítulo anterior para que quede funcionando con el dominio o con un subdominio.

Preguntas 1. ¿Cuál es la diferencia entre un dominio de nivel superior y un dominio? 2. ¿Qué es y para que sirven los subdominios?

3. ¿Donde se compra un dominio.com? 4. ¿Qué configuración debemos hacer para configurar nuestro .com? 5. ¿Qué significa DNS? 6. ¿Qué tipo de redirección no soporta Heroku? 7. ¿Que podemos hacer para configurar un dominio cuyo servidor de nombre no es compatible con los redireccionamientos de Heroku? 8. ¿En qué consiste el modo de mantención de Heroku? 9. ¿Cómo podemos ver los logs de Heroku?

Sección III SQL y bases de datos

13) SQL SQL es un lenguaje que permite realizar consultas de bases de datos, es del tipo declarativo porque uno en lugar de especificar el como obtener los resultados uno simplemente pide lo que necesita y SQL lo devuelve. Existen diversas implementanciones de SQL, siendo las más famosas MySQL, PostgreSQL y Oracle, hoy en día MySQL le pertenece a Oracle y a pesar de que algunas implementaciones siguen bajo licencia GPL también ha incorporado diversas licencias comerciales lo que empujó a diversos miembros de la comunidad a moverse a PostgreSQL, ahora la principal razón para utilizar Postgre no es el tema de las licencias si no el soporte de diversos tipos de datos nativos que funcionan muy bien con Ruby on Rails.

PostgreSQL Rails es un framework agnóstico a la base de dat os, esto quiere decir que puede ser configurado con cualquiera de ella mientras existan los drivers, y existen drivers para todas las bases de dat os conocidas. Al día de hoy PostgreSQL es la mejor opción para trabajar con rails, primero porque viene configurado con heroku y homologar los entornos de desarrollo con el de producción facilita el desarrollo y pruebas del software, pero además Postgres incluye diversas funcionales como manejo nativos de array y de hashs que abordaremos más adelante en este libro.

Instalando PostgreSQL en OSX Para instalar postgreSQL podemos descargar la aplicación postgreAPP esta automáticamente creará un usuario con el mismo nombre de usuario del sistema. Esta forma es fácil de prender y apagar y nos aseguramos de que el servidor no esté corriendo de fondo gastando recursos en nuestro computador.

Instalando PostgreSQL en Linux Podemos instalar PostgreSQL en linux utilizando apt-get

1

apt-get install postgre sql-9.4

También es posible instalar la interfaz gráfica de pgadmin http://www.pgadmin.org/

Entrando a PSQL Una vez instalado y corriendo psql Ahora necesitamos entrar a PostgreSQL para crear una base de datos. En linux

1

su - postgres

En OSX

1

psql

Para que lo anterior funcione, el servicio debe de estar corriendo, pues en caso contrario obtendremos un:

1 2 3

psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

Para entrar a psql tenemos que

1

psql

Insensible a las mayúsculas Una curiosidad que tiene SQL es que es un lenguaje insensible a las mayúsculas, la convención consiste en escribir las palabras reservadas de SQL en mayúsculas, y los nombres de las tablas y valores en minúsculas

Creando usuarios Luego podemos crear un usuario con:

1

CREATE USER nombre_usuario;

Cambiando la clave En postgres los usuarios y los roles son lo mismo, podemos cambiar el password de un usuario con:

1

ALTER ROLE x WITH password 'xx';

Dando acceso de superusuario 1

ALTER ROLE nombre_usuario WITH superuser;

Listando a todos los usuarios creados en la base de datos. Podemos listar a todos los usuarios para ver si los creamos exitosamente.

1

gonzalosanchez=# \du

Role name

Attributes

Member of

desafio_blog

Superuser

{}

super_gonzalo

Superuser

{}

admin

Superuser, Create role, Create DB, Replication

{}

Creando una base de datos En SQL las tablas son archivos, archivos que contienen un solo formato y se parecen en cierto sentido a un excel, sólo que las columnas son fijas. Cuando creamos una tabla definimos una estructura, cuando insertamos datos no podemos salirnos de la estructura de la tabla definida, sin embargo en el futuro podemos cambiar la estructura de la tabla siempre y cuando especifiquemos que hacer con los datos que existen actualmente. Una base de datos es un conjunto de tablas que pueden o no estar relacionadas entre ellas. Para crear una base de datos simplemente debemos utilizar el comando

1

CREATE DATABASE nombre_base_de_datos;

Listando una base de datos. Postgre al igual que otros motores de bases de datos maneja múltiples bases de datos, y cada usuario del sismte Para listar todas las bases de datos lo podemos hacer con \l

Botando una base de datos Para poder borrar una base de datos existente utilizaremos el comando

1

DROP DATABASE nombre_base_de_datos

Por lo mismo en lugar de borrar se dice botar una base de datos, por el drop.

No hay vuelta atrás de este comando, por lo mismo hay que utilizarlo con mucha responsabilidad y siempre respaldar las bases de datos, especialmente antes de hacer este tipo de operaciones.

Conectándose a una base de datos Para poder ver los datos de las diversas tablas que hay dentro de una base de datos necesitamos primero conectanos a una, eso lo podemos lograr con:

1

\c nombre_base_de_datos

Para poder conectarnos a una base de datos necesitamos estar dentro de Postgres con un usuario que tenga permisos para poder ver esa base de datos.

Manejo de tablas Finalmente una vez dentro de la base de datos podemos hacer queries a las tablas, para saber que t ablas

hay dentro de la base de datos con

1

\t

Para poder crear tablas, que son archivos con estructuras fijas, primero vamos a tener que entender un poco más de estas estructuras, y para eso hay que entender que cada columna tiene un nombre y un tipo de dato. Columna = Nombre + Tipo de dato

Introducción a tipos de datos. Los tipos de datos básicos en Postgres 9.4 se dividen en diversas categorías: Numéricos, Monetarios, de caractéres, binarios, de fechas, booleanos, de enumeración, geométricos e incluso existen tipos de datos para manejar json, xml, hashs y arrays. Los detalles exacto de los tipos de datos no los abordaremos en este libro pero pueden ser consultados en la doumentación oficial de PostgreSQL. http://www.postgresql.org/docs/9.4/static/datatype.html Partamos creando una tabla con los tipos más simple, integer y varchar integer, que permite guardar enteros de hasta 4 bytes, o sea números entre -2147483648 to +2147483647 varchar(n) el cual permite almacenar strings de hasta n caracteres

Creando una tabla La sintaxis básica para crear tablas es la siguiente: CREATE TABLE table_name( column1 datatype, column2 datatype, column3 datatype, ….. columnN datatype ); Ahora con esto nosotros guardaremos datos en una tabla que almacena personas con nombre y edad

1 2 3 4

CREATE TABLE personas( name varchar(64), age integer );

Manipulando valores de una tabla Insertando valores Para insertar valores dentro de la tabla podemos hacerlo con el comando INSERT, la sintaxis básica es la siguiente:

1

INSERT INTO table_name VALUES ('valor_campo1', 'valor_campo2');

Para insertar valores en la tabla persona, insertamos un nombre y una edad.

1 2

INSERT INTO personas VALUES ('Camila', '26'); INSERT INTO personas VALUES ('Gonzalo', '30');

Leyendo valores de una tabla. Para leer datos de una tabla la instrucción es SELECT, con SELECT nosotros podemos especificar los valores que queremos o utilizar * para indicar que queremos todos los campos de la tabla.

1

SELECT * FROM personas;

name

age

Camila

26

Gonzalo

30

(2 rows) Si queremos sólo un campo podemos indicarlo

1

SELECT name FROM personas;

name

Camila Gonzalo

Actualizando valores de una tabla Para cambiar valores ocuparemos la instrucción update

1

UPDATE personas SET age = 28;

Sorpresivamente obtendremos lo siguiente: UPDATE 2, o sea se cambiaron 2 valores, si ahora mostramos todas las personas con SELECT * FROM personas; veremos:

name

age

Camila

28

Gonzalo

28

Para cambiar sólo una persona debemos acompañar el update de la instrucción where

1

UPDATE personas SET age = 30 WHERE name = 'Gonzalo'

Debemos cuidar las comillas, estas t ienen que ser comillas simples cuando remplazemos valores por strings, en lugar pueden ir sin comillas cuando los valores sean numéricos.

1

UPDATE personas SET age = 31 WHERE age = 30;

Borrando datos de una tabla Podemos borrar datos ocupando la instrucción delete, pero debemos tener mucho cuidado de ocupar el where o borraremos todos los datos.

1

DELETE FROM personas;

DELETE 2 << UPS ahora para la siguiente prueba vamos a insertar nuevamente los valores.

1 2 3

INSERT INTO personas VALUES ('Julian', '55'); INSERT INTO personas VALUES ('Fernanda', '19'); INSERT INTO personas VALUES ('Paulina', '20');

Podemos borrar bajo la condición de igualdad, pero también podemos borrar bajo otras condiciones, como en el siguiente ejemplo:

1

DELETE FROM personas WHERE age < 25;

Modificando una tabla Previamente dijimos que la estructura de una tabla es fija y no puede ser cambiada, pero eso se refiere en cuanto a que la inserción de datos no puede salirse de la estructura de la tabla, sin embargo en SQL tenemos una instrucción para cambiar el formato de la tabla, y ese es ALTER

Agregando una columna 1

ALTER TABLE personas ADD COLUMN id VARCHAR(16);

Removiendo una columna 1

ALTER TABLE personas DROP COLUMN id;

Constraints Los constraints son reglas que creamos para cuidar la integridad operacional de la base datos, o sea que los datos que tengamos cumplan con las reglas del negocio, algunos son muy obvios como por ejemplo que el precio o el stock de un producto no puedan ser negativos, otros son exclusivos del negocios, por ejemplo tener x productos comprados para poder obtener ciertos descuentos. Creemos la tabla productos para probarlo

1 2 3 4

CREATE TABLE products ( name VARCHAR(100), price NUMERIC CHECK (price > 0) );

Si intentamos ingresar un producto con precio negativo obtendremos:

1

ERROR:

new row for relation "products" violates check constraint "products_pric

Evitando valores nulos Al momento de crear la tabla, o de alterarla podemos establecer que una columna no pueda tener valores nulos, esto es muy conveniente para evitar errores de integridad de datos.

1 2 3 4

CREATE TABLE products2 ( name VARCHAR(100) NOT NULL, price NUMERIC CHECK (price > 0) );

Si intentamos insertar productos con:

1

INSERT INTO products2 VALUES (NULL, 100);

1

INSERT INTO products2 (price) VALUES (100);

o

ERROR: null value in column "name" violates not-null constraint DETAIL: Failing row contains (null, 100). Eso no evita que podamos ingresar valores vacíos

El constraint Unique

1 2 3 4

CREATE TABLE products3 ( name VARCHAR(100) UNIQUE, price numeric CHECK (PRICE > 0) );

1 2

INSERT INTO products3 (name, price) VALUES ('producto 1', 100); INSERT INTO products3 (name, price) VALUES ('producto 1', 100);

Obtendremos primero un insert y luego un error de duplicated key, puesto que el nombre debe ser único.

La clave primaria La clave primaria es una combinación entre los constraints NOT NULL y UNIQUE, pero además es un índice, que en este caso permite encontrar de forma rápida los resultados, y además te asegura que sea único los resultados, esto en la mayoría de los casos hace sentido, por ejemplo todos los autos tienen una patente la cual es única dentro de cada país, y esta clave permite encontrar todos los datos referentes a ese auto específico, en la mayoría de los países existe un identificador asociado a las personas, (RUT, RUN, RFC, nº de seguridad social, etc..) Para agregar una clave primaria tenemos que alterar la estructura de la t abla puesto que vamos a agregar un índice que en cierto sentido es como agregar una columna.

1

ALTER TABLE personas ADD PRIMARY KEY (id);

Si hemos ido siguiendo la secuencia de este libro en este momento obtendremos el siguiente error.

ERROR:

column "id" contains null values

El error dice que una columna con clave primaria no puede tener valores null y eso tiene mucho sentido ya que este es un identificador único. Por lo mismo ahora tenemos que darles id a todas las personas que tengamos en la base de datos, si has seguido la secuencia debería ser sólo una persona.

1


name

age

Julian

55

id

1

UPDATE personas SET id=1 WHERE name='Julian';

y ahora si podremos cambiar la tabla personas

1

ALTER TABLE personas ADD PRIMARY KEY (id);

Si todo está bien en lugar de error, obtendremos como output alter table, pero ahora nunca más podremos ingresar usuarios sin id o con un id que esté repetido. Por ejemplo, si hacemos un insert ahora con el mismo id

1

INSERT INTO personas VALUES ('Julian', 55, 1);

Obtendremos:

ERROR: DETAIL:

duplicate key value violates unique constraint "personas_pkey" Key (id)=(1) already exists.

Pero si podemos hacerlo si realizamos un I NSERT con:

1

INSERT INTO personas VALUES ('Julian', 55, 2);

Creando una tabla con primary key Es posible crear directamente una tabla con clave primaria, la sintaxis es la siguiente:

1 2 3 4

create table ejemplo1 ( columna1 tipo primary key, columna2 tipo )

Ordenando los resultados. Para esta sección necesitaremos un mini set de datos, para eso borraremos todos los que tenemos e ingresaremos nuevos.

1 2 3 4 5

DELETE INSERT INSERT INSERT INSERT

FROM personas; INTO personas VALUES ('Francisca', 30, 1); INTO personas VALUES ('Juan', 31, 2); INTO personas VALUES ('Javier', 32, 3); INTO personas VALUES ('Penelope', 28, 4);

Mostrando todos los resultados

1


name

age

id

Francisca

30

1

Juan

31

2

Javier

32

3

Penelope

28

4

Mostrando los resultados ordenados por edad Para ordenar por algún criterio tenemos que agregar order by y la columan sobre la cual vamos a ordenar.

1

SELECT * FROM personas ORDER BY age;

name

age

id

Penelope

28

4

Francisca

30

1

Juan

31

2

Javier

32

3

Mostrando los resultados ordenados por nombre alfabéticamente pero en reverso. Esto lo logramos ocupando DESC en la query.

1

SELECT * FROM personas ORDER BY name DESC;

name

age

id

Penelope

28

4

Juan

31

2

Javier

32

3

Francisca

30

1

(4 rows)

Limitando la cantidad de resultados Podemos limitar los resultados agregando al query la instrucción LIMIT

1

SELECT * FROM personas LIMIT 1;

Es combinable con otras instrucciones por ejemplo con las de ordenamiento

1

SELECT * FROM personas ORDER BY name DESC LIMIT 1;

Conteo Aquí la sintaxis es ligeramente distinta, en lugar de seleccionar una tabla en específico seleccionaremos la cuenta de elementos de esa tabla

1

SELECT COUNT(*) FROM personas;

En este caso obtendremos 4.

Select distinct Para los siguientes ejemplos necesitamos un par de datos más, para eso vamos a ingresar a otra mujer llamada Penelope en la base de datos de distinta edad.

Nuestro set de datos quedaría:

1


name

age

id

Francisca

30

1

Juan

31

2

Javier

32

3

Penelope

28

4

Penelope

30

5

Podemos seleccionar de la base de datos todos los nombres distintos, o sea si hay un nombre repetido no aparecerá en la respuesta.

1

SELECT DISTINCT(name) FROM personas;

name

Javier Juan Penelope Francisca

Un ejemplo donde esto podría ser muy útil es si queremos extraer de nuestra base de datos cuantas personas hay de cada país o ciudad ( o ambas)

Distinct y count Podemos combinar distinct y count para contar la cantidad de elementos distintos.

1

SELECT COUNT(DISTINCT(age)) FROM personas;

Con los datos de nuestro ejemplo deberíamos obtener 4, y si hacemos el count sin el distinct deberíamos obtener 5

Preguntas 1. ¿Qué tipo de lenguaje es SQL? 2. ¿Cómo se entra a SQL? 3. ¿Cómo crear un usuario en psql? 4. ¿Qué comando muestra todas las bases de datos dentro de postgresql? 5. ¿Qué comando muestra todas las usuarios dentro de postgresql? 6. ¿Cuál es la diferencia entre una base de datos y una tabla? 7. ¿Cómo se le da permisos a un usuario para poder modificar una base de datos? 8. ¿Cómo insertar datos en una tabla existente 9. ¿Qué es la clave primaria? 10. ¿Por qué es importante especificar el where en las instrucciones de update y delete? 11. ¿Cómo se puede borrar una base de datos? 12. ¿Cómo se puede borrar una tabla? 13. . ¿Cómo se puede obtener la persona de mayor edad de la tabla personas? 14. ¿Qué hace select distinct? 15. ¿Qué son los constraints?

Guía de ejercicios Peliculas Completar los queries y poner la consulta SQL repectiva de cada pregunta subirlos a la plataforma de empieza.

CRUDS 1. Crear la base de datos movies 2. Crear la tabla movie con la clave primaria id y nombre 3. Ingresar la película El Rey León 4. Ingresar la película Terminator II

5. Alterar la tabla películas para agregar el año 6. Cambiar los datos de todas las películas existentes a 1984 7. Borrar la película Terminator II 8. Crear un usuario nuevo en la base de datos 9. Asignarle un rol que sólo permite hacer consultas select (no podrá ingresar) 10. Cambiar de usuario en la base de datos 11. Probar que no puede ingresar una película

Sorting 1. Ingresar 5 películas más, con nombres y años distintos. 2. devolver las primeras 3 películas (ordenadas alfabéticamente) 3. devolver las últimas 3 películas (ordenadas por año)

Conteo 1. Contar la cantidad de películas en la base de datos 2. Contar la cantidad de películas por año. 3. Alterar la tabla para agregar la categoría de la película 4. Agregar categorías a todas las películas existentes 5. Obtener un listado de las categorías (sin repeticiones)

Productos Completar los queries y poner la consulta SQL repectiva de cada pregunta subirlos a la plataforma de empieza. 1. Crear la base de datos productos 2. Crear la tabla productos con id, nombre, precio 3. id debe ser la clave primaria, agregar el contraint de que el precio debe ser mayor que cero y el nombre del producto único. 4. Insertar 10 productos 5. Contar la cantidad de elementos que hay, se deberían obtener 10 6. Contar la cantidad de elementos que hay con precio mayor a 1000 7. Contar la cantidad de elementos que hay con precios distintos 8. Ordenar los productos por precio

14) SQL con más de una tabla Integridad referencial La integridad es un concepto asociado a la calidad y validez de los datos, por ejemplo supongamos como en el caso del ejercicio anterior tenemos películas y categorías pero que pasa si queremos renombrar una categoría, entonces tendríamos que asegurarnos de cambiar todas las referencias a la categoría en la tabla películas, en una base de datos pequeñas esto podría no ser un problema pero en bases de datos grandes es más complejo. ¿Cómo se soluciona el problema de las referencias? Separando una tabla en dos partes, la primera contiene los datos donde insertaremos la película, la segunda es una tabla donde insertaremos todas las categorías, y las relacionaremos a través de un número.

De esta forma sólo tenemos que cambiar el valor dentro de la categoría para cambiar todos los valores referidos.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

create table movies ( id integer primary key, title varchar(64), category_id integer ); create table categories ( id integer primary key, name varchar(64) ); INSERT INTO categories VALUES (1, 'Acción'); INSERT INTO categories VALUES (2, 'SCI FI'); INSERT INTO categories VALUES (3, 'Animación'); INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT

INTO movies INTO movies INTO movies INTO movies INTO movies INTO movies INTO movies INTO movies INTO movies

VALUES (1, VALUES (2, VALUES (3, VALUES (4, VALUES (5, VALUES (6, VALUES (7, VALUES (8, VALUES (9,

'Terminator', 1); 'Terminator 2', 1); 'Volver al futuro', 2); 'Terminator 3', 1); 'Volver al futuro 2', 2); 'Tiburón', 1); 'Akira', 3); 'Ghost in the Shell', 3); 'Duro de matar', 1);

Luego podemos juntar ambas tablas ocupando la instrucción SELECT

1

SELECT * FROM movies, categories;

id

title

category_id

id

name

1

Terminator

1

1

Acción

2

Terminator 2

1

1

Acción

3

Volver al futuro

2

1

Acción

4

Terminator 3

1

1

Acción

5

Volver al futuro 2

2

1

Acción

6

Tiburón

1

1

Acción

7

Akira

3

1

Acción

8

Ghost in the Shell

3

1

Acción

9

Duro de matar

1

1

Acción

1

Terminator

1

2

SCI FI

2

Terminator 2

1

2

SCI FI

3

Volver al futuro

2

2

SCI FI

4

Terminator 3

1

2

SCI FI

5

Volver al futuro 2

2

2

SCI FI

6

Tiburón

1

2

SCI FI

7

Akira

3

2

SCI FI

8

Ghost in the Shell

3

2

SCI FI

9

Duro de matar

1

2

SCI FI

1

Terminator

1

3

Animación

2

Terminator 2

1

3

Animación

3

Volver al futuro

2

3

Animación

4

Terminator 3

1

3

Animación

5

Volver al futuro 2

2

3

Animación

6

Tiburón

1

3

Animación

7

Akira

3

3

Animación

8

Ghost in the Shell

3

3

Animación

9

Duro de matar

1

3

Animación

El problema es que hacerlo nos da el producto cartesiano entre ambas tablas, o sea todos los datos con todos los otros, que obviamente no es lo que queremos, para obtener los resultados que buscamos tenemos que utilizar la instrucción where.

1

SELECT * FROM movies, categories WHERE categories.id = movies.category_id;

id

title

category_id

id

name

1

Terminator

1

1

Acción

2

Terminator 2

1

1

Acción

3

Volver al futuro

2

2

SCI FI

4

Terminator 3

1

1

Acción

5

Volver al futuro 2

2

2

SCI FI

6

Tiburón

1

1

Acción

7

Akira

3

3

Animación

8

Ghost in the Shell

3

3

Animación

9

Duro de matar

1

1

Acción

Y estos si son los resultados que queremos.

Ambiguedad en los nombres Cuando hay campos con los mismos nombres en ambas tablas no podemos ser ambiguos, por ejemplo si realizamos el query:

1

SELECT * FROM movies, categories WHERE id = category_id;

ERROR: column reference "id" is ambiguous LINE 1: SELECT * FROM movies, categories WHERE id = category_id; Es por lo mismo que en la mayoría de los casos tendremos que utilizar tanto el nombre de la tabla como el nombre del campo.

Joins Otra forma de lograr resultados similares es utilizando la instrucción JOIN

1

SELECT * FROM movies INNER JOIN categories ON (categories.id = movies.category_i

Tipos de joins Hay diversos tipos de join y principalmente difieren en como tratar la unión de estos conjuntos cuando los valores no están asociados.

Para entender bien la diferencia vamos a ingresar una película sin categoría y una categría sin película.

1 2

INSERT INTO movies VALUES (10, 'Película sin categoría'); INSERT INTO categories VALUES (4, 'Categoría sin películas');

Luego si probamos:

1

SELECT * FROM movies, categories WHERE categories.id = movies.category_id;

O si probamos:

1

SELECT * FROM movies INNER JOIN categories ON (categories.id = movies.category_i

En ambos casos no obtendremos resultados ni de la película nueva ni de la categoría nueva.

Left Outer Join 1

SELECT * FROM movies LEFT OUTER JOIN categories ON (categories.id = movies.categ

id

title

category_id

id

name

1

Terminator

1

1

Acción

2

Terminator 2

1

1

Acción

3

Volver al futuro

2

2

SCI FI

4

Terminator 3

1

1

Acción

5

Volver al futuro 2

2

2

SCI FI

6

Tiburón

1

1

Acción

7

Akira

3

3

Animación

8

Ghost in the Shell

3

3

Animación

9

Duro de matar

1

1

Acción

10

Película sin categoría

Right Outer Join 1

SELECT * FROM movies RIGHT OUTER JOIN categories ON (categories.id = movies.cate

id

title

category_id

id

name

1

Terminator

1

1

Acción

2

Terminator 2

1

1

Acción

3

Volver al futuro

2

2

SCI FI

4

Terminator 3

1

1

Acción

5

Volver al futuro 2

2

2

SCI FI

6

Tiburón

1

1

Acción

7

Akira

3

3

Animación

8

Ghost in the Shell

3

3

Animación

9

Duro de matar

1

1

Acción

4

Categoría sin películas

Full Outer Join 1

SELECT * FROM movies FULL OUTER JOIN categories ON (categories.id = movies.categ

Tipos de relaciones Recientemente separamos la tabla películas en dos tablas para evitar tener datos repetidos como el nombre de la película dentro de cada una. Al tener dos tablas se generó una relación entre ellas, podemos decir que una película tiene una categoría, pero una categoría puede tener múltiples películas, este tipo de relaciones se llama de uno a muchos, puesto que a un elemento de una tabla de la base de datos le corresponden varios elemetnos de la otra tabla. Hay tres tipos de relaciones famosas. Relaciones de uno a uno. Relaciones de uno a muchos. Relaciones de muchos a muchos.

Relaciones de uno a uno Las relaciones de uno a uno consisten en dividir un tabla que tiene muchas columnas en dos, para esto supongamos que estamos construyendo un software de ventas y tenemos una tabla de usuarios. Donde la tabla tiene: nombre edad direccion telefono tarjeta de credito rut (identificador de la persona) compañia direccion compañia telefono compañia cargo En una tabla como esta podemos separar los datos del usuario con los de la compañía, y sólo llenarlos si la persona tiene compañía, entonces quedaría la tabla usuarios y la tabla de compañías, pero para unirlas tenemos que hacer una de dos, guardar un id de la compañía en la tabla usuarios o guardar el usuario en la tabla de compañía, determinar cual es la mejor forma tiene que ver más con el diseño de la aplicación que con el de la base de datos, pero la pregunta de rigor que nos haríamos es que se guardará primero, si creamos el usuario y luego la compañía es más sencillo guardar el usuario en la compañía, si creamos primero la compañía y luego al usuario probablemente sea más sencillo guardar el dato de la compañía en el usuario.

Hay diversas formas de diagramar las relaciones, usualmente se representa con una flecha cuando tiene un elemento y con doble flecha cuando tiene más de un elemento.

Relaciones de 1 a n Estas son las relaciones más frecuentes, normalmente sucede cuando hay una tabla de datos y una tabla de categoría de esos datos, por ejemplo: persona y pais, o, ciudad o país, pelicula y categoría. En otros casos sucede cuando también hay un dueño de muchas cosas, por ejemplo un autor y sus posts, o un autor y sus comentarios.

Relaciones de n a n Estas relaciones se dan cuando la autoría de algo es compartida, por ejemplo un proyecto puede tener varios integrantes, pero a su vez un integrante puede tener varios proyectos, o una persona puede tener permisos para varias secciones, pero cada sección puede ser accedida por varios usuarios.

Estas relaciones son un poco más complejas porque no se pueden representar directamente en un modelo de datos relacional, porque donde pondríamos los índices?, si los agregamos por el lado de usuarios un proyecto_id como haríamos para meter varios proyectos?, por otro lado si lo agregamos del lado del proyecto con usuario_id como haríamos para meter varios usuarios? La solución es convertir la relación de n a n en dos relaciones de 1 a N.

De esta forma pueden haber cuantas personas quieran trabajando en cuantos proyectos quieran.

La clave foránea La clave foránea (en ingés Foreign Key o FK) es un índice que permite mantener la integridad referencial entre dos tablas, principalmente evita que se borre un elemento de una tabla si hay otros que se refieran a el.

En nuestro ejemplo anterior no podríamos borrar la categoría acción porque hay películas que utilizan esa categoría.

1 2 3 4

CREATE TABLE movies2 ( id integer PRIMARY KEY, category_id integer REFERENCES categories (id) );

Ahora si intentamos ingresar una película con una categoría que no existe, obtendremos:

1

Insert into movies2 values (2, 10);

ERROR:

insert or update on table "movies2" violates foreign key constraint "movie

s2\_category\_id\_fkey" DETAIL:

Key (category_id)=(10) is not present in table "categories".

Preguntas 1. ¿Cuál es la diferencia entre los outer y los inner joins? 2. ¿Cuál es la diferencia entre `SELECT * FROM movies, categories;` y `SELECT * FROM movies, categories WHERE categories.id = movies.category_id;`? 3. ¿Cuál es la diferencia entre SELECT * FROM movies, categories WHERE categories.id = movies.category_id; e y realizar el mismo select con inner join? 4. ¿Por qué es importante en el select nombrar la tabla? 5. ¿Para qué sirven las relaciones de 1 a 1? 6. Nombre 5 ejemplos donde sería útil una relación de 1 a n 7. Nombre 5 ejemplos donde sería útil una relación de n a n 8. ¿Para qué sirve la clave foránea? 9. ¿Qué significa FK?

Ejercicios

Shopping Crear la base de datos shopping101 y dentro de ella. Crear la tabla compradores, con id y nombre Ingresar al menos 5 compradores Crear la tabla país con id y nombre Ingresar al menos 5 países Alterar la tabla compradores para agregar la columna pais_id Agregar un par de usuarios que no tenga paises asignados Obtener todos los usuarios con todos los paises Obtener todos los países que no tienen asigando ningún usuario Obtener la cantidad de usuarios de cada país Obtener al país con mayor cantidad de usuarios

movieDB 1. Crear la base de datos moviedb ####Relaciones 1 a n 2. Crear la tabla category 3. agregar la columna category_id a movie 4. Ingresar 3 categorías de películas Acción Terror Drama 5. Ingresar las FK para relacionar las películas existentes con las categorías respectivas 6. Obtener todas las películas de la categoría Acción y contarlas 7. Ordenar la tabla de categorías según la cantidad de películas que hay con esas categorías

Relaciones n a n 1. Crear la tabla tags, con una clave primaria id, y el campo tag 2. crear la tabla movie_tags con la clave primaria id, y las claves foraneas tag_id y movie_id 3. Ingresar un grupo de tags 4. Asignar 3 tags a cada películas (puedes ocupar más de un insert) 5. Obtener todas los nombres de las películas con el tag dinosaurios 6. Utilizando joins, devuelve todas las películas con todos sus tags 7. Contar la cantidad de tags que tiene cada película -hint tienes que hacer dos joins en el mismo query 8. Devolver los tags ordenados por mayor uso -hint hacer el join sólo con la tabla intermedia

Exportando datos 1. Exportar todos los datos en un archivo SQL

14) Modelando con SQL Objetivos 1. Repasar SQL a través de casos prácticos 2. Modelar diversos ejemplos típicos de aplicaciones

El secreto para modelar con SQL es distinguir bien cuales son las tablas y cuales son los at ributos de esas tablas, por ejemplo supongamos que queremos hacer un blog, entonces claramente un blog tiene artículos, ahora los comentarios son un campo de artículo o una tabla aparte?, el t ítulo del artículo es un campo del blog o no?, todo ese tipo de preguntas tenemos que poder hacernos para poder modelar con SQL. Es muy importante tener experiencia en esto para trabajar en rails puesto que Rails no modela por nosotros, sólo nos genera las consultas SQL de forma automática.

Modelando un blog Lo primero que tenemos que hacer es distinguir a los actores y las acciones principales. Entonces: - una visita entra y ve artículos - una visita entra al artículo puede leerlo y ver sus comentarios una visita se registra y se convierte en un usuario - un editor (el cual es un tipo de usuarios puede crear articulos nuevos) - un editor puede borrar artículos y comentarios - al borrar un articulo se deben borrar todos sus comentarios La pregunta de rigor al modelar es ¿qué infomración necesitamos utilizar? y para poder utilizarla ¿quçe necesitamos guardar?. Respecto a nuestro blog tenemos que considerar algunas preguntas y comentarios ¿Vamos a guardar las visitas en la base de datos o no?, quizas no sea útil ya que estas no registran nada, si queremos medir el acceso de visitas podemos hacerlo utilizando alguna solución como google analytics y no tenemos la necesidad de meter estos datos en nuestra base de datos. Los artículos necesitamos guardarlos, porque vamos a mostrar esa información, cada artículo puede tener un título y una foto. Los usuarios necesitamos guardarlos, y surge de aquí un tipo de usuario el cual es el editor, por lo tanto tenemos que guardar el tipo del usuario dentro de la base de datos para consultarlo después. Hay comentarios, y estos tenemos que guardarlos para poder mostrarlos, y le pertenecen a un

usuario, pero además uno comenta dentro de un artículo, y dentro de un artículo pueden haber varios comentarios, así que los comentarios le pertenecen a un artículo. Entonces el modelo quedaría:

Las convenciones son muy importantes, especialmente cuando trabajamos con Rails, una de estas convenciones es la del nombre de las claves foráneas, el nombre debe ser el nombre de la tabla referida en singular con un sufijo id. O sea si la tabla comentario tiene usuarios, la FK debería llamarse usuario_id y en lo posible todos los nombres en inglés para evitar problemas.

Ejercicio Crear la blase de datos blogX Crear un usuario llamado "Julian" del tipo editor Crear 5 artículos y asociarlos al usuario creado Crear 3 usuarios más y agregar comentarios a los artículos creados Mostrar todos los articulos con la cantidad de comentarios de cada uno Mostrar todos los usuarios con la cantidad de comentarios creados de cada uno Mostrar los articulos junto con la información del editor.

Modelando Tinder Tinder es una famosa red social de citas, que tiene usuarios y tu ves personas marcando si te gustas o no, si ambas se marcan como gustados entonces es un match, ahora hay múltiples formas de modelar esto, pero analizemos alguna. La pregunta entonces es, que actores hay, y que información nos interesa guardar. Claramente necesitamos a los usuarios con sus fotos, en este momento no es importante que los usuarios se saquen de Facebook porque necesitamos guardarlos de todas formas en nuestra base de

datos. Por otro lado lo que nos interesa guardar son dos cosas, una los likes, un usuario hace like a otro, entonces un usuario da y recibe likes, cuando existe un like del usuario uno al dos y existe uno del dos al uno entonces hacemos match. En nuestra aplicación puede (o puede que no) importarnos de que likes viene el match, una vez que ya lo hacemos podemos darnos el lujo de perder esa información, pero si debemos saber entre que usuarios se hizo match.

Ahora en el funcionamiento de la aplicación, se encuentran personas que están cerca, por lo tanto tenemos que saber donde están esas personas, para eso agregaremos latitud y longitud, y además no podemos mostrarle usuarios que ya haya descartado a una persona, por lo que tenemos que guardar la información de si la interacción fue de like o unlike, para eso renombraremos la tabla like a interacciones y guardaremos cada interacción entre un usuario uno y otro.

Ejercicios de diagrama Modificar el diagrama para que el usuario pueda agregar todas las fotos que quiera. Agregar la tabla de mensajes para guardar los mensajes entre usuarios.

Ejercicios de SQL Crear las tablas en el modelo Agregar 10 usuarios Agregar 4 interacciones positivas Agregar 4 interacciones negativas Obtener todos los usuarios con los que hayas tenido una interacción negativa Obtener todos los usuarios con los que hayas tenido una interacción positiva Obtener todos los usuarios con los que no hayas tenido una interacción. Obtener todos los nombres de los matches de un usuario.

Modelando un carro de compras El carro de compras más básico consiste en un carro donde guardamos los items que queremos y después procedemos a hacer el chekcout. Una pregunta interesante que uno debe hacerse es, ¿nos interesa guardar el carro de compras?, es perfectamente posible que solo nos interese guardar los items comprado y no el carro mismo, muchas veces el carro solo se guarda en la sesión del navegador.

Como no podemos tener relaciones de n a n romperemos la tabla ocupando una intermedia

Ejercicio Crear las tablas en la base de datos. Ingresar 5 items Ingresar 2 usuarios Generar una orden de compra con dos items Obtener todos los items que ha comprado un usuario Obtener los items más comprados

Sección IV: Backend

15) Rails con PSQL Objetivos 1. Aprender a crear un proyecto rails con PostgreSQL como motor de base de datos 2. Aprender a modificar un proyecto rails existente para agregar PostgreSQL como motor de base de datos

Instalando postgre en un proyecto existente En ruby todas las componentes se llaman gemas, en este caso instalaremos los drivers de postgre para ruby utilizando

1

gem install pg

Luego debemos cambiar el archivo de configuración de desarrollo, este se encuentra en el archivo database.yml.

1 2 3 4 5 6 7

development: adapter: postgresql encoding: unicode database: nombre_base_de_datos pool: 5 username: usuario password: password

Los archivo yaml o .yml requieren de una identación perfecta, asegura de agregar espacios de sobre ni que falten, así como no agregar comillas donde no vayan.

Con el archivo database configurado el siguiente paso es abrir el archivo gemfile, sacar la gema de sqlite3 del entorno de desarrollo y agregar la gema ‘pg’ al entorno de desarrollo, (y de producción si así se desea) Luego correremos el comando

1

bundle

y finalmente creamos la base de datos

1 2

rake db:setup rake db:create

Existen posibilidades de que el usuario puesto en la configuración no tenga permisos para crear bases de datos, en ese caso debemos o cambiar el usuario de la configuración, o darle acceso a ese usuario a crear bases de datos, o finalmente crear la base de datos a mano.

Creando un proyecto con postgreSQL Es posible crear un proyecto directamente ocupando postgreSQL con

1

rails new myapp --database=postgresql

De todas formas necesitaremos abrir el archivo database.yml para configurar nuestra base de datos, sin embargo no tendremos que abrir el gemfile para remover la gema sqlite3 y agregar la gema pg.

El error de socket Existe un error muy común al cargar el servidor de rails y abrir la página que dice

could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

Esto normalmente se debe a que el servidor de postgreSQL no está corriendo.

Preguntas 1. Por qué es necesario configurar el archivo database.yml si creamos el proyecto con `rails new myapp –database=postgresql` 2. ¿Qué hace rake db:create? 3. ¿Qué hace rake db:setup?

4. ¿Cuál es la diferencia entre instalar postgres en el sistema operativo e instalar la gema de postgre en el proyecto rials? 5. ¿En qué archivo se configura la base de datos?

16) Los modelos en rails Objetivos 1. Entender el concepto de modelo como ORM 2. Manejar las migraciones para modificar la base de datos 3. Agregar datos a través de rails console 4. Agregar datos a través del archivo seed 5. Utilizar atributos virtuales

El concepto de modelo en rails puede ser complicado de entender porque es simultaneamente dos cosas. En primera opción es un ORM (object relational mapper) lo cuál consiste en conectar elementos de dentro de una tabla de base de datos con un objeto de alto nivel que nos permite abstraernos del SQL y trabajar con objetos que saben buscarse, actualizarse y guardarse en la base de datos. Además los modelos manejan la capa lógica del negocio, o sea se encargan de cuidar la integridad de los datos a un nivel más abstracto y más fácil de programar que el de SQL En este capítulo abordaremos los modelos como un ORM, y en el capítulo 16 abordaremos el como cuidar y validar datos con los modelos.

Los modelos como mapas a los objetos (ORM) El modelo al ser un mapa del objeto nos permite manipular datos de la base de datos de forma simple, mientras la clase sirve para mapear la tabla, las instancias del modelo nos sirven para mapear filas. Veamos un ejemplo, para eso creemos el modelo Task en un proyecto nuevo.

1

rails g model task user:string

Obtendremos:

invoke

active_record

create

db/migrate/20151130040223_create_tasks.rb

create

app/models/task.rb

invoke

test_unit

create

test/models/task_test.rb

create

test/fixtures/tasks.yml

Al crear modelos se generan migraciones que nos permiten crear las tablas de forma automática en la base de datos, en el caso anterior se generó la migración db/migrate/20151130040223_create_tasks.rb , podemos correr esos cambios con:

1

rake db:migrate

Luegos gracias a esto obtendremos métodos de clase que nos permiten traer a memoria todos los tasks que hay en la base de datos, o, encontrar uno en específico, ya sea el primero, el último o por algún criterio a nuestra voluntad. Estos los podemos probar directamente en

1 2 3 4 5

rails console o dentro de nuestro proyecto rails .

Task.all #Obtiene todas las tareas en la base de datos Task.find(1) #Busca la tarea con id 1 Task.first #Devuelve el primer task de la base de datos Task.last #Devuelve el último task de la base de datos Task.where(user: "Gonzalo") #Busca todas las tareas cuyo usuario sea Gonzalo, es

No es sorpresa que en ninguna de las pruebas anteriores obtendremos resultados distinto de vacío, puesto que todavía no tenemos datos, par ahacerlo podemos generar instancias de los tasks para guardar tareas nuevas.

1 2

t = Task.new(user: "Gonzalo") t.save

O podemos crearlas directamente utilizando el método create

1

Task.create(user: "Gonzalo")

Para actualizar un dato de la base de datos tenemos que traerlo a memoria primero, luego podemos modificarlo y guardarlo.

1 2 3

t = Task.first t.name = "R2D2" t.save

Hay métodos que traen a memoria un objeto, en ese caso ese objeto será de ese tipo, como por ejemplo t.task será Task, pero los métodos que traen múltiples datos a memoria como .all, o .where nos devuelven un objeto del tipo ActiveRecord_Relation que no son un array pero se comportan como uno, en términos de que son iterables.

1

Task.all.each {|t| puts t.user}

Se debe tener cuidado de no confundir los métodos de instancia con los de clase, por ejemplo no tiene sentido obtener `Task.user` ¿de qué usuario estaríamos hablando? sin embargo si tiene sentido obtener un usuario de la tabla y preguntar su nombre.

La clave para evitar este error es entender quelos métodos de clase sirven para operar por sobre la tabla, y en cambio los métodos de instancia sirven para operar sobre una de las filas.

Creando modelos En rails cada vez que creamos un modelo se crea una migración que nos permite modificar la base de datos y que existe esa persistencia a nivel de base de datos cuando ingresamos, borramos o modificamos datos. Entonces ¿Para qué sirven los modelos? Para guardar datos y para asegurarnos que esos datos cumplan con reglas, y esas reglas las podamos programar en ruby y con toda la magia de rails en lugar de SQL Y ¿para qué sirven las migraciones? Para cambiar la estrucutra de la base de datos, particularmente sirven para crear, actualizar y borrar tablas, campos e índices.

Convención de nombres La convención en Rails es que los modelos se escriben en singular, de ahí el mismo rails lo pluraliza para escribir el nombre de la tabla en la base de datos.

por eso mismo no debemos escribir estos nombres en español puesto que las reglas no son las mismas y podemos causarnos problemas.

Creando un modelo vacío Podemos crear un modelo vacío, (sólo id, created_at , updated_at los modelos son en minúscula, con:

1

rails g model nombre_modelo

Creando un modelo con diversos campos Para crear el modelo con uno o más campos, pero debemos ocupar un nombre distinto

1

rails g model nombre_modelo2 campo1:tipo_de_dato campo2:tipo_de_dato

si el tipo_de_dato se omite se asumirá que es string. por ejemplo si creamos un modelo para guardar comentarios, obtendremos:

1 2 3 4 5 6

invoke create create invoke create create

active_record db/migrate/20151128090136_create_comments.rb app/models/comment.rb test_unit test/models/comment_test.rb test/fixtures/comments.yml

O sea, un archivo de migración, un archivo con el modelo y tests (los cuales cubriremos pronto en un próximo capítulo)

Podemos agregar todas las columnas que necesitemos a una tabla, hay tablas en empresas que tienen 50 columnas y no hay problemas con eso, pero tampoco se deben agregar datos innecesariamente ni mucho menos se debe caer en el error de tener columnas que repitan la información.

Ahora, dentro de los tipos de datos comunes que ocuparemos, los más freceuntes son: integer

float (decimales) boolean (true o false) string (hasta 255 chars) text (más de 255 chars)

No podemos tener dos modelos con el mismo nombre

Migraciones Una migración es un set de cambios para la base de datos, por ejemplo agregar una tabla, cambiar de nombre una tabla, agregar campos a las tablas, botarlas, etc. Las migraciones son clave para el desarrollo pues nos ayudan a ordenar el desarrollo de nuestra aplicación, la base de datos es el esqueleto de una aplicación web y las migraciones nos permiten generar un control de cambios bien fino y evitar errores por diversas versiones. Imaginemos el siguiente caso, dos personas, Pedro y Raúl están trabajando en una aplicación web, Pedro crea un campo nuevo para una tabla y crea el código para manejar ese campo, luego sube al repositorio los cambios, pero la base de datos está en su computador, por lo tanto sólo sube los cambios respectivos a lógica del manejo del campo y no notifica que agregó un campo en la base de datos, luego Raúl descarga los cambios de Pedro y la aplicación deja de funcionar. Las migraciones resuelven el tipo de problemas que tienen Pedro y Raúl, pues estas son parte del código y por lo mismo se agregan a los repositorios, gracias a las migraciones podemos compartir de forma sencilla las aplicaciones y con sólo rake db:migrate estar listos para empezar a trabajar.

El archivo schema.rb El secreto para entender las migraciones es el archivo db/schema.rb, el cual a esta altura luce así:

1 2 3 4 5 6 7 8

ActiveRecord::Schema.define(version: 20150819042819) do create_table "tasks", force: :cascade do |t| t.string "task" t.datetime "created_at", null: false t.datetime "updated_at", null: false t.string "user" end end

El schema contiene toda la información respecto al estado actual de la base de datos, la suma de todas las migraciones construye el schema, y la versión del schema, o sea el número que aparece corresponde

al nombre del archivo de la última migración. Rails sabe que hay migraciones no corridas con solo comparar el último archivo de las migraciones con el de la versión del schema.

Creando migraciones. Al crear modelos se crean migraciones, pero nosotros también podemos crear una migración nueva utilizando el generador de rails rails g migration nombre_migracion pero esto generará una migración vacía. Una migración vacía luce así:

1 2 3 4

class MigracionX < ActiveRecord::Migration def change end end

Dentro del método change nosotros podemos:

Agregar una columna 1

add_column :tabla, :columna, :tipo_de_dato

Por ejemplo podemos agregar el campo completed a la tabla task con:

1

add_column :tasks, :completed, :boolean

Remover una columna 1

remove_column :tabla, :columna

Por ejemplo podemos remover el campo completed a la tabla task con:

1

remove_column :tasks, :completed

Generadores mágicos Tanto para el añadir columnas como para removerlos existen autogeneradores, Si recuerdan bien ya los hemos ocupado previamente para agregar el campo usuario a task. La Lógica del autogenerador es la siguiente, dentro del bash:

1

rails g migration addXAndYAndZToTable x:string y:integer z:float

y el código anterior generará automáticamente:

1 2 3 4 5 6 7

class AddXAndYAndZToTask < def change add_column :tasks, :x, add_column :tasks, :y, add_column :tasks, :z, end end

ActiveRecord::Migration :string :integer :float

También existe generador mágico para borrar campos.

1

rails g migration removeXAndYFromTable x:string y:integer

Revirtiendo una migraciones El pasado no lo debemos modificar, pero podemos, por lo tanto debemos hacerlo con cuidado. Supongamos que Raúl realizó una migración pero esta tuvo algún error, ya sea por el tipo de dato, o por un error tipográfico y supognamos que se dio cuenta después de haber corrido el comando rake db:migrate si Raul todavía no ha compartido sus cambios a través de un push todavía está a tiempo de enmendar su error.

Enmendando un error. Como no podemos modificar el schema lo que tenemos que hacer es modificar una de las migraciones, pero siempre teniendo en mente que la suma de las migraciones debe dar el schema, y no pueden haber por ahí dos sumas distintas, o sea en todos los códigos las migraciones deben ser las mismas, por eso sólo vamos a enmendar los errores de esta forma cuando no hayamos compartido nuestros cambios. Pasos para enmendar el error.

1. Devolver la base de datos a una versión anterior con rake db:rollback esto el schema ahora apuntará a la versión anterior a la última 2. Modificar la migración y guardar los cambios 3. Correr rake db:migrate Si los cambios ya fueron enviados entonces lo que tenemos que haces es simplemente avanzar hacia adelante, o sea crear una nueva migración que remueva la columna mal hecha y que la cree de nuevo, de esta forma para aplicar los cambios sólo basta rake db:migrate.

Cuidado con los branches Cuando se está trabajando con sqlite3 en la versión de desarrollo no existen problemas con los branchs puesto que cada branch tiene su propia copia de la base de datos, pero cuando se ocupa postgreSQL u otro motor similar existen problemas como el siguiente. Imaginemos que Raúl ahora está trabajando en un proyecto con PostreSQL, va a implementar una funcionalidad nueva por lo que hace un branch del código, luego crea una migración y la corre modificando la base de datos, después se da cuenta que no le gustó como iba y vuelve al branch de desarrollo, pero al intentar trabajar se da cuenta que la base de datos no se ha devuelto a su forma original si no que está con los cambios implementados en el branch. Hay dos formas de resolver esta situación, volver al branch y hacer un rake db:rollback (o tantos como sea necesario) y volver al branch orginal o …

Botón de autodestrucción En el peor de los casos siempre se puede empezar de nuevo, esto quiere decir que podemos resetear la base de datos utilizando la siguiente reseta: 1. rake db:drop 2. rake db:create 3. rake db:migrate 4. rake db:seed Si quieres saber más sobre migraciones revisa la guía oficial de migraciones en Rails http://guides.rubyonrails.org/active_record_migrations.html

Es importante siempre respaldar la base de datos porque una vez que la botemos no la

podremos recuperar.

Ahora que ya entendemos lo básico de migraciones podemos volver al modelo y sus campos.

Destruir un modelo Para destruir un modelo podemos ocupar:

1

rails destroy model nombre_modelo

Agregando un campo extra. Una vez que hayamos creado un modelo no podemos volver a crear campos para agregar datos, desde el punto de vista de SQL no tendría sentido crear dos veces las misma tabla, habría que destruir una para luego crear la otra, por lo mismo podemos destruir el modelo pero si ya tiene código esto no tendría sentido, entonces lo que hacemos es agregar un campo extra ocupando el generador de rails. Hay dos opciones, con el helper que se crea la migracion automática o sin el que nos obliga a nosotros a escribir los comandos para crear las tablas, añadir los campos o hacer lo que queramos hacer.

Con helper

1

rails g migration addCampoToTabla campo:tipo

Por ejemplo:

1

rails g migration addNameToUser name:string

Sin helper

1

rails g migration nombreMigracion

y luego se debe modificar la migración generada.

Correr las migraciones

Todo cambio en el modelo a nivel de agregar columnas o cambiarlas o borrarlas, o crear tablas requiere de una migración, estos archivos se crearán sólo si seguimos las convenciones, o los podemos crear nosotros siguiendo las reglas, pero una vez que los archivos estén listos hay que dar el siguiente paso, que consiste en correr las migraciones. Todo hacia adelante

1

rake db:migrate

Revisar que la consola no muestre error. Una versión hacia atras:

1

rake db:rollback

Un número n de versiones hacia atrás

1

rake db:rollback STEP=n

Correr las migraciones hacia arriba o abajo a una versión específica.

1

rake db:migrate VERSION=20150306120002

El número de la versión lo podemos sacar de los nombres de los archivos dentro de la carpeta de migraciones.

Revisar las migración generada Todas las migraciones se encuentran dentro de la carpeta db/migrate , las migraciones están ordenadas por un número que es una fecha invertida por lo tanto las últimas siempre iran al final. Al correr el comando rake db:migrate se corren todas las migraciones y a partir de ellas se genera db/schema.rb , no se corran todas desde cero, el archivo schema contiene un número, ese número corresponde al de la última migración corrida, a partir de ahí rake db:migrate corre todo el resto de las migraciones y actualiza el archivo schema. Nunca debemos modificar el archivo schema directamente

Probar un modelo Una vez creado el modelo debemos probarlo como lo hicimos en capítulos previos.

1

rails c

Y luego dentro del archivo:

1

Modelo. Modelo .new

Es importante ocupar mayúscula y singular, esas son los reglas para referirse a una clase del tipo Active Record Si lo hicimos bien obtendremos una instancia del modelo este mostrará, id, created_at, updated_at y todos los otros campos que hayas agregado a la base de datos. En caso de que no haya sido generado obtendremos un error.

Creando una FK con índice. Si estamos ocupando postgreSQL u otro motor con soporte de índices sobre claves foraneas es posible de utilizar el generador de rails para crear el campo y el índice simultáneamente, esto se puede lograr con la palabra clave references

1 2

rails g model user rails g model company users:references

Veremos Ver emos que La migración obtenida incluye el índice.

1 2 3 4 5 6 7 8 9

class CreateCompanies < ActiveRecord ActiveRecord: ::Migration def change def change create_table :companies do |t| t.references :users :users, , index: true true, , foreign_key: true t.timestamps null: false end end end

Los índices generan dependencias, por ejemplo ya no podremos borrar un usuario sin borrar o reasignar la compañía que tiene antes

Getters y setters Para la siguiente sección vamos a crear un modelo user con nombre y un campo para saber si es administrador o no.

1

rails g model user name:string admin:boolean

1

u = User.create(name:"Gonzalo", admin:true)

Los modelos automáticamente crean métodos getter y setters para cada uno de los campos de nuestro objeto. Por ejemplo podemos obtener el nombre del usuario con u.name y el valor de si es administrador con u.admin en el caso de los valores booleanos se crea un método getter adicional con un signo de interrogación al final, entonces es lo mismo escribir u.admin que u.admin?

El archivo seed El archivo seed sirve para agregar datos de prueba a la base de datos de desarrollo (e incluso podría servir para poblar una base de datos de producción, como por ejemplo para agregar los administradores administradores y configuraciones inciales) Dentro del archivo seed vienen comentado dos ejemplos que se explican de forma bastante clara

1 2

#cities = City.create([{ name: 'Chicago' }, { name: 'Copenhagen' }]) #Mayor.create(name: 'Emanuel', city: cities.first)

El primero sirve para crear varias ciudades, el segundo para crear un Mayor para la primera ciudad (dependiendo de la versión de rails estos ejemplos pueden ser distintos). La idea es borrar esto y crear tus propios datos de prueba. Ejemplo:

1

Movie. Movie .create create([{name: ([{name:"El "El rey leon"}, leon"}, {name:"terminator" {name:"terminator"}]) }])

Dentro del seed es posible agregar ruby:

1 2

c = Category Category. .create create( ("Disney" "Disney") ) Movie. Movie .create create(name: (name: "El rey león 2", 2" , category: c)

Atributos virtuales virtuales Los atributos virutales son atributos que tienen los modelos pero no persisten en la base de datos (no se guardan), ¿para qué sirven entonces?, pueden tener distintos usos, desde almacenar una variable temporalmente, hasta servir para hacer un cálculo que no queremos guardar en la base de datos, para crear atributos virtuales sólo tenemos que crear variables de instancias en el modelo con sus respectivos getter y setters.

Preguntas 1. ¿Para qué sirven sirven los modelos? 2. ¿Qué es un ORM? ORM? 3. ¿Para qué sirven las migraciones? 4. Suponiendo que existe el modelo modelo User con con el atributo name name ¿Qué hace User.all? ¿Cómo puedo devolver al último de los usuarios guardados en la base de datos? ¿Cómo podemos develver todos los usuarios de nombre “Desafio”? ¿Cómo podemos cambiar todos los registros con el nombre “Desafio” por el nombre “Desafio 2”? 5. ¿De cuál clase clase heredan heredan los modelos en rails? 6. ¿Para qué sirve el archivo seed.rb? 7. ¿Qué son son los atributos virtuales? virtuales?

Ejercicio Crea el modelo icecream con el campo sabor (flavour) el cual es un string Corre las migraciones Crea 10 helados, al menos 3 deben de ser de sabores distintos, y dos de ellos debe ser de sabor a chocolate. Selecciona todos los helados de sabor a chocolate, deberían ser dos Crea el modelo provider con la columna name Agrega la columna columna e índice de FK provider_id provider_id a la tabla helados helados

Corre las migraciones Crea un proveedor llamado "Proveedor de helados 1" Modifica todos los helados existentes para que esten asociados al proveedor uno. (solo hay que cambiar la columna proveedor_id) haz un rollback Muestra todos los helados.

17) Reglas del negocio Objetivos 1. Utilizar el modelo para proteger la integridad de los datos 2. Aprender a validar campos del del modelo

Protegiendo la integridad de los datos En el capítulo de SQL vimos como agregando constraints podiamos proteger datos que cumplieran ciertas reglas, es posible de rails levantar una migración y crear constraints con un ALTER TABLE pero también es posible agregar las reglas a nivel de modelo. Dentro de los modelos podemos validar presencia de campos, que estos sean únicos, que sean mayores que otros, que la combinación de campos sea única, o que un producto no esté expirado o que una licitación esté hecha dentro de cierto rango de fechas, este tipo de reglas dependen específicamente de cada negocio.

Validando V alidando la presenci presencia a de un campo En el modelo respectivo, dentro de la clase:

1

validates :nombre_campo :nombre_campo, , presence: true

Un detalle importante si estamos trabajando en la consola los cambios en el modelo no se reflejan de forma inmediata, tenemos que salir y volver a entrar de rails console o utilizar el comando reload!

Validando V alidando que el campo sea único único En el modelo respectivo, dentro de la clase:

1

validates_uniqueness_of :nombre_campo

Validacione V alidaciones s custom Podemos validar un campo o conjunto de campos con las reglas del negocio que queramos, para eso hay que hacer dos cosas, la primera dentro de la clase debemos agregar un método validate acompañado de los métodos que queramos ejecutar, ejecutar, ejemplo

1 2 3 4 5 6 7

validate :metodo_custom def metodo_Custom def metodo_Custom if expiration_date.present if expiration_date.present? ? && && expiration_date expiration_date < Date Date.today .today errors.add( errors.add (:expiration_date :expiration_date, , "can't be in the past") past" ) end end

Valores V alores iniciales Hay dos formas de agregar valores iniciales a un modelo, una es a nivel de base de datos, para lograrlo tenemos que generar un migracion para agragar una columna con valor inicial o para modificar una columna y darle valor inicial. Ejemplos:

1 2

add_column :users, :notification_email, :boolean, :default => true change_column :player_states, :location, :integer, :default => 0

Callbacks La segunda forma es utilizando callbacks, los modelos permiten llamar automáticamente métodos en ciertos momentos, por ejemplo antes de guardarse, de esa forma podemos detectar si no hay valores ingresados y ponerlos nosotros. Para hacerlo ocuparemos el método before_save en el modelo respectivo.

1

before_save :metodo1 :metodo1, , metodo2

Estos métodos se llamaran en el orden establecido, o sea primero metodo1 y luego metodo2, pero para

que esto funcione debemos definir los métodos, ejemplo:

1 2 3

def metodo1 self.user = User.first end

Debemos tener mucho cuidado de nunca devolver false dentro de estos métodos pues en es caso rails asumirá que alguna validación falló y hará rollback del commit, o sea no se guardarán los datos.

Ejercicios Copiar todos los códigos a un archivo de texto Crear un proyecto nuevo de rails, con una configuración nueva de la base de datos Crear el modelo de posts (sin agregar los usuarios) Validar que el título del post este presente Crear 5 artículos desde la consola Crear una artículo sin título y observar el error obtenido Crear el modelo de usuarios Agregar una migración para agregar el usuario a los posts Modificar el modelo de post para validar que el usuario esté presente Crear un post sin usuarios para asegurarnos de que la validación esté funcionando Crear el modelo de comentarios Validar que el usuario esté presente Crear el usuario "Usuario por defecto" Cuando se cree un post sin usuario se debe asignar al usuario por defecto. Cuando se borre un usuario que sea dueño de posts se deben asignar todos esos post al usuario "usuario por defecto"

Preguntas 1. ¿Cómo podemos agregar una validación de presencia sobre un atributo del modelo? 2. ¿Cómo podemos agregar un método custom para validar un modelo? 3. ¿En qué archivo se muestra el estado actual de la base datos?

4. ¿Qué significan los números al lado de los archivos de migraciones? 5. ¿Cómo podemos agregar un campo nuevo a un modelo? 6. ¿Cómo podemos eliminar un campo de un modelo? 7. ¿Que consecuencias habrían de modificar el archivo schema directamente? 8. ¿Para qué sirve dar valores iniciales a un campo del modelo? 9. ¿Cuál es la diferencia de realizar este trabajo a nivel de base de datos y a nivel de modelo? 10. ¿Cómo se crea una migración para dar un valor incial en el modelo?

18) Relaciones entre modelos Objetivos 1. Utilizar el modelo para proteger la integridad de los datos 2. Graficar automáticamente los modelos de datos utilizando los modelos de rails

En SQL podemos relacionar dos tablas haciendo un select a múltiples tablas o haciendo un join, cuando lo hacemos estamos uniendo dos o más tablas en una resultante.

1

select * from posts, users where posts.post_id = users.id

En rails podemos hacer lo mismo al establecer relaciones, sin embargo debemos especificar el tipo de relación. Agregar relaciones en los modelos nos permite movernos de un objeto a sus objetos relacionados de forma sencilla, los modelos requieren que Por ejemplo si establecemos una relación de uno a muchos entre los posts y los comentarios podemos hacer lo siguiente:

1 2

@post = Post.first @post.comments

Establecer la relación en el modelo nos genera automáticamente métodos que nos permiten obtener los objetos relacionados de forma sencilla, en este capítulo estudiaremos esas asociaciones y sus ventajas.

Relaciones 1 a 1 Cuando existen relaciones 1 a 1 se dice que uno de los modelos tiene a otro, y el otro le pertence al primero. Si tenemos un usuario y una compañía semanticamente hace más sentido decir que la compañía le pertenece al usuario, y que el usuario tiene una compañia, debemos tratar de ocupar las relaciones siempre en el sentido semántico, si no se hace muy difícil programar si lo que se lee no tiene sentido en españo.

Entonces crearemos dos modelos usuario y compañia

1 2

rails g model user name:string rails g model company name:string user:references

Corremos las migraciones:

1

rake db:migrate

y ahora la parte nueva consiste en agregar las relaciones a los modelos. En el modelo user.rb agregaremos

1

has_one :company

En el modelo company.rb nos daremos cuenta que ya se encuentra la relación, esto se agregó automáticamente ya que rails lo dedujo a partir del user:references

1

belongs_to :user

Al igual que cuando agregamos los campos validadores en los modelos, al agregar referencias debemos reiniciar la consola, despues de hacer cambios en el modelo, lo podemos hacer ocupando el comando reload!

Debemos tener cuidado de por cual lado va la clave foránea y no invertir el orden por error, por eso siempre es bueno dibujar el diagrama

Si lo implementamos bien dentro de rails console podemos obtener un usuario a partir de la empresa y viceversa, de esta forma. Para probarlo, vamos a crear un usuario y una empresa

1 2

u = User.new(name:"Rick Hunter") c = Company.new(name:"SDF-1 Macross", user:u)

¿Qué fue lo que obtuvimos al hacer las relaciones? ganamos el obtener métodos getter automáticos para obtener objetos a partir del otro, ejemplo:

1 2 3 4

u.company => #

Borrando una relación en cascada. Podemos borrar campos en cascada, esto quiere decir que al borrar un usuario se borrará su compañía automáticamente, esto lo podemos hacer agregando dependent: :destroy en el modelo dentro de la relación.

1

has_one :company, dependent: :destroy

reiniciar la consola

Para probarlo esta vez si necesitamos guardar los datos, (si no están no tiene sentido borrarlos)

1 2 3

u = User.create(name:"Rick Hunter") c = Company.create(name:"SDF-1 Macross", user:u) u.destroy

Veremos que justo después de hacer el destroy obtendremos:

1 2 3 4 5 6

2.2.2 :004 > u.destroy (0.1ms) begin transaction SQL (0.2ms) DELETE FROM "companies" WHERE "companies"."id" = ? [["id", 1]] SQL (0.1ms) DELETE FROM "users" WHERE "users"."id" = ? [["id", 1]] (0.9ms) commit transaction => #
Donde del SQL claramente se distinguen dos borrados, primero el de la compañía asociada y luego el de el usuario que se intenta destruir.

Graficando las relaciones Existe una gema en rails que permite generar los diagramas de clases del modelo de datos.

Esta gema requiere de que tengamos instalado graphviz en nuestro computador, esto se puede lograr con: En OSX

1

brew install graphviz

En Ubuntu

1

sudo apt-get install graphviz

1

gem 'railroady', group: :development

y finalmente bundle. Luego podemos generar el diagrama de modelos corriendo la línea.

1

railroady -M | dot -Tsvg > doc/models.svg

O podemos generar todos los diagramas con la línea.

1

rake diagram:all

Los diagramas se guardan en la carpeta doc del proyecto rails. Ahora podemos diagramar al relación que creamos en el proyecto anterior.

Se necesita la base de datos para generar el documento, por lo mismo es necesario correr las migraciones antes del comando

User Models diagram Date: Nov 28 2015 - 02:15 Migration version: 20151128080750 Generated by RailRoady 1.3.1 http://railroady.prestonlee.com

id :integer name :string phone :string created_at :datetime updated_at :datetime

Company id :integer users_id :integer created_at :datetime updated_at :datetime

Relaciones de 1 a n Implementar relaciones 1 a n es muy similar a implementar relaciones 1 a 1, para probarlo vamos a crear un proyecto nuevo y crear dos modelos, películas y categorías, una categoría t iene muchas películas, una película le pertenece a una categorías

1 2

rails g model category name:string rails g model movie name:string category:references

luego

1

rake db:migrate

Una cosa es que en la base de datos existan las relaciones y otra muy distinto es que existan en el modelo, el modelo es una capa de abstracción por sobre los datos, por lo mismo al igual que en las relaciones 1 a 1 ahora debemos agregar las relaciones. para agregar las relaciones debes agregar belongs_to :category al modelo de películas y has_many :movies al modelo de categoría. en el modelo category.rb

1

has_many :movies

y luego abriremos el modelo de movies.rb para revisar si se creó la relación, debería aparecer:

1

belongs_to :category

Observar que el has_many viene acompañado con el nombre de la tabla en plural, y es por que son varias películas y no una, esta es una de las grandes razones porque debemos programar en inglés en lugar de en español, porque las reglas de inflección (para pasar de singular a plural) no son las mismas en ambos idiomas. Para probarlo tenemos que entrar a rails console y luego crear una categoría y una película.

1 2

c = Category.create(name: "Children and Family") m = Movie.create(name:"Hercules", category: c)

Al igual que en las relaciones 1 a 1 podemos hacer

1

m.category

Si observamos el diagrama veremos que es similar al de 1 a 1 pero en este caso vemos varias flechas para representar que la relación es de 1 a n.

Lo nuevo en este tipo de relación es que categoría no tiene una película, tiene muchas, por lo mismo el getter para obtener todas las películas es en plural.

1 2

c.movies #=> #
El método build Este método es parecido al new pero permite automaticamente un objeto hijo

1

m = c.movies.build(name:"Wall-E")

De esta forma automáticamente el objeto nuevo tiene como clave foránea la id del padre, debemos tener cuidado porque aún cuando el objeto no esté guardado en la base de datos si mostramos ahora todas las películas veremos esta nueva, para guardarlo en la base datos es el mismo proceso.

1

m.save

Múltiples relaciones de 1 a n Son muy pocas las aplicaciones que tengan unicamente una o dos tablas, una aplicación pequeña puede tener entre 5 y 10 y una grande puede t ener cientos, muchas veces existen relaciones entre varias de estas simultáneamente. En el caso típico de un blog tenemos usuario, comentarios y posts, ya estudiamos un posible modelo para esto en el capítulo 13, y era:

Generamos los tres modelos:

1 2 3

rails g model user name:string rails g model post content:text user:references rails g model comment content:text post:references user:references

Corremos las migraciones con modelos.

rake db:migrate agregamos las relaciones en los respectivos

En el modelo de usuario agregamos:

1 2

has_many :comments has_many :posts

En el modelo de posts:

1 2

has_many :comments belongs_to :user

En el modelo de comments:

1 2

belongs_to :user belongs_to :comment

Podemos rescatar los post de un usuario de la misma forma que hicimos previamente, pero para realizar las pruebas vamos a tener que agregar algunos datos, lo podemos hacer en el archivo seed.rb o directamente en la consola.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

u1 = User.create(name:"Usuario 1") u2 = User.create(name:"Usuario 2") u3 = User.create(name:"Usuario 3") p1 = Post.create(content:"Articulo 1 del usuario 1", user: u1) p2 = Post.create(content:"Articulo 2 del usuario 1", user: u1) p3 = Post.create(content:"Articulo 3 del usuario 1", user: u1) Comment.create(content:"Comentario del usuario 1 en el articulo 1", user: u1, po Comment.create(content:"Comentario del usuario 1 en el articulo 1", user: u1, po Comment.create(content:"Comentario del usuario 2 en el articulo 1", user: u2, po Comment.create(content:"Comentario del usuario 2 en el articulo 1", user: u2, po Comment.create(content:"Comentario del usuario 3 en el articulo 1", user: u3, po Comment.create(content:"Comentario del usuario 3 en el articulo 1", user: u3, po Comment.create(content:"Comentario del usuario 2 en el articulo 1", user: u2, po Comment.create(content:"Comentario del usuario 3 en el articulo 2", user: u3, po

Para ingresar los datos ahora debemos escribir rake db:seed

1 2

user = User.first user.posts

Tambien podemos obtener todos los comentarios con user.comments pero que pasa si lo que necesitamos es un poco más complejo, por ejemplo como podríamos obtener todos los comentarios que ha recibido en todos sus posts un usuario. Intuitivamente podríamos decir user.posts.comments pero sería un error, puesto que user.posts es un active record association, es como un array de posts y este no tiene un método .comments Podemos seleccionar primero todos los posts de ese usuario y luego buscar dentro de estos los comentarios.

1 2

comments = [] user.posts.each {|p| comments << p.comments }

El problema es que ahora comments es un array y no podemos realizar filtros sucesivos o utilizar otros métodos del activerecord Como solución podemos utilizar dos joins, o sea unimos la tabla de comments con la de post, y la de post con la de usuarios.

1

Comment.joins(:post => :user)

Esto se transforma en una consulta sql con:

1

SELECT "comments".* FROM "comments" INNER JOIN "posts" ON "posts"."id" = "commen

pero hay una forma mucho más sencilla, que es utilizando hasmanythrough

Has many :through Para llegar a una tercera tabla a través de una segunda podemos utilizar has_many :through en el modelo, la sintaxis es la siguiente

1

has_many :tabla_final, through: :tabla_intermedia

Ahora en el caso de nuestro modelo de usuarios ya tenemos una relación llamada comentarios, por lo que no podemos crear otra igual, pero en este caso podemos crear una relación con nombre, para eso especificamos el nombre de la relación y el destino, ya que no lo puede calcular sólo.

1

has_many :received_comments, through: :posts, source: :comments

Ahora si recargamos la consola, podemos utilizar user.received_comments y obtendremos todos los comentarios que ha recibido un usuario.

Relaciones n a n Existen dos formas de implementar relaciones de n a n en rails, la primera es ocupando el has_many :through, o sea dado que tenemos 3 modelos, donde uno de los

Preguntas 1. ¿Para qué sirve relacionar los modelos? 2. ¿Por qué es necesario agregar una columna en la base de datos para hacer la asociación? 3. ¿Cuál es la converción respecto a la columan de asociación? 4. ¿Cuál es la diferencia entre una relación de 1 a 1 y una de 1 a n? 5. ¿Cómo se puede agregar nombre a una relación? 6. ¿Para que sirve el método .build? 7. ¿Cómo se pueden borrar en cascada los elementos de una relación?

19) Testing unitario de modelos Objetivos 1. Entender el concepto de testing unitario 2. Aprender a correr tests automatizados 3. Mejorar la calidad de código 4. Entender como funcionan los fixtures

Los modelos son el esquelo de la aplicación y por lo tanto es muy importante que desarrollemos tests automatizados para probar nuestra lógica del negocio. En este capítulo aprenderemos a crear set de datos y correr pruebas para probar que nuestros modelos fallan y decimos que debemos probar que las cosas fallan, porque la lógica del testing nace del intentar hacer fallar algo. Si intentamos demostrar que algo funciona probablemente solo incluiremos algunas pruebas necesarias y no demostraremos que nuestro código es sólido y lo que es peor obviaremos aquellas que son más importantes y representan un riesgo para nuestra aplicación. Dentro de un proyecto rails todos los test se encuentran en la carpeta test de nuestra aplicación, dentro de ella encontraremos subcarpetas para distintos tipos de tests, en este capítulo utilizaremos sólo dos de ellas, models y fixtures los cuales sirven para hacer unit testing de los modelos. Los test corren en un entorno especial llamado testing y no comparten los datos con la base de datos de desarrollo o producción.

Los fixtures Los fixtures son los archivos con los datos que se cargaran en la base de datos en cada prueba. Cuando creamos un modelo se crea automáticamente un fixture para ese modelo, los fixtures están en formato yaml por lo que su identación es clave.

1 2 3 4 5 6 7 8 9

one: content: MyText post_id: user_id: two: content: MyText post_id: user_id:

Un secreto para no tener problemas con la identación es cuidar las tabulaciones, son críticas en YML, utilizar dos espacios, en lugar de tabs, esto requiere configurar el editor.

Por defecto los fixtures incluyen valores para todos los campos que fueron creados con el generador de rails al momento de generar el modelo, si los valores los agregamos después con una migración no aparecerán aquí, pero los podemos agregar manualmente. También hay que destacar que los fixtures no incluyen el campo id, pero podemos agregarlo, esto es especialmente útil a la hora de probar relaciones.

Estructura de un test de modelo Cada archivo de test viene ya con la estructura, la cual consiste en la clase que hereda de los TestCase y dentro de esta van todos los pruebas que definiremos para nuestro modelo.

Formas de escribir un test Hay dos formas de escribir los tests dentro de este archivo, la primera es creando métodos que empiezen con test_

1 2 3

def test_the_truth assert true end

La segunda es de la siguiente forma:

1 2 3

test "the truth" do assert true end

Esta última forma es la más utilizada puesto que es más clara, pero cualquiera de las dos sirve y cumple el mismo propósito

El método assert Los asserts que vimos en las líneas anteriores son afirmaciones, con un assert le estamos diciendo a ruby que una cosa tiene que ser de una forma y si no cumple, que nos avise. Entonces con estos asserts podemos hacer pruebas como determinar si un objeto con ciertos dados puede ser guardado con éxito en la base de datos. Cuando ejecutemos los tests obtendremos un reporte por cada assert que no haya cumplido. Un ejemplo práctico es evaluar si uno modelo se guardó o no

1

assert post.save?

Existen diversos tipos de asserts, estos vienen de la librería de minitest https://github.com/seattlerb/minitest Algunos de los más usados son:

Assertion

Purpose

assert( test, [msg] )

Asegura que el resultado sea verdad.

assert_not( test, [msg] )

Asegura que el resultado sea falso.

assert_equal( expected, actual, [msg] )

Asegura que el primer parámetro sea igual al segundo.

assert_not_equal( expected, actual, [msg] )

Asegura que el primer parámetro sea distinto al segundo.

assert_nil( obj, [msg] )

Asegura que el objeto sea nulo.

assert_not_nil( obj, [msg] )

Asegura que el obejto no sea nulo.

assert_empty( obj, [msg] )

Asegura que el objeto esté vacío.

assert_not_empty( obj, [msg] )

Asegura que el objeto no esté vacío.

assert_includes( collection, obj, [msg] )

Asegura que un objeto esté en una colección de datos.

assert_not_includes( collection, obj, [msg] )

Asegura que el objeto no esté en la colección de datos-

Cada test contiene uno de los assets vistos en la tabla o incluo más de uno, la lógica del testing unitario

es probar una sola cosa a la vez lo que suele traducirse a hacer sólo un assert por test pero esto no es estrictamente necesario, lo que si es importante es aislar los casos de pruebas, en los modelos se suele hacer un assert por método

Corriendo tests Todos estos tests se correran cuando ejecutemos el comando rake en la terminal dentro de la carpeta del proyecto, al correrlo en un proyecto nuevo (o donde no tengamos tests definidos, obtendremos:

1 2 3

# Running: Finished in 0.007509s, 0.0000 runs/s, 0.0000 assertions/s.

Cargando los fixtures en los tests Si tenemos un test del tipo:

1 2 3

test "probar que el usuario sea valido" do assert user.valid? end

¿de donde sacamos el valor de user?, la respuesta es de los fixtures, para poder utilizar un fixture en un test lo hacemos de la siguiente forma:

1 2 3 4

test "probar que el usuario sea valido" do user = users(:one) assert user.valid? end

El método setup permite crear un método comun para todos los otros que se carga antes que cualquier otra cosa, y sirve casi exclusivamente para cargar los fixtures, si todos los metodos cargan fixtures distintos no tiene sentido, pero en muchos casos un fixture se comparte en todos o casi todos los métodos, en ese caso es muy útil para evitar repetir código. El método setup va así:

1 2 3 4 5 6 7 8 9 10

require 'test_helper' class UserTest < ActiveSupport::TestCase def setup @user = users(:one) #cargamos el fixture end test "probar que el usuario sea valido" do assert @user.valid? end

En la línea 5 se ve que escribimos @user en lugar de user, debemos ocupar variables de instancias, si fueran locales no podriamos compartirlas entre los distintos métodos.

Preguntas 1. ¿Por qué los tests los debemos escribir con la lógica de fallar? 2. ¿Qué son los fixtures? 3. ¿En qué consisten los tests unitarios? 4. ¿En qué entorno corren los tests? 5. ¿Cómo utilizamos un fixture dentro de un test? 6. ¿Cómo podemos correr los tests? 7. ¿Cuál es la diferencia entre escribir `def test_insert` y test “insert” do? 8. ¿Qué significa assert? 9. ¿Cuántos assert pueden haber en un test? 10. ¿Para qué sirve el método valid? 11. ¿Cuál es la diferencia entre assert assert_equal? 12. ¿Cómo se corren los tests? 13. ¿Cómo se cargan los fixtures en un test? 14. ¿Para qué sirve el método setup en los tests? 15. ¿Por qué el método setup se ocupan variables de isntancias en lugar de locales?

20) Creando un Blog Construyendo el modelo En este capítulo y en los próximos construiremos un blog, por ahora utilizaremos como base el modelo que hemos generado en capítulos anteriores del blog para realizar los tests del modelo.

Entonces y a modo de repaso, construimos el proyecto desde cero.

1

rails new blog_with_testing --database=postgresql

Corremos rake db:migrate para crear el archivo schema y para probar si tenemos algún conflicto con la configuración de la base de datos

1

rake db:migrate

Luego creamos los modelos, por ahora todo campo que no sea un fk, será un string, esto nos ayudará a demostrar un test pronto.

1 2 3

rails g model user name email role rails g model post title content user:references rails g model comment content user:references post:references

Construyendo los tests Los test del modelo consisten principalmente en lógica del negocio, entonces necesitamos saber que vamos a validar antes de hacer los test Partiremos validando que un usuario no se pueda crear un usuario sin email

Test para modelo sin campo presente Para evitar errores de cualquier tipo primero tenemos que partir de fixtures válidos ya que estos se cargan directamente en la base de datos. Si vamos a crear una regla de negocio que valida la existencia de un email y luego creamos usuarios sin email vamos a tener problemas.

1 2 3 4 5 6 7 8 9

one: name: MyString email: MyString role: MyString two: name: MyString email: MyString role: MyString

La lógica de la validación de la existencia de un campo siempre es similar, utilizamos un fixture válido, anulamos el campo que debería ester presente, esperamos que eso sea inválido.

1 2 3 4 5 6 7 8 9 10

require 'test_helper' class UserTest < ActiveSupport::TestCase test "user should have an email" do user = users(:one) user.email = nil #decimos que no tiene email assert_not user.valid?, "el usuario no puede no tener email" end end

O, utilizando el método setup (es exactamente lo mismo):

1 2 3 4 5 6 7 8

def setup @user = users(:one) #cargamos el fixture end test "user should have an email" do @user.email = nil #decimos que no tiene email assert_not @user.valid? end

Al correr los tests con rake obtendremos:

1) Failure: UserTest#test_user_should_have_an_email [/Users/gonzalosanchez/Proyectos/clases/bo otcampv4/modelo/blog_with_testing/test/models/user_test.rb:10]: Expected true to be nil or false

Además a los métodos assert les podemos pasar un parámetro más con el mensaje.

1

assert_not user.valid?, "user must have an email"

De esta forma al correr los test obtendremos algo más específico .

UserTest#test_user_should_have_an_email [/Users/gonzalosanchez/Proyectos/clases/bo otcampv4/modelo/blog_with_testing/test/models/user_test.rb:10]: user must have an email

Ahora, nosotros hicimos un test que dice que un usuario no debería ser valido si el email es nulo, entonces al fallar nos está diciendo que hay usuarios con email nulo, por lo tanto nuestro código no lo está validando, y eso es obvio porque no lo hemos implementado. ¿Cómo lo arreglamos? Agregando una validación de presencia en el model de usuario al campo email, entonces en el modelo de usuario:

1

validates :email, presence: true

Si ahora corremos los tests veremos:

Running: . Finished in 0.071091s, 14.0665 runs/s, 14.0665 assertions/s.

Es normal que los test fallen, que fallen significa que una funcionalidad no está implementada o está mal implementada, y eso es genial porque nos permite encontrar problemas en nuestro código y además nos permite ordenar nuestro trabajo. A esta filosofía de testear primero y codear después se llama Test Driven Develpment o TDD

Test para modelo con campo único Ahora si se pide que el mail sea unico, ¿qué necesitamos? La respuesta es otro test

1 2 3 4 5

test "user cant have a duplicatd email" do u = User.new(email: @user.email) assert_not u.valid?, "user with email #{u.email} is repeated" repeated " end

¿Por qué en esta ocasión no ocupamos un fixture?, nuevamente, el secreto para sobrevivir al t esting es que todos los fixtures deben ser válidos porque estos se cargan directamente a la base de datos, y si uno de ellos parte rompiendo un regla ya tendremos probemas. Entonces como probamos que esté repetido?, creamos uno nuevo (no lo guardamos todavía) y verificamos si con los datos que tiene es válido.

Test para probar la relación Para probar una relación necesitamos dos fixtures, uno para cada elemento de la relación, hay varias formas de hacer esta prueba, lo que nosotros haremos es crear un usuario y un post, un usuario tiene muchos posts, por lo mismo podríamos preguntarnos si dentro de todos los posts del usuario se encuentra el fixture, para eso probaremos con el método assert_includes Entonces, primero agregamos el id del usuario al fixture de usuario

1 2 3 4 5 6 7 8 9 10 11

one: id: 1 name: MyString email: MyString role: MyString two: id: 2 name: MyString email: MyString role: MyString

Luego agregamos el id del usuario como user_id al fixture de post

1 2 3 4 5 6 7 8 9

one: title: MyString content: MyString user_id: 1 two: title: MyString content: MyString user_id: 2

Con estos datos estamos diciendo que en nuestra base de datos hay dos usuarios y dos post, y cada usuario tiene su post, ahora dentro del test veremos si el usuario one efectivamente tiene el post one. Luego creamos nuestro test.

1 2 3

test "user has posts" do assert_includes @user.posts, posts(:one), "user one should have post one" end

Al correr los test obtendres un error en lugar de un failure, los failures suceden cuando el assert no cumple la espectativa, los errores por diversos motivos, pero en este caso es porque el usuario no tiene el método posts

UserTest#test_user_has_posts: NoMethodError: undefined method `posts' for # test/models/user_test.rb:19:in `block in '

¿Cómo lo arreglamos?, agregando el método post a usuarios, por ahora lo haremos manualmente sin agregar la relación para demostrar el failure, y devolveremos un arreglo vacío ya que assert_includes espera como primer parámetro una colección de datos y un array vacío cumple con eso.

model user.rb

1 2 3 4 5 6 7 8

validates :email, presence: true validates :email, uniqueness: true def posts [] end end

Ahora al correr los tests obtendremos:

Expected [] to include #.

Claro, nosotros esperamos que el usuario tenga dentro del arreglo un post, y un arreglo vacío no tiene nada adentro, ahora borraremos el método posts y montaremos la relación para arreglarlo.

1 2 3 4 5

class User < ActiveRecord::Base validates :email, presence: true validates :email, uniqueness: true has_many :posts end

y voila, hemos pasado la prueba porque ahora si se incluye.

Running: ... Finished in 0.121981s, 24.5939 runs/s, 32.7919 assertions/s.

Test de pertenencia Ahora queremos hacer el test inverso, o sea asegurarnos que un post le pertenece a un usuario, si existe el método obtendremos o un usuario en caso de que haya o nil en caso de que no, y error en casa de que no exista el método, para eso dentro de los posts escribiremos el test.

1 2 3

test "post has user" do assert_not_nil posts(:one).user, "Post one should have a user" end

Test para diferencias de tiempo Validando que un post no se pueda actualizar después de 5 minutos. Primero haremos el test, para eso lo primero que necesitamos es revisar que el fixture de post incluye la fecha en que fue guardado, como nos interesa que no se pueda guardar después de 5 minutos crearemos 2, uno hace 6 minutos que no podemos actualizar y uno de hace 4 minutos que si podremos.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

require 'test_helper' class PostTest < ActiveSupport::TestCase # test "the truth" do # assert true # end test "cant update after 5 minutes" do @post = posts(:one) assert_not @post.valid? end test "can update before 5 minutes" do @post = posts(:two) assert @post.valid? end end

Al correr los tests veremos que sólo uno de ellos fala, esto se debe a que no existe ninguna validación, por lo que al intentar guardar el post después de 5 minutos funciona y no debería funcionar. Ahora tenemos que crear la validación, como no existe una para tiempos tendremos que crear una custom como aprendimos previamente en el libro. El modelo de post quedaría así:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class Post < ActiveRecord::Base belongs_to :user has_many :comments validate :time_limit def time_limit delta = Time.now - self.created_at if delta > 5.minutes errors.add(:expiration_date, "can't update") end end end

La diferencia de tiempos es simplemente al resta de cuanto tiempo ha pasado desde que se creó y si es mayor a 5 minutos

Desafios En un modelo de datos donde hay usuario y cada usuario puede tener hasta 6 fotos, se pide. Crear los modelos de usuario y fotos Crear las asociaciones Asegurar que el usuario tiene la relación con fotos Asegurar que el usuario puede tener un máximo de 6 fotos Asegurar que el modelo foto tenga la relación con usuario En un modelo de datos donde hay articulos, item pedido, orden de compra y usuarios, donde un una orden de compra se relaciones con muchos artículos y viceversa y una orden de compra le pertenece a un usuario. se pide: Crear el modelo de articulo, itempedido, ordencompra y usuario Establecer las relaciones acorde al enunciado. Asegurar que un ariculo no pueda estar en un pedido si tiene stock igual a cero Asegurar que un ariculo no puede ser pedido si tiene stock igual a cero Asegurar que la orden de compra tiene al menos un item pedido. Asegurar que el item_pedido le pertenesca a una orden de compra Asegurar que desde el modelo de usuario se pueda resctar las ordenes de compra. Asegurar que desde el modelo de usuario se pueda resctar los itemes pedidos Asegurar que desde el modelo de usuario puede rescatar los articulos a través de las respectivas relaciones

Preguntas 1. ¿Por qué es bueno que el archivo fixtures contenga únicamente fixtures válidos sea válido? 2. ¿Qué es TDD? 3. ¿Por qué para probar el test de email hicimos assert_not user.valid? en lugar de assert user.valid?, ¿no deberíamos revisar que fuera válido? 4. ¿Qué son los errores y cuales son la diferencia con los failures? 5. ¿Por qué en en el caso de la validación de la relación usuario -> posts obtuvimos un error en vez de un failure? ¿Qué se hizo para resolverlo?

21) MVC Ruby on Rails es un framework MVC, eso quiere decir que separa la programación en 3 capas lógicas importantes, modelo , vista y controlador, ya vimos superficialmente estas capas en los capítulos anteriores, en este vamos a aprender un poco más de ellas e integrarlas. Para empezar debemos entender el diagrama básico.

Un navegador se conecta a localhost:3000/ruta, lo que está sucediendo ahí es que el navegador se está conectando con el servidor que está corriendo localmente en nuestro computador, ese mismo que nosotros levamantos corriendo el comando rails s , es por eso que necesita estar andando para que podamos entrar a la página localhost:3000. Cuando el servidor de ruby on rails detecta una conexión, las cuáles desde ahora en adelante llamaremos request lo que hace es verificar el archivo de rutas, este le indica que controller debe resolver el request y con que método, dentro de este a veces se hacen llamados al modelo (y a veces no) y luego se mostra la vista. La ventaja de esta separación en tres capas es que hace fácil la revisión de un código de un tercero y coordinar tareas con el equipo de trabajo, como podemos ver en los siguientes ejemplos:

1. Si se necesita actualizar una vista en particular para un diseñador es fácil saber cual archivos es, se revisa la URL, luego se revisa a que controller y que método redirige y luego busca el archivo dentro de views con el mismo nombre dentro del método. 2. Si hay una falla dentro de una página que no carga, el primer responsable es el controller, si este no tiene nada fuera de la normal o está todo ok, revisamos el modelo y luego la vista. 3. Toda la lógica de negocios está en el modelo, si una regla del negocio sólo tendremos que actualizar este archivo, en caso de que agreguemos un campo o saquemos uno tendremos que revisar la vista pertintente pero sólo eso. En resúmen la arquitectura MVC hace fácil la coordinación de la construcción y la mantención de una aplicación web y es por eso que tan usada en la industria de desarrollo, tanto así que incluso se está ocupando para el desarrollo de apps no webs.

Arquitectura REST Rails es un framework MVC, pero hay otro concepto de desarrollo embebido en la lógica de la construcción de proyectos, y es el de REST. La idea de REST es definir recursos independientes para construir una aplicación, cada uno de estos recursos tiene 7 métodos primarios. 1. Index: Muestra todos los elementos de un recurso. 2. Show: Muestra el detaller de un recurso 3. New: Muestra el formulario para crear un nuevo recurso 4. Create : Maneja la lógica de la creación de un nuevo recurso 5. Edit: Muestra el formulario para editar un recurso 6. Update: Maneja la lógica para la actualización de un recurso 7. Delete: Borra un recurso específico. La forma más fácil de empezar a trabajar con REST en Rails es con el generador de sca !old.

Sca!old En rails existe una forma de crear todos los métodos rest para el recurso que queramos, es más el sca!old crea:

1. El modelo (y cada vez que se crea un modelo viene acompañado de la migración para crear la table en la base de datos) 2. El controller con los métodos REST 3. Las rutas para cada uno de los métodos REST. 4. Las vistas necesaria para cada uno de los métodos rest 5. Tests y fixtures básicos 6. Un archivo SCSS para ingresar sass (una variante de CSS) 7. Un archivo co!eescript (una variante de Javascript) 8. Un archivo de helper para delegar la lógica del controller Para probarlo creemos un proyecto nuevo, donde haremos una una lista de tareas.

1

rails g scaffold tasks task:string

Como resultado obtendremos:

invoke

active_record

create

db/migrate/20150815182842_create_tasks.rb

create

app/models/task.rb

invoke

test_unit

create

test/models/task_test.rb

create

test/fixtures/tasks.yml

invoke

resource_route

route

resources :tasks

invoke

scaffold_controller

create

app/controllers/tasks_controller.rb

invoke

erb

create

app/views/tasks

create

app/views/tasks/index.html.erb

create

app/views/tasks/edit.html.erb

create

app/views/tasks/show.html.erb

create

app/views/tasks/new.html.erb

create

app/views/tasks/_form.html.erb

invoke

test_unit

create

test/controllers/tasks_controller_test.rb

invoke

helper

create

app/helpers/tasks_helper.rb

invoke

test_unit

invoke

jbuilder

create

app/views/tasks/index.json.jbuilder

create

app/views/tasks/show.json.jbuilder

invoke

assets

invoke

coffee

create

app/assets/javascripts/tasks.coffee

invoke

scss

create invoke

app/assets/stylesheets/tasks.scss scss

create

app/assets/stylesheets/scaffolds.scss

El último archivo creado sca !olds.scss es una base para mostrar los errores de los formularios y otros detalles menores, si no es de tu agrado puedes borrarlo o modificarlo. ¿Cómo lo probamos? Primero tenemos que saber cuales son las rutas, eso lo podemos lograr con

rake routes

Prefix Verb tasks GET POST new_task GET edit_task GET task GET

URI Pattern

Controller#Action

/tasks(.:format)

tasks#index

/tasks(.:format)

tasks#create

/tasks/new(.:format)

tasks#new

/tasks/:id/edit(.:format) tasks#edit /tasks/:id(.:format)

tasks#show

PATCH

/tasks/:id(.:format)

tasks#update

PUT

/tasks/:id(.:format)

tasks#update

DELETE /tasks/:id(.:format)

tasks#destroy

Viendo las rutas descubrimos que para entrar al index de tasks tenemos que entrar a localhost:3000/tasks Y si no hemos realizado la migración obtendremos el siguiente error.

Esto se debe a que cada vez a que rails detecta que hay una migración que aún no ha sido corrida, pero resolverlo simplemente debemos correr el comando rake db:migrate en el terminal.

1

rake db:migrate

Si la migración es correcta, deberíamos obtener:

1 2 3 4

== 20150815182842 CreateTasks: migrating ====================================== -- create_table(:tasks) -> 0.0024s == 20150815182842 CreateTasks: migrated (0.0025s) =============================

Luego volvemos a entrar a la página web y podremos ver el index de task.

Desde ahí podemos ingresar tareas nuevas, ver el detalle de cada una, en la misma vista se provee un link para crear un task nuevo, si utilizamos el inspector de elementos o hacemos hover con el mouse sobre el link veremos que el link apunta hacia tasks/new.

Para saber exactamente que página es lo compararemos con el resultado de rake routes, de esta forma sabremos que task/new utiliza el controller tasks con el método new, entonces para saber que acción se realiza revisaremos el controller y método respectivo.

1 2 3 4 5 6 7 8

class TasksController < ApplicationController # GET /tasks/new def new @task = Task.new end end

Si observamos el método veremos que no hay mucha lógica, solo se crea un objeto task vacío que se ocupará para guardar el tasks Sin embargo en la vista app/views/tasks/new.html.erb nos encontraremos con sorpresas.

1 2 3 4 5

New Task
<%= render 'form' %> <%= link_to 'Back', tasks_path %>

Render es una instrucción que no habíamos visto en los controllers, pero no en las vistas aunque tiene el mismo propósito, cargar otro vista, cuando de una vista se carga otra se le denomina vista parcial, para

señalizar que un archivo es una vista parcial se utiliza como prefijo un _, como es el ejemplo del archivo app/views/tasks/_form.html.erb. Veamos el archivo generado.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<%= form_for(@task) do |f| %> <% if @task.errors.any? %>

<%= pluralize(@task.errors.count, "error") %> prohibited this task fro
<% @task.errors.full_messages.each do |message| %>
<%= message %>
<% end %>

<% end %>
<%= f.label :task %>
<%= f.text_field :task %>

<%= f.submit %>
<% end %>

Lo primero que vemos es el helper form_for , es similar al form_tag sólo que este es capaz de determinar las rutas para guardar o actualizar a partir de un objeto, en cambio en form_tag hay que especificarlas como lo hicimos en el capítulo previo. En caso de que al querer guardar un objeto haya un error lo mostraremos, de eso se encargan las líneas 2 a la 12. y entre las líneas 14 a 17 se crea el field task y de la 18 a la 20 el botón de envío. la ruta del formulario se calcula con el objeto, si el objeto task es nuevo apuntará al metodo create si es antiguo a update, revisemos el método create.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

# POST /tasks # POST /tasks.json def create @task = Task.new(task_params)

respond_to do |format| if @task.save format.html { redirect_to @task, notice: 'Task was successfully created.' format.json { render :show, status: :created, location: @task } else format.html { render :new } format.json { render json: @task.errors, status: :unprocessable_entity } end end end

El método create parte con algo muy interesante Task.new(task_params) esta es la clave para entender los form_for todos los datos del formulario se envían en un hash, esto lo podemos ver en los logs de rails server

Started POST "/tasks" for 127.0.0.1 at 2015-08-17 13:22:29 -0500 Processing by TasksController#create as HTML Parameters: {"utf8"=>"!", "authenticity_token"=>"PIaNf9h4CoHU/lxBWTSH3Kn9lY/LekE 6fmPH8uCu9B4FZfT0jSb8FGTeD7YfVkOtCdEC1sqTxZc1gxQfpffthQ==", "task"=>{"task"=>"Hell o !!"}, "commit"=>"Create Task"} (0.1ms)

begin transaction

SQL (0.2ms) ?, ?)

INSERT INTO "tasks" ("task", "created_at", "updated_at") VALUES (?,

[["task", "Hello !!"], ["created_at", "2015-08-17 18:22:29.437613"], ["upd

ated_at", "2015-08-17 18:22:29.437613"]] (0.8ms)

commit transaction

Redirected to http://localhost:3000/tasks/3 Completed 302 Found in 3ms (ActiveRecord: 1.1ms)

Los parameters son un hash, este hash ya lo hemos ocupado antes cuando dentro de un método del controller utiizábmaos render json: params en lugar da cargar una vista, lo que estamos haciendo ahí es mostrar el hash params. Dentro de este hash existe el key task (que corresponde al recurso) y que a su vez es un hash donde vienen todos los campos creados y modificados. Utilizando la misma idea del capítulo anterior podemos mostrar el hash en lugar de

1 2 3

def create render json: params end

Si queremos leer el hash dentro del controller lo podemos hacer utilizando params , por ejemplo para mostrar todos los campos pasados del formulario para ingresar una tarea lo podemos hacer con:

1 2 3

def create render json: params[:task] end

Entonces, ¿qué es el task_params creado en el sca !old? @task = Task.new(task_params) task_params es params[:task] pero limpiado, a este técnica de limpieza se le denomina Strong parameters

Strong parameters Veremos en las últimas líneas del task controller el siguiente código.

1 2 3 4

# Never trust parameters from the scary internet, only allow the white list thro def task_params params.require(:task).permit(:task) end

Ahí se define un método task_params, donde dice que del key task solo permiteremos un key dentro, en este caso se le llama task, pero si hubiese otro, por ejemplo el id de un usuario podríamos obtenerlo agregándolo a la lista.

1 2 3

def task_params params.require(:task).permit(:task, :user_id) end

Todo lo que no esté en esa lista será declarado un parámetro ilegal, y será borrado, ahora para probar esto agregaremos un campo nuevo a la base de datos, un nombre del responsable de la tarea. Como el modelo ya está creado no corresponde utilizar rails g model en su lugar crearemos una migración que agregue el campo a la base de datos. Esto se hace así:

1

rails g migration addUserToTask user:string

Si la migracion fue creada con éxito deberíamos obtener:

invoke create

active_record db/migrate/20150819042641_add_user_to_task.rb

Si abrimos el archivo creado, deberíamos ver lo siguiente

1 2 3 4 5

class AddUserToTask < ActiveRecord::Migration def change add_column :tasks, :user, :string end end

Si add_column no aparece probablemente se debe a que no alternaste la minúsculas y mayúsculas en addUserToTask correctamente, la notación utilizada es de lower camel case. Si el archivo es igual al mostrado entonces procedemos a correr la migración, ahí es cuando realmente se modifica la base de datos.

1

rake db:migrate


== 20150819042819 AddUserToTask: migrating =================================== = -- add_column(:tasks, :user, :string) -> 0.0015s == 20150819042819 AddUserToTask: migrated (0.0016s) ========================== =

Nota sobre las migraciones Las migraciones son el medio por el cual modificamos la base de datos, jamás deberíamos modificar la base de datos sin una migración, como queremos agregar usuarios responsables a la tarea haremos justo eso, crear una migración que agregue un usuario a la tarea, donde el usuario es un string. Discutiremos más profundamente el tema de las migraciones en un próximo capítulo, si te interesa tener más información puedes revisar la documantación oficial de migraciones

Probando los strong params Ahora tenemos un nuevo campo user, vamos a probar los strong params agregando el campo user al formulario pero sin agregarlo a los strong params. Para eso abriremos el archivo app/views/tasks/_form.html.erb y dentro agregaremos el nuevo field.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

<%= form_for(@task) do |f| %> <% if @task.errors.any? %>

<%= pluralize(@task.errors.count, "error") %> prohibited this task fro
<% @task.errors.full_messages.each do |message| %>
<%= message %>
<% end %>

<% end %>
<%= f.label :task %>
<%= f.text_field :task %>

<%= f.label :user %>
<%= f.text_field :user %>

<%= f.submit %>
<% end %>

Recargaremos la página y llenaremos el formulario.

Para probar si funcionó abriremos desde el bash la consola rails

1

rails c

Adentro buscaremos el último task para ver si fue ingresado correctamente.

1

Task.last

Task Load (0.7ms)

SELECT

"tasks".* FROM "tasks"

ORDER BY "tasks"."id" DES

C LIMIT 1 => # 2.2.2 :002 >

La razón del por qué user es nil, la podemos encontrar en los logs de rails server (en el tab secuestrado)

Started POST "/tasks" for 127.0.0.1 at 2015-08-18 23:43:40 -0500 Processing by TasksController#create as HTML Parameters: {"utf8"=>"!", "authenticity_token"=>"iGFUq2LShLo5NZV+Cjd5dmtnnz4 8MbSderUtyRDdAeCxgi0gN4xyL4kVxolMVb0Hy0sIZz3YMDAxVf4kVYQYew==", "task"=>{"task"=>" Tarea 1", "user"=>"Gonzalo"}, "commit"=>"Create Task"} Unpermitted parameter: user (0.2ms)

begin transaction

SQL (1.6ms) (?, ?, ?)

INSERT INTO "tasks" ("task", "created_at", "updated_at") VALUES

[["task", "Tarea 1"], ["created_at", "2015-08-19 04:43:40.411793"], ["

updated_at", "2015-08-19 04:43:40.411793"]] (0.8ms)

commit transaction

Redirected to http://localhost:3000/tasks/1 Completed 302 Found in 30ms (ActiveRecord: 2.6ms)

Podemos ver una línea que dice Unpermitted parameter: user, y la razón es sencilla, user no está dentro de los strong parameters, dentro del controller de tasks tendremos que agregar:

1

params.require(:task).permit(:task, :user)

y luego si podremos crear tasks con usuarios.

Preguntas 1. ¿Cuales son las ventajas de la separación de capas MVC en un apliación web? 2. ¿Cuál es la diferencia entre crear un sca !old y un controller? 3. ¿Cuáles son los 7 métodos de la arquitectura REST en Rails? 4. ¿Qué es una vista parcial? 5. ¿Cuál es la diferencia entre form\_for y form\_tag? 6. ¿Cuál es la diferencia entre task_params y params[:task] 7. ¿Para qué sirven los strong params?

22) El archivo de rutas a fondo Introducción al archivo de rutas El archivo routes.rb El archivo routes.rb que se encuentra dentro de la carpeta config contiene todas las URL que serán accesibles por los usuarios del sistema, si la URL no está especificada aquí entonces simplemente no será accesible. El archivo routes se encarga de mapear la ruta con un controller y un método dentro de ese controller, de esta forma cada URL corresponde a una acción que se encuentra definida dentro de un método de instancia del controller especificado. Entonces la página /controller_x/pages apuntará al método pages dentro del controller controller_x Es posible también que el nombre de la ruta no corresponda con el nombre del método, o omitir el nombre del controller, eso lo veremos más adelante. Otra cosa que puede hacer el archivo routes es pasar parámetros, los parámetros en la url son unas especies de variables, de esa forma el programador puedes especificar la página /controller_x/pag/20 y eso llamar al método pag asigando el valor 20 a una variable.

Rake routes rake es un programa de administración de tareas (parecido a ANT), por ejemplo rake db:mgirate para migrar la base de datos, en particular la tarea importante que utilizaremos respecto a las rutas es rake routes, esto nos mostrará todas las rutas existentes en el sistema. Veremos más detalles de Rake routes después de crear nuestra primera ruta sin parámetros.

Rutas sin parámetros El caso más común para crear rutas es el de sin parámetros, estas son útiles cuando queremos páginas estáticas o incluso cuando queremos obtener todos los elementos de un recurso, por ejemplo todos los post, otro caso útil por ejemplo es el perfil del usuario conectado actualmente, por otra parte obtener el perfil de un usuario específico requeriría el id de ese usuario. Las rutas sin parámetros pueden ser con controller (la forma más habitual) y sin el controller, no tiene ventajas omitir el controller pero hay personas que lo prefieren por estetica de la URL

Ruta con controller ejemplo: localhost:3000/controller\_x/about\_us Para crear una ruta especificando el controller debemos agregar al archivo routes una nueva dirección de la siguiente forma: get 'controller/accion' , como por ejemplos

1

get 'pages/about_us'

para probar que esto funcione en el terminal dentro del mismo proyecto escribiremos rake routes

Rake routes a fondo Después de digitar el siguiente comando en la consola

1

rake routes

Obtendremos lo siguiente: (Esto es un proyecto nuevo, si lo hacemos en otro probablemente obtendremos muchas más rutas)

Prefix

Verb

URI Pattern

pages_about_us

GET

/pages/about_us(.:format)

Controller#Action

pages#about_us

Pero, ¿Qué es cada columna?

Prefix: El prefijo El prefix muestra una variable que se creará para referirnos a esa página, es un prefijo porque hay dos sufijos posibles, que son _url y _path, el primero muestra la ruta absoluta y el segundo la ruta relativa. De esta forma si nosotros dentro de una vista de rails imprimimos <%= pages_about_us_url %> obtendremos la dirección a esa página.

Verb, el verbo Los request dentro de HTTP se hacen en conjunto con un verbo, en la mayoría de los casos este verbo es GET, pero también existen otros como, POST, PUT, PATCH, DELETE, etc.

El verbo depende del llamado que se haga, por ejemplo cuando nosotros ingresamos una url en el navegador automáticamente estamos haciendo un GET, pero cuando enviamos un formulario lo más probable es que estemos haciendo un POST. Ahora, para que una ruta sea válida tienen que suceder dos cosas, la primera es que la url tiene que estar habilitada, la segunda es que el verbo tiene que correponder a la url. En el caso anterior si intentamos hacer un POST a localhost:3000/pages/about_us entonces obtendremos que la ruta no existe, puesto que nuestra ruta habilitada es GET Ahora si dentro del archivo routes cambiamos el get por post, al hacer rake routes obtendremos:

Prefix

Verb

URI Pattern

pages_about_us

POST


Controller#Action

pages#about_us

URI pattern el URI pattern es la dirección URL en conjunto con el formato, ejemplo .html, .json, .xml, .js. Los controllers en RAILS por defecto responden a múltiples formatos pero es posible limitarlos a uno o sólo algunos.

URI Controller#Action finalmente la última columna indica quien es el controller y el método responsable cuando se carga una página web, esto es muy útil para debuggear errores pues nos indica en que parte del código esté probablemente el problema. Ahora que ya entendemos más sobre rake routes podemos proceder a ver aplicaicones interesantes del archivo routes.

El archivo routes a fondo ruta sin controller primero aclarar que una ruta sin controller no quiere decir que no exista un controller, es sólo que no aparece en la URL. por ejemplo: localhost:3000/about_us

Para obtener una ruta sin controller tenemos que especificar dentro del archivo routes cuál es el controller de la siguiente forma:

get 'about_us' => 'pages#about_us'

1

Luego con rake routes obtendremos lo siguiente:

Prefix

Verb

URI Pattern

about_us

GET

/about_us(.:format)

Controller#Action

pages#about_us

Claramente para que esta página funcione tiene que existir el controller pages con un método llamado about_us y la respectiva vista.

Cambiando el prefijo Es posible cambiar el prefix de una url utilizando el símbolo

1

:as cuando definimos la ruta, ejemplo:

get 'pages/about_us', as: "hola"

Al hacer rake routes nos dará como resultado:

Prefix

Verb

URI Pattern

hola

GET


Controller#Action

pages#about_us

No es conveniente cambiar el nombre del prefix arbitrariamente, pero en algunos casos rails no será capaz de distinguir el prefix de forma automática y en esos casos lo necesitaremos.

Crear una ruta con un parámetro Una ruta con parámetro se ve así:

localhost:3000/user/:id

Para crear una ruta con parámetros tenemos que hacer dos cosas, la primera es especificar que la ruta tiene un parámetro y nombrarlo, esto lo hacemos así: get 'user/:id' la segunda parte consiste en especificar el controller como lo hicimos previamente, ya que la ruta no tiene la misma estructura que antes del tipo controller/pages ahora hay que especificar el controller, uniendo quedaría así:

1

get 'user/:id' => 'users#profile'

al realizar rake routes nos daremos cuenta que en esta ocasión el prefix desapareció, como no sabía cuál era el controller y el método, menos aún tiene la capacidad de autodeterminar un prefijo, entonces recurrimos a especificarlo con el símbolo :as

Prefix

Verb

URI Pattern

profile

GET

/user/:id(.:format)

Controller#Action

users#profile

Dentro de las vistas y controllers de rails ahora debmeos pasar el parámetro id, esto es sencillo, en lugar de utilar profile_path utilizaremos profile_path(id: 5) Para utilizar este parámetro dentro del controller o dentro de una vista podemos utilizar el hash params de la siguiente forma

1

params[:id]

Luego este id lo podemos utilizar para buscar registros en nuestra base de datos o para cualquier función que estimemos conveniente.

Rutas anidadas Es posible anidar una ruta, o sea una subruta que depende de una ruta padre. Veamos un ejemplo para entenderlo mejor: Supongamos que tenemos una red social y queremos obtener todos los matches de un usuario en específico, pero la ruta user/:id ya la estamos ocupando para mostrar el perfil, podríamos crear otra que diga matches/:id pero luego matches también apuntaría al controller de user y eso ya empieza a causar confusión, entonces una forma de solucionarlo de forma que quede limpio es anidando la ruta para que resulte en user/:id/matches Esa ruta la podemos especificar así:

1

get 'user/:id/matches' => 'users#matches', as: "matches"

Crear una ruta que recibe dos parámetro Los parámetros dentro de las rutas tienen nombres, por ejemplo en el caso anterior estabamos

nombrando a la variable :id, pero ¿qué sucede si queremos utilizar una segundo parámetro, por ejemplo para ver el detalle del match de un usuario en específico. Eso lo podemos implementar de la siguiente forma:

1

get 'user/:user_id/match/:match_id' => 'match#show', as: 'match_show'

Las rutas anidadas y formularios anidados son muy útiles a la hora de construir aplicaciones, ahondaremos en más detalle en un próximo capítulo.

Query strings Los querys strings son los parámetros libres que recive una dirección, estos parámetros no se declaran en el archivo routes.rb, si no que los pasa el usuario cuando realiza un request. Todo lo que está a continuación del caracter ? en la url son query strings, seguramente los has visto cuando haces búsquedas en google. Entonces al pasar una ruta al navegador del tipo localhost:3000/users?sort=ok podemos rescatar tanto el valor ok simplemente utilizando params[:sort] desde el controller o desde la vista, en este caso nos devolvería ok ¿Para qué sirven los query strings? principalmente cuando una página puede realizar otras acciones, que no son críticas en los datos, como por ejemplo paginación, ordenamineto, etc o búsquedas como lo hace google.

Resources Hasta el momento hemos trabajado todas las rutas individualmente, pero hay forma de crear rutas REST de forma automática para un recurso, para eso basta con especificar dentro del archivo routes:

1

resources :nombre_recurso

Prefix

users

Verb

URI Pattern

Controller#Action

GET

/users(.:format)

users#index

POST

/users(.:format)

users#create

new_user

GET

/users/new(.:format)

users#new

edit_user

GET

/users/:id/edit(.:format)

users#edit

user

GET

/users/:id(.:format)

users#show

PATCH


users#update

PUT


users#update

DELETE


users#destroy

En este caso cuando el prefijo no sale mencionado es porque es el mimo que el anterior. Limitando las rutas con :only y :except Es posible además limitar las rutas rest generada utilizando los símbolo :only o :except, en el primer caso las rutas quedan limitadas a las específicadas, y en el segundo son todas menos las especificadas. Ejemplo:

1

resources :users, only: [:index, :create, :update]

Prefix

users

Verb

URI Pattern

Controller#Action

GET

/users(.:format)

users#index

POST

/users(.:format)

users#create

PATCH


users#update

PUT


users#update

member vs collection Además es posible agregar acciones extras manteniendo la estructura REST, para eso existen los members y los collections.

member

Los bloques member permiten agregar acciones a un elemento específico del recurso, por ejemplo a las rutas rest de user podríamos agregar el método profile de la siguiente forma:

1 2 3 4 5

resources :users, only: [:index, :create, :update] do member do get 'profile' end end

Fuera de las rutas de user que vimos previamente, obtendremos una nueva la de profile.

Prefix

Verb

URI Pattern

profile_user

GET

/users/:id/profile(.:format)

Controller#Action

users#profile

Los bloques member hacen más sencillo el agregar rutas nuevas sin tener que especificar con :as y establecer que controller y que método, pues es el método respectivo del recurso.

Collection Los bloques de collections son muy similares a los de members, pero con una diferencia, el collection no tiene un parámetro :id involucrado, pues se utiliza principalmente para generar una acción que involucra a todos los recursos, o a uno independiente del id. Por ejemplo crear un método para: borrar todos los posts, sería collection. obtener el perfil del usuario logeado, no depende del id de user y por lo tanto sería con collection. dar un acceso especial a un usuario específico sería member votar por un post sería member. (requiere del id del post) Los bloques collection se utilizan de la misma forma que los members

1 2 3 4 5

resources :users, only: [:index, :create, :update] do collection do get 'profile' end end

Obtendríamos:

Prefix

Verb

URI Pattern

profile_users

GET

/users/profile(.:format)

Controller#Action

users#profile

23) Rutas anidadadas y métodos REST anidados Introducción a rutas anidadas Las rutas anidadas son cuando ponemos una ruta dentro de otra, en el capítulo anterior lo explicamos brevemenete, en este lo veremos a fondo debido a que son una parte importante y compleja de rails. Para entender bien la idea detrás de las rutas anidadas debemos reapasar el propósito de la arquitectura REST, esta sirve para normalizar la manipulación de recursos, o sea utilizar las misma estructura de URL ya sea para verlos, crearlos, modificarlos o borrarlos. Si queremos manipular un recurso que depende de otro podemos inventar muchas rutas para manipularlo, o, podemos ocupar la arquitectura REST y poner este nuevo recurso anidado dentro del otro. De esta forma si tenemos comentarios que depende de posts los podemos anidar asi:

1 2 3

resources :posts do resources :comments end

Prefix

post_comments

Verb

URI Pattern

Controller#Action

GET

/posts/:post_id/comments(.:format)

comments#index

POST

/posts/:post_id/comments(.:format)

comments#create

new_post_comment

GET

/posts/:post_id/comments/new(.:format)

comments#new

edit_post_comment

GET

/posts/:post_id/comments/:id/edit(.:format)

comments#edit

post_comment

GET

/posts/:post_id/comments/:id(.:format)

comments#show

PATCH


comments#update

PUT


comments#update

DELETE


comments#destroy

GET

/posts(.:format)

posts#index

POST

/posts(.:format)

posts#create

new_post

GET

/posts/new(.:format)

posts#new

edit_post

GET

/posts/:id/edit(.:format)

posts#edit

post

GET

/posts/:id(.:format)

posts#show

PATCH


posts#update

PUT


posts#update

DELETE


posts#destroy

posts

Los bloques collection y member tamibén aplican a rutas anidadas, si hay que tener el cuidado de escoger el recurso completo, por ejemplo si quisieramos agregar un método para votar un post deberíamos escribir:

1 2 3 4 5 6

resources :posts do member do get 'vote' end resources :comments end

y si quisieramos crear uno para votar un comentario, deberíamos agregar:

1 2 3 4 5 6 7

resources :posts do resources :comments do member do get 'vote' end end end

Finalmente si queremos que ambos tengan un método para votos, simplemente combinamos ambos métodos.

1 2 3 4 5 6 7 8 9 10

resources :posts do member do get 'vote' end resources :comments do member do get 'vote' end end end

Prefix

Verb

URI Pattern

Controller#Action

vote_post

GET

/posts/:id/vote(.:format)

posts#vote

vote_post_comment

GET

/posts/:post_id/comments/:id/vote(.:format)

comments#vote

Es perfectamente posible cambiar los GET por POST.

Creando un sca!old anidado Vamos a suponer para este ejercicio que tenemos un modelo que tiene usuarios y tweets Un tweet le pertenece a un usuario y un usuario puede tener muchos tweets. En el caso de los usuarios lo podemos crear como sca !old o no, pero sólo vamos a utilizar el index y el show, ya que nos enfocaremos en el recurso anidado, el resto se vio en capítulos anteriores.

1 2

rails g scaffold user name:string rails g model tweet tweet:string user:references

Luego corremos las migraciones con rake db:migrate

Agregamos las relaciones en los modelos. Agregamos al menos un usuario desde la consola y creamos el controller de tweets. Antes de siqueira generar el método index para los tweets vamos a comenzar creando los tests.

Testeando una ruta anidada Para testear el acceso a la ruta index, podemos hacer:

1 2 3 4

test "should get index" do get :index assert_response :success end

Pero las rutas anidadas tienen una subruta adentro, o sea el index de los t weets depende de un usuario específico /users/2/tweets entonces debemos testear asi:

1 2 3 4

test "should get index" do get :index, user_id: 1 assert_response :success end

Para evitar errores también debemos agregar id: 1 dentro del fixture de users.

Ahora en ambos casos (aunque sólo el segundo es el correcto) obtendremos el siguiente error:

1) Error: TweetsControllerTest#test_should_get_index: ActionController::UrlGenerationError: No route matches {:action=>"index", :control ler=>"tweets"} test/controllers/tweets_controller_test.rb:8:in `block in '

Agregamos la ruta:

1 2 3

resources :users do resources :tweets end

Corremos los tests nuevamente, obviamente fallará, puesto que todavía no tenemos el método en el controller. Observemos el error:

1) Error: TweetsControllerTest#test_should_get_index: AbstractController::ActionNotFound: The action 'index' could not be found for Twee tsController test/controllers/tweets_controller_test.rb:8:in `block in '

Agreguemos el método index al tweet controller, y de paso agreguemos la vista para evitar errores que ya hemos estudiado.

1 2

def index end

No habríamos tenido que pasar por esto si hubiésemos creado el controller como rails g controller tweets index Si ahora corremos rake, veremos que ya todos los tests pasan, sin embargo si quitamos el user_id del test veremos que el test deja de funcionar.

1) Error: TweetsControllerTest#test_should_get_index: ActionController::UrlGenerationError: No route matches {:action=>"index", :control ler=>"tweets"} test/controllers/tweets_controller_test.rb:8:in `block in '

Esto se debe a que la ruta que nosotros creamos es anidada, por lo tanto debemos testear contra una ruta anidada.

Obteniendo y mostrando los resultados. En el controller bajo una ruta anidada normalmente generamos n objetos, uno par cada ruta padre y el objeto (u objetos) del mismo controller. Para que funcione tenemos que haber establecido las relaciones belongsto y hasmany en el modelo.

1 2 3 4

def index @user = User.find params[:user_id] @tweets = @user.tweets end

y luego dentro de la vista mostramos los tweets con:

1 2 3

<% @tweets.each do |t| %> <%= t.tweet %> <% end %>

Es necesario obtener el objeto user?, no, otra opción de hacer lo mismo sería.

1

@tweets = Tweet.where(user_id: params[:user_id])

Pero es limpio, elegante y después nos servirá para hacer los redireccionamientos, además debemos recordar que los controllers deben tener la menor cantidad de lógica posible, y esto incluye evitar hacer consultas a la base de datos directamente.

El detalle del tweet Partamos desde los tests:

1 2 3 4

test "should get show" do get :show, user_id: 1 assert_response :success end

la ruta ya está agregada, agreagmos todas las rutas REST, ahora en el controller agregamos el método show.

1 2 3

def show @tweet = Tweet.find(params[:id]) end

y finalmente lo mostramos en la vista, se deja de tarea para el lector.

Formulario para un nuevo tweet Partimos con el test:

1 2 3 4

test "should get new" do get :new, user_id: 1 assert_response :success end

Agregamos el método en el controller:

1 2 3 4

def new @user = User.find params[:user_id] @tweet = @user.tweets.build end

La forma que creamos el tweet en el paso anterior puede parecer rara, de hecho es muy común, y es lo mismo que @tweet = Tweet.new (bueno, casi lo mismo, en ciertas ocasiones, como cuando ocupemos relaciones polimórficas, veremos la útilidad de ocupar el build) ya tenemos el controller, veamos la vista:

1 2 3 4

<%= form_for [@user, @tweet] do |f| %> <%= f.text_area :tweet %> <%= f.submit :enviar %> <% end %>

Recordemos que form_for determina automáticamente las rutas para el objeto, pero en este caso las rutas de tweet están anidadas dentro de user, para lograr que form_for construya las rutas automáticamente con recursos anidados tenémos que pasarles los recursos en un arreglo. El orden de los parámetros del arreglos es el mismo que el de anidamiento, de afuera hacia dentro, o sea si es del tipo users/2/tweets el orden sería [@user, @tweet] El formulario no funcionará porque no tenemos el método create todavía.

Creando el método create Primero un test básico, simplemente para determinar si logramos crear el tweet o no, más adelante veremos el redireccionamiento.

1 2 3 4 5

test "should create tweet" do assert_difference('Tweet.count') do post :create, tweet: { tweet: "hola, soy un tweet" }, user_id: 1 end end

Como se observa el test se hace igual que otros de create, pero al igual que en todo lo anidado debemos especificar un user_id existente. Ahora creamos le método

def create @tweet = Tweet.new(tweet_params) @tweet.save render nothing: true end

1 2 3 4 5

y luego corremos el test.

Manejando el redireccionamiento del create. No existe un lugar específico a donde debamos redireccionar, depende de los requisitos de la plataforma, pero un lugar muy común, es al show del objeto padre, en este caso user.

1 2 3 4 5 6 7

test "should create tweet" do assert_difference('Tweet.count') do post :create, tweet: { tweet: "hola, soy un tweet"}, user_id: 1 end

assert_redirected_to user_path(users(:one)) end

y ahora tenemos que modificar el método create para lograr la redirección:

1 2 3 4 5 6 7

def create @user = User.find params[:user_id] @tweet = Tweet.new(tweet_params) @tweet.user = @user @tweet.save redirect_to @user end

las líneas 3 y 4 pueden ser sustituídas por:

1

@tweet = @user.tweets.build(tweet_params)

Se deja de tarea crear los métodos de edit y update que son iguales al de new y create. y el de delete que no presenta mayor dificultad que el show.

22) Relaciones n a n Tenemos una relación de n a n cuando un elemento de una t abla está relacionados con n elementos de la otra y viceversa. Ejemplo tags y películas

Una pelicúla x puede tener el tag acción, y el tag suspenso, y luego el tag suspenso puede a su vez ser de la película x y de la película y. En bases de datos relacionlaes no es posible modelar directamente una relación de muchos a muchos, pero si es posible hacerlo ocupando una tabla intermedia. La tabla intermedia guarda las referencias a las otras tablas.

Entonces siempre que queramos implementar una relación de muchos a muchos en bases de datos relacionales necesitaremos 3 tablas. Ahora para llevar esto a Rails hay dos formas: 1. Ocupando las relaciones has_and_belongs_to_many 2. Ocupando las relacions has_many :through La gran diferencia entre la primera y la segunda es que la primera no requiere de un modelo intermedio y la segunda si, ahora no confundir modelo con tabla, en ambos casos se requieren 3 tablas.

Implementando relaciones has_and_belongs_to_many Vamos a empezar con un proyecto nuevo, en el vamos a crear dos modelos, el de películas (movies) y el de los generos. Primero creamos los modelos.

1 2

rails g model movie title:string rails g model genre name:string

luego creamos la tabla intermedia, para eso podemos crear una migración y luego crear la tabla manualmente dentro o, podemos utilizar una ayuda de rails para crear la migración que cree la tabla automáticamente. para eso:

1

rails g migration CreateJoinTable movies genres

El archivo de migración generado debería contener algo así:

1 2 3 4 5 6 7 8

class CreateJoinTable < ActiveRecord::Migration def change create_join_table :movies, :genres do |t| # t.index [:movie_id, :genre_id] # t.index [:genre_id, :movie_id] end end end

Este archivo generado puede cambiar dependiendo de la versión de rails. Después de la migración, el schema debería contener:

1 2 3 4

create_table "movies_genres", id: false, force: :cascade do |t| t.integer "movie_id", null: false t.integer "genres_id", null: false end

En muchas ocaciones la tabla intermedia no tiene un id como clave primario, puesto que no es necesaria, además esta tabla nunca la accederemos directamente, siempre buscaremos por movie, o por genero.

Con las tablas hechas y los modelos creados ahora procedemos a establecer las relaciones.

1 2 3

class Genre < ActiveRecord::Base has_and_belongs_to_many :movies end

1 2 3

class Movie < ActiveRecord::Base has_and_belongs_to_many :genres end

Podemos probar las relaciones desde la consola de rails Movie.new.genres nos debería devolver un colección vacía, y Genre.new.movies también. Hagamos otra prueba para explicar como agregar generos a las películas.

1 2 3 4

m = Movie.new(title:"la pelicula de los muchas a muchos") g = Genre.new(name:"Acción") m.genres << g m.save


1 2 3 4 5 6 7 8 9 10 11 12 13

(1.7ms) begin transaction SQL (2.6ms) INSERT INTO "movies" ("name", "created_at", "updated_at") VALUES (?, ?, ?) [["title", "la pelicula de los muchas a muchos"], ["created_at", "2015-10-14 03:47:10.050114"], ["updated_at", "2015-10-14 03:47:10.050114"]] SQL (0.6ms) INSERT INTO "genres" ("name", "created_at", "updated_at") VALUES (?, ?, ?) [["name", "Acción"], ["created_at", "2015-10-14 03:47:10.093517"], ["updated_at", "2015-10-14 03:47:10.093517"]] SQL (0.5ms) INSERT INTO "movies_tags" ("movie_id", "genre_id") VALUES (?, ?) [["movie_id", 1], ["genre_id", 1]] (1.0ms) commit transaction

Observar que se generó una transacción donde se guardan tres cosas simultáneamente, la película, el genero, y la asociación. luego podemos rescatar los generos de esa película con m.genres

Borrando la asociación:

¿Cómo podemos borrar la asociación? Para borrar debemos tener el objeto que queremos borrar, por ejemplo

1 2 3

genre = Genre.first movie = Movie.first movie.genres.delete(genre)

Se debe tener el cuidado de no hacer movie.genres[0].delete, pues en ese caso se borraría el tag pero no la asociación, esto en SQLite es posible pero en PostgreSQL generaría un error.

Testeando la relación Cómo todo sucende dentro de una transacción podemos probarlo con un simple assert, también podríamos contar los resultados.

1 2 3 4 5 6

test "may have many genres" do 3.times do |i| @movie.genres << Genre.create(name: "Genero #{i}") end assert @movie.save end

Implementando relaciones con has_many :through Existe otra forma distinta de hacer relaciones de muchos a muchos y es con has_many :through, la implementación es distinta, pero el resultado es idéntico, con ciertas excepciones que discutiremos en esta sección. A continuación veremos como hacer la relación con has_many through usando el mismo ejemplo de películas y genero

1 2

rails g model movie title:string rails g model genre name:string

Y ahora crearemos un modelo que los una a los otros dos, con:

1

rails g model movie_genre movie:references genre:references

Corremos las migraciones con

rake db:migrate y procedemos a crear las relaciones:

Agregamos las relaciones a movie

1 2 3 4

class Movie < ActiveRecord::Base has_many :movie_genres has_many :genres, through: :movie_genres end

Revisamos las relaciones de movie_genre, (deberían haberse agregado solas gracias al generador de ruby)

1 2 3 4

class MovieGenre < ActiveRecord::Base belongs_to :movie belongs_to :genre end

Agregamos las relaciones a genre

1 2 3 4

class Genre < ActiveRecord::Base has_many :movie_genres has_many :movies, through: :movie_genres end

Entramos a rails c y procedemos a probar las relaciones: Desde usuario:

1 2

Movie.new.movie_genres # ó Movie.new.genres

Desde car:

1 2

Genre.new.movie_genres # ó Genre.new.movies

Al hacerlo obtendremos colecciones vacías, ya que una película nueva no tiene géneros y lo mismo en el orden inverso. Si en alguno de los casos obtenemos un error, hay que revisar los plurales en los modelos.

1 2 3 4

movie = Movie.new(name:"Avengers") genre = Genre.new(name:"Action") movie.genres << genre movie.save


1 2 3 4 5 6 7 8 9 10 11 12

(2.4ms) begin transaction SQL (4.2ms) INSERT INTO "movies" ("title", "created_at", "updated_at") VALUES (?, ?, ?) [["title", "Avengers"], ["created_at", "2015-10-14 04:55:41. ["updated_at", "2015-10-14 04:55:41.129110"]] SQL (0.5ms) INSERT INTO "genres" ("name", "created_at", "updated_at") VALUES (?, ?, ?) [["name", "Action"], ["created_at", "2015-10-14 04:55:41.159 ["updated_at", "2015-10-14 04:55:41.159226"]] SQL (1.6ms) INSERT INTO "movie_genres" ("movie_id", "genre_id", "created_at", VALUES (?, ?, ?, ?) [["movie_id", 1], ["genre_id", 1], ["created_at", "2015-1 ["updated_at", "2015-10-14 04:55:41.164011"]] (0.9ms) commit transaction => true

Se puede observar que la utilización es la misma y el resultado también, independiente del método utilizado, entonces ¿Cuándo conviene utilizar uno o el otro?

Has_many through vs Has_and_belongs_to_many EL principal motivo para utilizar has_many through es cuando se requiere agregar negocio al modelo intermedio, tanto en el caso de las películas como en el de los vehículos no había una necesidad real, pero imaginemos por un momento que quisiéramos manejar el porcentaje de películas pertenecientes a un genero o necesitar validaciones para esa tabla, entonces en ese caso ya convendría trabajar con has_many through.

Ejercicio practico de uso Aprovechando la relación creada anteriormente, con has_many :through, implementaremos la asignación de géneros a una película, para eso crearemos el formulario, método y ruta necesarios. Primero agregaremos películas y géneros a nuestra base de datos, para eso modificaremos nuestro archivo seed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

genres = [] genres genres genres genres genres genres genres genres genres genres

<< << << << << << << << << <<

Genre.create(name: Genre.create(name: Genre.create(name: Genre.create(name: Genre.create(name: Genre.create(name: Genre.create(name: Genre.create(name: Genre.create(name: Genre.create(name:

'Action') 'Comedy') 'ScyFy') 'Horror') 'Drama') 'Adventure') 'Thriller') 'Documental') 'Musical') 'Animated')

movies = [] (1..50).each do |m| movies << Movie.create(title: "Pelicula #{m}") end

Luego crearemos el método index y show de películas, para eso primero crearemos el controller con el método index y show desde el generador con:

1

rails g controller movies index show

Cambiaremos el archivo de rutas, las rutas generadas por:

1

resources :movies, only [:index, :show]

Luego dentro del método show del controller de movies, obtendremos la película y los generos, necesitamos ambas para crear nuestro formulario de accesos

1 2 3 4 5 6 7

class MoviesController < ApplicationController def show @movie = User.find params[:id] @genres = Genre.all @movie_genres = @movie.genres end end

y ahora creamos un formulario sencillo, que apunte a la misma página, para probarlo.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Generos
<%= form_tag @movie, method: :get do %> <% @genres.each do |genre| %> <% if @movie_genres.include? genre %> <% else %> <% end %> <% end %>

Genero Selecionar

<%= genre.name %> <%= check_box_tag 'genres_ids[]', genre.id, 'Yes' %>
<%= genre.name %> <%= check_box_tag 'genres_ids[]', genre.id %>

<%= submit_tag 'Guardar' %> <% end %>

El formulario se vería así:

Antes de avanzar analicemos el código del formulario, primero ponemos como ruta en el formulario la misma página show (después podemos crear una distinta, esto es para probar), y pasamos como método get para no tener que crear una ruta nueva

Luego dentro del body de la tabla iteramos sobre todos los géneros, por cada uno de ellos mostramos el nombre del genero y luego un checkbox. Preguntamos si el genero ya esta asignado a la película y si es así el checkbox se vera seleccionado (la opción 'Yes' ) y si no se mostrara normal. El checkbox por defecto recibe el nombre de un atributo, y eso nos permite pasar un campo como true o false. Aviso: cuando el checkbox no está marcado no se envía, que definitivamente no es lo mismo a que se envíe con el valor cero. Pero en este caso nosotros queremos pasar un grupo de géneros asociados a esta película, para eso ocupamos el arreglo.

<%= check_box_tag "genres_ids[]", genre.id %>

1

Cuando un elemento del arreglo esta marcado se agregará a la lista con su id respectivo. Al enviar el formulario obtendremos el siguiente output de rails server

Started GET "/movies/4?utf8=%E2%9C%93&genres_ids%5B%5D=3&genres_ids%5B%5D=6&genres _ids%5B%5D=9&commit=Guardar" for ::1 at 2015-10-14 01:43:01 -0500 Processing by MoviesController#show as HTML Parameters: {"utf8"=>"!", "genres_ids"=>["3", "6", "9"], "commit"=>"Guardar", "i d"=>"4"} User Load (0.1ms) 1

SELECT

"movies".* FROM "users" WHERE "movies"."id" = ? LIMIT

[["id", 4]]

Section Load (0.2ms)

SELECT "genres".* FROM "genres"

Rendered movies/show.html.erb within layouts/application (2.1ms) Completed 200 OK in 101ms (Views: 98.9ms | ActiveRecord: 0.4ms)

La parte más importante que tenemos que observar es la de parameters

1

Parameters: {"utf8"=>"!", "genres_ids"=>["3", "6", "9"], "commit"=>"Guardar", "i

Ahí vemos que efectivamente los ids están en un arreglo, ahora simplemente hay que buscar esos géneros y asignarlos a la película, pero para eso agregaremos una ruta nueva, set_genre Antes tenemos que preguntarnos en que controller tiene que ir este método. ¿En uno nuevo?, ¿En el de géneros?, ¿En el de las películas?, en este caso lo que queremos hacer es asignar géneros a una película por lo que tenemos que trabajar sobre el controller de películas, movies. Y no solo necesitamos una ruta que nos lleve al método, sino que también envíe el id de la película actual para poder trabajar en ella, para eso hacemos uso de una ruta de tipo member en movies

1 2 3 4 5

resources :movies do member do post 'set_genre' end end

Luego con rake routes veremos obtendremos lo siguiente:

1 2

Prefix Verb set_genre_movie POST

URI Pattern /movies/:id/set_genre(.:format)

Controller#Action movies#set_genre

Cambiamos nuestro formulario y lo dejamos como:

1

<%= form_tag set_genre_movie_path(@movie)%>

Tenemos que pasar la película (@movie) como opción a la ruta del formulario porque se tiene que enviar el id de esta. Ahora creamos el método en el controller donde procesaremos el formulario.

1 2 3 4 5 6 7 8 9 10

def set_genre if params.key?(:genres_ids) && !params[:genres_ids].empty? @genres = Genre.find(params[:genres_ids]) @movie.genres = @genres else @movie.genres.clear end

redirect_to @movie end

Lo primero que hacemos comprobar que el parámetro que vamos a usar, en este caso :genres_ids , existe y no esta vacío, después buscamos los géneros y las guardamos en un arreglo, y por ultimo le asignamos los géneros al usuario, en este paso se eliminan los géneros que ya se desmarcaron al usuario y se asignan las que se marcaron, en el caso de ya estar asignadas no hace nada. Si el parámetro no existe o esta vacío, borramos todas los géneros asignados a la película. y si probamos el formulario y observamos los resultados veremos dentro del POST

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Started POST "/users/4/give_access" for ::1 at 2015-10-14 01:57:10 -0500 Processing by UsersController#give_access as HTML Parameters: {"utf8"=>"!", "authenticity_token"=>"+VsY2A3FZZDJzELf==", "genros_ids"=>["4", "7"], "commit"=>"Guardar", "id"=>"4"} User Load (0.1ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 4]] Section Load (0.2ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" IN ( (1.5ms) begin transaction SQL (1.8ms) INSERT INTO "movie_genres" ("movie_id", "genre_id", "created_at", "updated_at") VALUES (?, ?, ?, ?) [["movie_id", 4], ["genre_id", 4], ["created_at", "2015-10-14 06:57:10.224260"], ["updated_at", "2015-10-14 06:57: SQL (0.1ms) INSERT INTO "movie_genres" ("movie_id", "genre_id", "created_at", "updated_at") ALUES (?, ?, ?, ?) [["movie_id", 4], ["genre_id", 7], ["created_at", "2015-10-14 06:57:10.238410"], ["updated_at", "2015-10-14 06:57: (0.7ms) commit transaction (0.0ms) begin transaction (0.1ms) commit transaction Redirected to http://localhost:3000/users/4 Completed 302 Found in 180ms (ActiveRecord: 4.8ms)

Lo ultimo que haremos sera crear una validación en el modelo moviegenres para que la combinación entre movieid y genre_id sea única y así evitar entradas duplicadas

1 2 3 4 5 6

class MovieGenre < ActiveRecord::Base belongs_to :movie belongs_to :genre validates :movie_id, uniqueness: { scope: :genre_id } end

Podemos complicarlo aún más, y crear un nuevo formulario dentro de index, pero aquí para dar acceso a todos los usuarios simultáneamente. para eso hacemos un método de controller sencillo:

1 2 3 4

def index @users = User.all @sections = Section.all end

y luego haremos nuestro primer intento de vista, para eso dentro de la vista views/users/index.html crearemos una tabla donde en la cabecera estén los usuarios y en el eje de las columnas la sección, la intersección de ambas será el acceso.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<% @users.each do |u| %> <% end %> <% @sections.each do |s| %> <% @users.each do |u| %> <% end %> <% end %>
Accesos

Sección <%= u.name %>

<%= s.name %> <%= u.name %>

Como resultado obtendremos lo siguiente:

Ahora el siguiente paso, cambiemos el nombre repetido en cada fila por un checkbox, ese checkbox deberá guardar información del usuario y de la sección.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

<%= form_tag users_path, method: :get %> <% @users.each do |u| %> <% end %> <% @sections.each do |s| %> <% @users.each do |u| %> <% end %>
Accesos

Sección <%= u.name %>

<%= s.name %> <%= check_box_tag "user_sections_ids[#{u.id}][#{s.id}]" %>

<%= submit_tag "enviar" %>

Se vería así:

Aquí todo es bastante parecido excepto 1 cosa, el checkbox, analicemos esto:

1

<%= check_box_tag "user_sections_ids[#{u.id}][#{s.id}]" %><

En el caso anterior teníamos un sólo usuario, y estabamos enviando las secciones asociadas a ese usuario dentro de un arreglo, ahora tenemos un arreglo de usuarios, dentro de cada uno de ellos hay un arreglo con las secciones. Al enviar el formulario veremos que los parámetros son:

1 2 3

Parameters: {"utf8"=>"!", "user_sections_ids"=>{"5"=>{"1"=>"1", "9"=>"1"}, "7"=>{"7"=>"1"}}, "commit"=>"enviar"}

O sea recibimos un hash con los usuarios que recibieron accesos, en este ejemplo aquellos con id 5 y 7 y cada uno de estos apunta un hash con las secciones a las cuales recibieron acceso, el 5 recibió acceso a la 1 y a la 8, el 7 sólo a la 1. Para procesar esto ocuparemos un método distinto, como es para todos los usuarios usaremos un bloque collection. el archivo de rutas quedaría:

1 2 3 4 5 6 7 8

resources :users do member do post 'give_access' end collection do post 'give_accesses' end end

y el nuevo prefix obtenido con rake routes sería: give_accesses_users, por lo que el formulario de index debería quedar:

1

<%= form_tag give_accesses_users_path %>

y finalmente hacemos el método give_accesses dentro del controller de usuarios:

1 2

def give_accesses end

Dentro del controller lo importante es primero rescatar los usuarios que reciben los permisos.

1 2 3 4 5 6 7 8 9 10 11

def give_accesses users_and_sections = params[:user_sections_id] users_and_sections.each do |u| # user_hash contiene el user_id y el hash con las secciones user = User.find(u[0]) sections = Section.find(u[1].keys) user.sections << sections user.save end redirect_to users_path end

24) Haciendo un cloudtag En este tutorial crearemos un cloudtag, o nube de tags con ruby on rails igual la que se ilustra en la foto, para eso ocuparemos el plugin de jqcloud. Para este ejercicio crearemos un proyecto nuevo:

1

rails new tagandposts

1 2 3

rails g model post title content:text rails g model tag tag rails g model tagpost tag:references post:references

Establecemos las relaciones dentro del modelo de tag

1 2 3 4

class Tag < ActiveRecord::Base has_many :tagposts has_many :posts, through: :tagposts end

Establecemos las relaciones dentro del modelo de post

1 2 3 4

class Post < ActiveRecord::Base has_many :tagposts has_many :tags, through: :tags end

Las relaciones dentro del modelo tagpost se crearon automáticamente, ya que utilizamos el generador de rails con references.

Creando datos para la nube de tags Luego crearemos algunos datos para nuestro proyecto Dentro del archivo seeds vamos a agregar algunos datos

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

p = Post.new(title:"Aprendiendo a programar", content:"Lorem Ipsum ...") p.tags << Tag.new(tag:"Programación") p.save p = Post.new(title:"Introducción a ruby on rails", content:"Lorem, ruby, rails") p.tags << Tag.new(tag:"Programación") p.tags << Tag.new(tag:"Ruby") p.tags << Tag.new(tag:"Rails") p.save p = Post.new(title:"el Patrón MVC", content:"MVC, y lorem ipsum") p.tags << Tag.new(tag:"Programación") p.tags << Tag.new(tag:"Ruby") p.tags << Tag.new(tag:"Rails") p.tags << Tag.new(tag:"MVC") p.save p = Post.new(title:"Aprendiendo rails con desafiolatam", content:"Bootcamps lore p.tags << Tag.new(tag:"Bootcamps") p.tags << Tag.new(tag:"Aprender") p.save p = Post.new(title:"Lógica para la programación", content:"Logica, tablas de lor p.tags << Tag.new(tag:"Lógica") p.tags << Tag.new(tag:"Programación") p.save

p = Post.new(title:"Escalando rails", content:"rails, tablas de lorem ipsum" ) p.tags << Tag.new(tag:"Optimización") p.tags << Tag.new(tag:"Rails") p.save

Luego descargamos el plugin de jQCloude desde https://github.com/mistic100/jQCloud y copiamos los archivos de jqcloud.css y jqcloud.js en las carpetas respectivas de assets.

Creando el controller y cargando los datos para hacer la nube de tags Ahora crearemos el controller

1

rails g controller tags index

Dentro del controller de tags agruparemos los tags por término y los contaremos.

1 2 3 4 5 6

class TagsController < ApplicationController def index tags = Tag.group(:tag).count @tags = tags.collect {|x,y| {text: x, weight: y}} end end

Creando la vista con la nube de tags luego en la vista mostraremos los resultados ocupando un pequeño script. Vista de tags#index

1 2 3 4 5 6 7 8 9 10 11

<script> tags = <%= (@tags.to_json.html_safe) %> console.log(tags) $('.keywords').jQCloud(tags, { width: 500, height: 350 });

25) Devise La autenticación es el proceso de validación de un usuario en un sistema, es perfectamente posible programar uno desde cero, pero como en la mayoría de los casos estos sistemas son exactamente iguales en todos los sitios ya existen sistemas muy completos y seguros que puedes incorporar en tu sitio. En Ruby on Rails el sistema de autenticación más famoso se llama Devise, y es el que aprenderemos a ocupar en este capítulo, razones para ocuparlo: 1. Soporte autenticación sobre múltiples modelos 2. Es seguro, encripta las claves automáticamente, no guarda las claves en texto plano. 3. Incorpora herramientas para validación del email (módulo confirmable) 4. Es combinable con otras soluciones como Login con FB, Twitter, Linkedin y todo lo que soporte OAUTH 5. Los tiempos de sessión son configurables

Empezando con devise Devise es bastante sencillo de implementar, primero agregamos la gema al gemfile.

1

gem 'devise'

1 2

bundle rails generate devise:install

Al correr el generador, rails nos mostrará el siguiente mensaje:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Some setup you must do manually if you haven't yet: 1. Ensure you have defined default url options in your environments files. Her is an example of default_url_options appropriate for a development environm in config/environments/development.rb: config.action_mailer.default_url_options = { host: 'localhost', port: 300 In production, :host should be set to the actual host of your application. 2. Ensure you have defined root_url to *something* in your config/routes.rb. For example: root to: "home#index" 3. Ensure you have flash messages in app/views/layouts/application.html.erb. For example:
<%= notice %>

<%= alert %>
4. If you are deploying on Heroku with Rails 3.2 only, you may want to set: config.assets.initialize_on_precompile = false On config/application.rb forcing your application to not access the DB or load models when precompiling your assets. 5. You can copy Devise views (for customization) to your app by running: rails g devise:views

Y ahora debemos cumplir con estos 5 puntos: El 1er punto es para poder enviar los emails, estos emails probablemente sean bloqueados por Gmail u otros sistemas de todas formas así que podemos omitirlo

por ahora. El segundo punto es para ingresar la página de inicio, esto es necesario para que devise pueda redirigirte cuando intentes entrar a una URL y no estas autenticado. El tercer punto es para mostrar los mensajes de que ingresaste con éxito o falló el ingreso da lo mismo cuál página se use, por lo mismo estos mensajes se ponen en la página maestra. El punto cuatro es exclusivo para Rails 3.2 y nosotros estamos trabajando con Rails 4, así que no nos compete. El último punto permite generar las vistas para login, actualizar contraseñas y muchas otras, si omitimos este paso igual se van a mostrar estas vistas pero nosotros no las podremos generar. correr rails g devise:views creará todos estas vistas:

invoke

Devise::Generators::SharedViewsGenerator

create

app/views/devise/shared

create

app/views/devise/shared/_links.html.erb

invoke

form_for

create

app/views/devise/confirmations

create

app/views/devise/confirmations/new.html.erb

create

app/views/devise/passwords

create

app/views/devise/passwords/edit.html.erb

create

app/views/devise/passwords/new.html.erb

create

app/views/devise/registrations

create

app/views/devise/registrations/edit.html.erb

create

app/views/devise/registrations/new.html.erb

create

app/views/devise/sessions

create

app/views/devise/sessions/new.html.erb

create

app/views/devise/unlocks

create

app/views/devise/unlocks/new.html.erb

invoke

erb

create

app/views/devise/mailer

create

app/views/devise/mailer/confirmation_instructions.html.erb

create

app/views/devise/mailer/reset_password_instructions.html.erb

create

app/views/devise/mailer/unlock_instructions.html.erb

Creando el modelo de devise Una vez con devise instalado tenemos dos opciones, la primera es agregarlo sobre un modelo existente, la segunda es crear un nuevo modelo deviseable.

¿Cuál opción escoger? Sólo depende de si ya tienes creado el modelo de tus usuarios o no, pero en ambos casos lo que tenemos que hacer es:

1

rails generate devise user

Es perfectamente posible cambiar el nombre de la tabla y utilizar admin, u otro nombre en lugar de user, pero es importante el nombre utilizado puesto que devise genera helpers en base a ese nombre, así que si lo cambias no olvides cuál nombre utilizaste. al correr el generador del modelo la consola mostrará lo siguiente:

invoke

active_record

create

db/migrate/20151015141123_devise_create_users.rb

create

app/models/user.rb

invoke

test_unit

create

test/models/user_test.rb

create

test/fixtures/users.yml

insert route

app/models/user.rb devise_for :users

En resumen: se generó una migración, el modelo de usuario, test para el modelos de usuarios, los fixtures para las pruebas y se agrega la ruta devise_for :users Ahora debes correr las migraciones puesto que devise crea la tabla si no existe o agrega los campos necesarios si no los tiene.

1

rake db:migrate

y con eso ya terminamos la configuración inicial, ahora para revisar el login y el formulario de registro debemos entrar a http://localhost:3000/users/sign_in

http://localhost:3000/users/sign_up

recordar que si cambiamos el modelo de user la ruta también debe reflejar el nombre del modelo utilizado en plurar.

Ingreso, registro y salida Las acciones claves de devise son: 1. Sign_in 2. Sign_up 3. Sign_out hay otras como cambiar el password, pero por ahora vamos a abordar las 3 rutas claves, ¿cómo podemos ver todas la acciones?, con rake routes , a continuación ingreso las tres rutas que nos permitiran que un usuario se registre, ingrese y luego cierre la sesión.

Prefix

Verb

Url

Controller#method

new_user_registration

GET

/users/sign_up(.:format)

devise/registrations#new

new_user_session

GET

/users/sign_in(.:format)

devise/sessions#new

destroy_user_session

DELETE

/users/sign_out(.:format)

devise/sessions#destroy

¿Cómo podemos dirigir al usuario al formulario de ingreso? fácil, agregamso un link a new_user_registration_path

1

<%= link_to "Ingresar", new_user_registration_path %>

Para dirigirlo al formulario de creación es igual, pero ocupamos la ruta.

1

<%= link_to "Registrar", new_user_registration_path %>

Para salir debemos ocupar la ruta respectiva, pero además debemos especificar el verbo delete

1

<%= link_to "Salir", destroy_user_session_path,

method: :delete %>

o en la forma de HTML

1 2 3 4

" data-method="delete"> Salir

login or logout Es muy común en un sitio web o aplicación web que no se muestre simultaneamente el link a ingresar y registrar y el link a salir simultáneamente, normalmente se muestra ingresar y registrar (si no has ingresado) y salir (si ya estas ingresado) Esto lo podemos lograr ocupando el helper user_signed_in? de devise y un un if y else de ruby.

1 2 3 4 5 6

<% if user_signed_in? %> <%= link_to "Salir", destroy_user_session_path, method: :delete %> <% else %> <%= link_to "Ingresar", new_user_registration_path %> <%= link_to "Registrar", new_user_registration_path %> <% end %>

El objeto current_user Cuando el usuario se registra o ingresa se inicia una sesión, las sesiones en rails son un hash que permite identificar al usuario y guardar junto con el información a nuestra voluntad. La session no queda guardada en la base de datos, si no en las cookies del navegador, la entidad de rails encargada de manejar las sesiones es el ActionDispatch::Session::CookieStore. Por que son importantes las sesiones en el contexto de devise?, porque sirven para guardar al usuario actual, ¿cómo lo hace? el método current_user busca si el usuario está en la sesión, si no lo encuentra lo busca en la base de datos. Gracias a esa definición, nosotros podemos mostrar información del usuario logeado, por ejemplo si quisieramos mostrar el email sería:

1

<%= current_user.email %>

El logout destruye el objeto current_user.

Modificando los formularios de ingresar y registro Para modificar los formularios lo primero que debemos hacer (sólo si no lo hicimos previamente) es generar la vistas,

1

rails g devise:views

Con las vistas generadas ahora podemos modificarlas utilizando HTML. Las vistas generadas se encuentran en: views/devise/ ahí encontraremos varias carpetas, el login está dentro de views/devise/sessions/new y el sign_up dentro de views/devise/registrations/new Dentro de estas vistas encontraremos un formulario que es ligeramente distinto a lo que hemos vistos

hasta ahora.

1

<%= form_for(resource, as: resource_name, url: registration_path(resource_name))

Este fomulario de devise es compatible con múltiples recursos simultaneamente, o sea podemos tener múltiples modelos de usuarios (obviamente con distintos nombres) y t odos con devise. Además la mayoría de las vistas de devise incluyen un render a la vista parcial de links

1

<%= render "devise/shared/links" %>

Agregando un dato al modelo de usuarios El primer paso ya lo hemos realizado previamente, consiste en generar una migración para agregar el dato, para probarlo agregaremos el campo nombre (name) para el usuario.

1 2

rails g migration addNameToUser name:string rake db:migrate

El segundo paso es agregar el campo al formulario

1 2 3 4

<%= f.label :name %>
<%= f.text_field :name, autofocus: true %>

Al recargar la página veremos el formulario de registro con el nombre pero si lo llenamos y lo enviamos veremos en nuestra base de datos que nuestro usuario no tiene nombre, si revisamos en el log de rails server veremos:

Parameters: {"utf8"=>"!", "user"=>{"name"=>"Gonzalo", "email"=>"gonzalo@desafiol atam.com", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}, "comm it"=>"Sign up"} Unpermitted parameter: name

¿Cómo podemos arreglar un problema de strong parameteres si no tenemos controller de usuario? Fácil, utilizaremos el super controller, o sea el application controller

1 2 3 4 5 6 7

before_action :configure_permitted_parameters, if: :devise_controller? protected def configure_permitted_parameters devise_parameter_sanitizer.for(:sign_up) << :name end

El callback nos permite llamar al método configure_permitted_parameters si estamos dentro del controller de devise, luego el método agrega el campo name a la lista de los parámetros sanitizados. Podriamos agregar un segundo separandolo con una coma. Después de este cambio podemos enviar el formulario de nuevo y

INSERT INTO "users" ("email", "encrypted\_password", "name", "created_at", "update d_at") VALUES (?, ?, ?, ?, ?) [["email", "[email protected]"], ["encrypted\_password", "$2a$10$k19SMlN60bX4NQXutV3CseToYC/I5TbHeb.6P26N6WzWi0ZXxKa5C"], ["name", "Gonzalo "], ["created_at", "2015-10-19 04:06:23.324424"], ["updated_at", "2015-10-19 04:06:23.324424"]]

Bloqueando el acceso Es muy común en un sitio web que un usuario no puede acceder a una página X hasta que ya se haya logeado, en Devise es posible lograrlo utilizando el callback before_action dentro de un controller que se desea bloquear.

1

before_action :authenticate_user!

Ahora supongamos que tenemos un controller llamado pages, cuyo único objetivo es mostrar dos páginas, una es home, la otra es secreto y queremos que la página secreto sea sólo para usuarios logeados.

1 2 3 4 5 6 7

class PagesController < ApplicationController def home end def secreto end end

Podríamos hacer:

1 2 3 4 5 6 7 8

class PagesController < ApplicationController before_action :authenticate_user! def home end def secreto end end

Pero de esta forma limitaríamos todas las páginas y no solo home, para evitar esto podemos agregar como parámetro al before_action los hashs :only o except de esta forma:

1 2 3 4 5 6 7 8

class PagesController < ApplicationController before_action :authenticate_user!, only: [:secreto] def home end def secreto end end

De esta forma sólo el método secreto de pages dependerá de que el usuario se haya logeado y si el usuario intenta entrar a http://localhost:3000/pages/secreto sin estar logeado será redirigido a la login. Antes de probarlo no te olvides de agregar las páginas al archivo routes.rb

1 2

get 'pages/home' get 'pages/secreto'

Cuando se crea un sistema de login con Devise todo funciona perfecto salido de la caja excepto el recuperar contraseñas, la razón es muy sencilla, esto se hace via email y para que rails pueda enviar un email necesita tener un sender (enviador) configurado, este modulo en rails 4 recibe el nombre de Action Mailer.

Configurando action_mailer para enviar correos con gmail para hacerlo basta abrir el archivo de configuración config/application.rb (también es posible ocupar un initializer) y agregar las siguientes líneas dentro del module y de class Application.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

config.action_mailer.default_url_options = { :host => 'localhost:3000' } config.action_mailer.delivery_method = :smtp config.action_mailer.perform_deliveries = true config.action_mailer.raise_delivery_errors = true config.action_mailer.default :charset => "utf-8" ActionMailer::Base.smtp_settings = { :address => "smtp.gmail.com", :port => 587, :authentication => :plain, :domain => 'gmail.com', :user_name => ENV['email'], :password => ENV['email_password'],º }

Donde dice ENV[‘email’] y password podemos cambiarlas por nuestras claves de email y al reiniciar la aplicación ya estaría funcionando pero hay un problema grande con hacer eso, estaríamos dejando las claves del correo electrónico dentro de nuestro código. Protegiendo las claves con dot-env Dot-env es una gema que nos permite agregar variables de entorno de forma sencilla a nuestra aplicación, para eso vamos agregar la siguiente gema al gemfile gem 'dotenv-rails'

Luego tenemos que crear un archivo .env (si, el punto es parte del nombre) dentro de la raíz de nuestro proyecto, en el vamos a agregar las variables de entorno.

1 2

[email protected] email_password=tuppassword

y ya con eso nuestra aplicación permite recuperar las contraseñas del usuario desde el sign_in. Evitando adjuntar el archivo .env por error al repositorio Ahora debemos de asegurarnos de no adjuntar este archivo por error cuando hagamos un commit, para eso vamos a abrir el archivo .gitignore (esto sólo aplica si están ocupando GIT) /.env

Configurando Heroku para que acepte las variables de entorno Si ocupas Heroku te estarás preguntando como pasar el archivo .env si no está en el repositorio, el secreto es que no se pasa, vamos a ocupar la terminal para dar los valores de las variables de entorno.

Entonces desde la terminal dentro de la carpeta del proyecto, escribimos:

1 2

heroku config:set [email protected] heroku config:set email_password=tupassword

y ahora si que si, tus claves están seguras y tu aplicación está funcionando con la opción de recuperar contraseñas.

26) Devise avanzado Ya hemos cubierto los tópicos básicos de devise, pero todavía hay varias funcionalidades interesante que veremos en este capítulo.

Agregando el rol de usuario Lejos una de las funcionalidades más utilizadas es la de múltiples roles, o sea existe un usuario que tiene acceso a ciertas páginas y otros usuarios que tienen acceso a otras. Para lograr esto tenemos que agregar un campo rol al usuario para poder distinguirlo y luego customizar nuestro propio authenticate_user!

Agregando el campo Podemos hacerlo de varias formas, con un string, con un integer o la mejor forma con un enum. Los strings son buenos para distinguir el rol pero dejas abierta la posibilidad que en algún momento se ingrese un rol no definido. Los integers puedes utilizarlo como 0 para admin, 1 para usuario, etc, y a pesar de que no caen en el problema anterior de crear un rol usuari en vez de usuario tienen el problema de que no es claro que hace cada número, te obliga a revisar la documentación y es un causa problema de errores.

Enums al rescate Los enums permiten combinar lo mejor de estos dos mundos, los strings y los integers. Para crear un enum agregaremos el rol del usuario como integer en la base de datos.

1 2

rails g migration addRoleToUser role:integer rake db:migrate

luego en el modelo especificaremos que role es un enum

1

enum role: [ :admin, :editor, :user]

Para revisar cambiar el status de un usuario tenemos métodos como

1 2

- .admin! (cambia el usuario al rol admin) - .admin? (devuelve true o false dependiendo de si el usuario es admin)

Por ejemplo queremos revisar si el usuario logeado es editor, entonces simplemente:

1

<% if current_user.editor? %>

Para cambiar al primer usuario de la base de datos y darle acceso de admin haríamos

1

User.last.admin!

El problema que tenemos ahora es que los usuarios que ya existen en la base de datos quedan con el campo role como nil y los nuevos usuarios también, a menos que le demos la opción de elegir el role que tendrán, lo que es una muy mala idea ya que el administrador del sitio debería ser quien asigne los roles en la aplicación. Lo que debiera pasar es que cualquier usuario nuevo se cree con un role estándar, en este caso el de user, para eso definiremos un valor por defecto al campo role y lo haremos a nivel de base de datos y de modelo. A nivel de base de datos: Primero creamos una migración vacía

1

rails g migration addDefaultRoleToUser

Luego modificamos la migración recién creada para dejarla así

1 2 3 4 5 6 7 8 9

class AddDefaultRoleToUser < ActiveRecord::Migration def up change_column :users, :role, :integer, default: 2, null: false end def down change_column :users, :role, :integer, default: nil end end

Y por ultimo ejecutamos la migración

1

rake db:migrate

Una vez corrida la migración todos los usuarios en la base de datos que tenían tendrán el role por defecto, en este caso 2.

role = nil ahora

Ahora setearemos el defaul a nivel de modelo, para eso en el modelo de usuario user.rb añadimos lo siguiente:

1 2 3 4 5 6 7

... before_save :default_role def default_role self.role ||= 2 end ...

Ahora que ya tenemos roles pasaremos a verificar los accesos, para eso vamos al applicationController y añadimos lo siguiente al final del archivo antes del ultimo end

1 2 3 4 5 6 7

private def check_admin! authenticate_user! unless current_user.admin? redirect_to root_path, alert: "No tienes acceso" end end

De esta manera el método check_admin! estará disponible en todos nuestros controladores. Luego en cada uno de los controladores donde queremos que el usuario logueado sea administrador agregamos lo siguiente.

1

before_action :check_admin!, only: :secreto

Esto es suficiente para sitios chicos donde hay que revisar 3 o 4 páginas contra uno o dos accesos, pero si escalamos de esta forma nos vamos a ver creando muchos métodos en cada controller para revisar los accesos, para evitar esto en le próximo capítulo estudiaremos la gema CanCanCan.

Testeando los accesos El testeo de los accesos es un t est funcional, o sea un test de los controllers.

Para testear con Devise primero debemos incluir el helper dentro de la clase del test

1

include Devise::TestHelpers

Luego creamo fixtures para los distintos tipos de usuario en el archivo

1 2 3 4 5 6 7 8 9 10 11 12 13 14

test/fixtures/user.yml

admin: id: 1 email: "[email protected]" role: 0 editor: id: 2 email: "[email protected]" role: 1 user: id: 3 email: "[email protected]" role: 2

y luego de vuelta en el controller definimos nuestros tests. Principalmente lo que vamos a testear en este punto es si un usuario tiene acceso a una página estando logeado o no, o si tiene acceso a el método dado el rol que tiene. Siempre tenemos que realizar los dos tipos de test, los positivos y los negativos, o sea que no pueda cuando no deba y que pueda cuando deba.

1 2 3 4

test "unlogged user can get home" do get :home assert_response :success end

y luego probamos nuestro primer test, debería pasar, ahora si obtenemos un error del tipo:

ActionView::Template::Error: undefined method àuthenticate' for nil:NilClass

Es porque no agregamos el helpers de devise para los tests.

include Devise::TestHelpers

Ahora creemos un test para revisar si un usuario logeado puede entrar a la página home

1 2 3 4 5 6

test "logged user can get home" do user = users(:user) sign_in(user) get :home assert_response :success end

Este test será más interesante, que pasa si un usuario no loggeado intenta entrar a una página que no puede.

1 2 3 4

test "logged user can't get secreto" do get :secreto assert_response :redirect end

Y como probamos que un usuario con un rol específico no tenga acceso, eso lo hacemos con:

1 2 3 4 5 6

test "user without privileges can't get secreto" do user = users(:user) sign_in(user) get :secreto assert_response :redirect end

Como mencionamos previamente no es suficiente probar que no tenga acceso, también hay que probar que la persona correcta si lo tiene. La gran ventaja de tener test para los tipos de acceso es que si en algún momento llegamos a romper algo por integrar una nueva funcionalidad podemos detectarlo sin tener que probar manualmente todas las páginas una a una. En resument testear accesos nos permite: Mejorar los tiempos de desarrollo Bajar los costos de desarrollo Implementar cambios y mejoras con menor costo. Y en el caso de pruebas de acceso, asegurarnos que la seguridad del sitio esté OK

Códigos completos:

Tests 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

require 'test_helper' class PagesControllerTest < ActionController::TestCase include Devise::TestHelpers test "unlogged user can get home" do get :home assert_response :success end test "logged user can get home" do user = users(:user) sign_in(user) get :home assert_response :success end test "logged user can't get secreto" do get :secreto assert_response :redirect end test "user without privileges can't get secreto" do user = users(:user) sign_in(user) get :secreto assert_response :redirect end test "admin can get secreto" do admin = users(:admin) sign_in(admin) get :secreto assert_response :success end end

Pages Controller

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class PagesController < ApplicationController before_action :check_user, only: :secreto def home end def secreto end private def check_user authenticate_user! unless current_user.admin? redirect_to root_path, alert: "No tienes acceso" end end end

Fixture de usuario 1 2 3 4 5 6 7 8 9 10 11 12 13 14

admin: id: 1 email: "[email protected]" role: 0 editor: id: 2 email: "[email protected]" role: 1 user: id: 3 email: "[email protected]" role: 2

Generando los controllers de devise Al igual que las vistas, los controllers pueden ser generados, y al generarlos tenemos un mejor control del como funcionan, ya sea por los strong params, o porque queremos realizar alguna acción como enviar un email al momento del registro. Para generar los controllers ocuparemos el generador de devise.

1

rails generate devise:controllers users

Al correr el generador observaremos que aparece un mensaje que dice lo siguiente:

1 2 3 4 5 6 7 8 9 10

Some setup you must do manually if you haven't yet: Ensure you have overridden routes for generated controllers in your routes.rb. For example: Rails.application.routes.draw do devise_for :users, controllers: { sessions: 'users/sessions' } end

Para lograr esto iremos al archivo de rutas y cambiaremos el devise_for :users por

1 2 3 4

devise_for :users, controllers: { sessions: 'users/sessions', registrations: 'users/registrations' }

En el archivo de rutas debemos especificar el remplazo de lo que queramos cambiar. Una vez corrido el generador veremos que se crean diversos archivos bajo la carpeta user dentro de controllers.

Los métodos expresados ahí dentro son sencillos, ya que user hereda de RegistrationsController todos

los métodos respectivos se reducen a hacer un llamado a super para llamar al método padre.

Cambiando la página despues de registrarse Nosotros vamos a descomentar el primer before_filter, o sea configure_sign_up_params

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

class Users::RegistrationsController < Devise::RegistrationsController before_filter :configure_sign_up_params, only: [:create] # before_filter :configure_account_update_params, only: [:update] # GET /resource/sign_up # def new # super # end # POST /resource # def create # super # end # GET /resource/edit # def edit # super # end # PUT /resource # def update # super # end # DELETE /resource # def destroy # super # end # # # # # # # #

GET /resource/cancel Forces the session data which is usually expired after sign in to be expired now. This is useful if the user wants to cancel oauth signing in/up in the middle of the process, removing all OAuth session data. def cancel super end

# protected # If you have extra params to permit, append them to the sanitizer. def configure_sign_up_params devise_parameter_sanitizer.for(:sign_up) << :name end

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

# If you have extra params to permit, append them to the sanitizer. # def configure_account_update_params # devise_parameter_sanitizer.for(:account_update) << :attribute # end # The path used after sign up. # def after_sign_up_path_for(resource) # super(resource) # end # The path used after sign up for inactive accounts. # def after_inactive_sign_up_path_for(resource) # super(resource) # end end

Cambiando la página después de ingresar En la última versión de devise en la que probamos esto no se genera el código de redireccion, pero eso no quiere decir que no se pueda agregar, para eso dentro del archivo controllers/users/sessions_controller.rb Agregaremos al final:

1 2 3 4

protected def after_sign_in_path_for(resource) destino_path end

Donde destino_path es un path válido.

Configurando action_mailer para enviar correos con gmail para hacerlo basta abrir el archivo de configuración config/application.rb (también es posible ocupar un initializer) y agregar las siguientes líneas dentro del module y de class Application.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

config.action_mailer.default_url_options = { :host => 'localhost:3000' } config.action_mailer.delivery_method = :smtp config.action_mailer.perform_deliveries = true config.action_mailer.raise_delivery_errors = true config.action_mailer.default :charset => "utf-8" ActionMailer::Base.smtp_settings = { :address => "smtp.gmail.com", :port => 587, :authentication => :plain, :domain => 'gmail.com', :user_name => ENV['email'], :password => ENV['email_password'], }

donde dice ENV[‘email’] y password podemos cambiarlas por nuestras claves de email y al reiniciar la aplicación ya estaría funcionando pero hay un problema grande con hacer eso, estaríamos dejando las claves del correo electrónico dentro de nuestro código.

Protegiendo las claves con dot-env Dot-env es una gema que nos permite agregar variables de entorno de forma sencilla a nuestra aplicación, para eso vamos agregar la siguiente gema al gemfile gem 'dotenv-rails'

luego tenemos que crear un archivo .env (si, el punto es parte del nombre) dentro de la raíz de nuestro proyecto, en el vamos a agregar las variables de entorno.

1 2

[email protected] email_password=tuppassword

y ya con eso nuestra aplicación permite recuperar las contraseñas del usuario desde el sign_in. Evitando adjuntar el archivo .env por error al repositorio Ahora debemos de asegurarnos de no adjuntar este archivo por error cuando hagamos un commit, para eso vamos a abrir el archivo .gitignore (esto sólo aplica si están ocupando GIT) /.env

Configurando Heroku para dot-env Configurando Heroku para que acepte las variables de entorno Si ocupas Heroku te estarás preguntando

como pasar el archivo .env si no está en el repositorio, el secreto es que no se pasa, vamos a ocupar la terminal para dar los valores de las variables de entorno. Entonces desde la terminal dentro de la carpeta del proyecto, escribimos:

1 2

heroku config:set [email protected] heroku config:set email_password=tupassword

y ahora si que si, tus claves están seguras y tu aplicación está funcionando con la opción de recuperar contraseñas.

Quiz ¿Para qué sirve el objeto current_user? ¿Donde se ingresan los strong parameters de un objeto deviseado? ¿Cómo podemos redireccionar a un usuario después de ingresar por devise? ¿Cómo podemos redireccionar a un usuario después de registrarse por devise?

27) Autorización con CanCanCan CanCanCan es una gema para el manejo de accesos de usuarios en un sitio, y juega muy bien en conjunto con Devise.

Hay que tener cuidado a la hora de trabajar con este gema de no confundirla con su versión anterior llamada CanCan

¿Cuándo no utilizar CanCanCan? Cuando es un sitio pequeño y sólo se busca controlar acceso entre uno o dos perfiles de usuarios distintos.

Instalando CanCanCan Para instalar la gema debemos abrir el gemfile y agregar la gema cancancan. luego corremos bundle y generamos el árbol de habilidades de cancancan con el generador de rails.

1

rails g cancan:ability

Si lo hicimos bien, obtendremos:

1

create

app/models/ability.rb

El árbol de habilidades El árbol de habilidades es el archivo donde se define que puede hacer y que no puede hacer cada usuario, este archivo se encuentra dentro de app/model/ability.rb y parte con un par de ejemplos comentados. CanCanCan espera que exista un método current_user en el controlador, por eso primero agregamos un sistema de autenticación como devise en primer lugar.

1 2 3 4 5 6 7 8 9

def initialize(user) # user es sacado del metodo current_user automaticamante po # Define abilities for the passed in user here. For example: user ||= User.new # guest user (not logged in) if user.admin? can :manage, :all else can :read, :all end end

La lógica que contiene es suficiente para partir, se entiende que si no hay un usuario logeado igual hay que pasar por el proceso de autenticación por lo mismo crear el objeto user en la línea 4, luego si es admin le da permiso para acceder a todo, pero si no sólo tiene permisos de lectura. El método can recibe dos parámetros, el primero es la acción (método) a la cual estamos estableciendo el permiso, y el segundo el recurso (Clase) en donde se puede ejecutar esa acción. Por ejemplo quisiéramos dar acceso completo al recurso películas a los editores, haríamos

1 2 3

if user.editor? can :manage, Movie end

por ejemplo quisiéramos dar acceso completo a todos los recursos a los editores, haríamos

1 2 3

if user.editor? can :manage, :all end

Si quisiéramos por ejemplo que un usuario solo tuviera acceso a ver el índice podríamos hacer:

1 2 3

if user.user? can :index, Movie end

Es posible asignar múltiples acciones simultáneamente con arrays, por ejemplo:

1 2 3

if user.user? can [:index, :show], [Movie, Review] end

El método :manage es un alias que se refiere a todas las acciones y el método para referirse a todos los recursos de la aplicación.

:all es un alias

Hay otros cuatro alias que usaremos constantemente para definir y chequear permisos y son: :read que es un alias para

:index y :show

:create que es un alias para

:new y :create

:update que es un alias para

:edit y :update

:destroy que es un alias para

:delete y :destroy

También es posible definir aliases propios siguiendo los principios de la guía oficial https://github.com/CanCanCommunity/cancancan/wiki/Action-Aliases, pero al menos que tengas muchos métodos no REST repetidos en cada controller no tiene sentido.

Revisión de habilidades Una vez que ya tenemos el árbol de habilidades, podemos empezar a ocupar el método can? para determinar cuando mostrar (o cuando no) un link o cierta información específica a un usuario dependiendo de su rol.

1 2 3

<% if can? :update, @movie %> <%= link_to "Edit", edit_movie_path(@movie) %> <% end %>

o es una línea

1

<%= link_to "Edit", edit_movie_path(@movie) if can? :update, @movie %>

Ocultar el contenido no siempre es suficiente, por ejemplo en el caso de un link no sólo nos interesa que la persona no pueda ver el link, también nos interesa que no logre entrar cambiando la url.

Bloqueo La forma de bloquear un recurso a un acceso no deseado es a través del controller, se especifica la acción loadandauthorize_resource.

1 2 3 4 5 6 7

class MoviesController < ApplicationController load_and_authorize_resource def show # @movie is already loaded and authorized end end

load_and_authorize_resource cambia algunas reglas del juego, por ejemplo ya no tenemos que cargar los recursos en los métodos clásicos para los métodos REST usando el callback before_action . ejemplo:

1 2 3

def index # @movies is already loaded and authorized end

En otros métodos si tenemos que cargarlos.

Manejo de conexiones no autorizadas El último paso consisten en especificar dentro del applicationController a que página redirigir en caso de que una persona intente acceder a una página a la que no está autorizada.

1 2 3 4 5

class ApplicationController < ActionController::Base rescue_from CanCan::AccessDenied do |exception| redirect_to root_url, alert: exception.message end end

Podemos cambiar el mensaje donde se define el

alert por uno personalizado.

Testeando las habilidades Es posible testear las habilidades en la consola, y es el primer lugar en el que deberíamos revisar si algo no funciona. El testing de una habilidad siempre tiene la siguiente forma: Seleccionamos un usuario y vemos si tiene acceso a un recurso.

1 2 3 4 5

user = User.first ability = Ability.new(user) ability.can?(:create, Movie) ability.can?(:edit, Movie) ability.can?(:destroy, Movie)

Habilidades basadas en la propiedad Es perfectamente posible limitar el acceso a un recurso a cualquier otra persona que no sea su dueño, por ejemplo supongamos que en un foro los editores pueden cambiar todo, pero un usuario solo puede editar o eliminar los post creador por el, este tipo de restricciones son bastante comunes y fáciles de implementar con cancancan En el árbol de habilidades se puede especificar el acceso en base a un campo del recurso, por ejemplo:

1

can [:update, :destroy], [Movie, Review], user_id: user.id

Testear este tipo de habilidades requiere especificar de quien es el objeto.

1

ability.can?(:destroy, Review.new(user: user))

Habilidades en recursos anidados Supongamos un caso donde hayan diversos grupos, y quieres que un usuario tenga acceso a todo dentro de un grupo, tendríamos un recurso grupo y anidado a un recurso movie, lo otro importante es que el usuario tenga guardado el group_id dado eso podemos limitar el acceso con:

1

can :index, Movie, {id: user.group_id}

Luego el recurso (en el controller) también hay que autorizarlo de una forma ligeramente distinta. El de group sería de la misma forma:

1

load_and_authorize_resource

pero el de Movie sería

1 2

load_and_authorize_resource :group load_and_authorize_resource :through => :group

Construir tests para este tipo de habilidades es igual que para otros tests de recursos anidados.

1 2 3 4 5

test "users can't access other groups sections" do sign_in users(:group1) get :index, {group_id: 2} assert_redirected_to root_path end

28) Polimorfismo En muchas ocasiones nos encontraremos con interacciones entre modelos que se repiten, por ejemplo: votos con post y votos con comentarios foto del post y del usuario tags de diferentes elementos likes a diferentes tablas como movie y review Para no tener que implementar las reglas del negocio para cada uno de los elementos y caer en el error de repetir código existe una técnica llamada polimorfismo que consiste en una interfaz que permite interactuar entre modelos que se comportan similar. La interfaz suena a algo muy complejo, pero realmente consiste en dos campos de la base de datos que permiten relacionar con el id del objeto y otro para guardar el tipo de objeto. La interfaz se agrega sobre el modelo común, por ejemplo si queremos implementar likes de usuarios sobre movies y sobre reviews la interfaz la haríamos sobre likes. Agregando la interfaz: Creando el modelo like desde cero:

1

rails g model like user:references likable:references{polymorphic}

Convirtiendo el modelo like a polimórfico si este ya existe

1

rails g migration addLikableToLike likable:references{polymorphic}

Esto generara la migración:

1 2 3 4 5

class AddLikeableToLike < ActiveRecord::Migration def change add_reference :likes, :likable, polymorphic: true, index: true end end

y ahora marcamos nuestro modelo de like como polimórfico y lo asociamos al usuario

1 2

belongs_to :user belongs_to :likable, polymorphic: true

Los modelos que interactúan con la interfaz deben saber que lo están haciendo, para eso agregaremos al modelo de movie y al de review la relación con

1 2

has_many :likes, as: :likable has_many :user_likes, through: :likes, source: :user

Y al modelo de user también agregamos la relación

1 2 3

has_many :likes has_many :movie_likes, through: :likes, source: :likable, source_type: ‘Movie’ has_many :review_likes, through: :likes, source: :likable, source_type: ‘Review’

Si queremos validar que un usuario pueda hacer like una sola vez a una movie o review, agregamos la siguiente validación en el modelo like:

1

validates :user_id, uniqueness: {scope: [:likable_id, :likable_type]}

Es necesario hacer la comprobación usando los tres campos ya que de otra manera si un usuario hace like a la movie con id 4 no podrá hacer like al review con id 4.

29) Subiendo archivos con carrirewave La gema carrierwave es una gema bastante sencilla de ocupar que permite la subida de archivos, exista otra gema que cumple el mimso propósito llamada paperclip, la configuración es distinta pero ambas hacen el trabajo.

Instalando carrierwave El branch master de la gema todavía es experimental, por lo que recomendamos ocupar la documentación del tag 0.10

Para instalar la gema agregaremos gem carrierwave al gemfile. Gemfile.rb ~~~ruby gem ‘carrierwave’ ~~~ luego bundle. El siguiente paso es generar un uploader, un uploader define una estrategia para subir archivos, si tenemos varios campos que requieran subir fotos, pero todas las fotos reciben el mismo tratamiento podemos reutilizar el uploader, pero si tenemos distintos tipos de archivos que subir y hay que tratarlos de forma distitna crearemos uno por estrategia.

Generando el uploader 1

rails generate uploader Avatar

Si revisamos el uploader generado, veremos algo como:

1 2 3

class AvatarUploader < CarrierWave::Uploader::Base storage :file end

storage file indica que el archivo se guardará dentro de la aplicación, dentro de la carpeta public, en el próximo capítulo estudiaremos como subir estos archivos a Amazon S3. Luego el último paso que nos falta es montar el uploader, para montarlo necesitamos tener un campo del tipo string para guardar el nombre del archivo. por ejemplo si tuvieramos un campo llamado photo dentro del modelo, entonces:

1

mount_uploader :photo, AvatarUploader

Probando desde rails console. Si tenemos un archivo en la raiz del proyecto podemos asignarsela a un objeto así.

1 2 3 4 5

post = Post.first File.open("nombre_archivo) do |f| post.photo = f end post.save

Creando una formulario con archivos En primer lugar para que un formulario pueda enviar archivos debe ser del tipo multiparte, podemos convertir a cualquier formulario en multiparte utilizando html: {:multipart => true} por ejemplo

1

= form_for @post, html: {:multipart => true} do |f|

luego dentro del formulario para agregar un campo que nos permite utilizar archivos debemos uitlizar

1

f.file_file :photo

30) Amazon S3 Amazon S3 es un sistema de almacenamiento de archivos, es bastante fácil de usar, lamentablemente no es gratuito pero si es muy barato. Hay dos formas de subir archivos, con fog y con carrierwave-aws, la ventaja de carrierwave-aws es que tiene menor footprint y debemos tener cuidado de no sobrecargar nuestra aplicación, sin embargo fuera de que la configuración dentro de un archivo es ligeramente distinta el resto de nuestra aplicación se mantiene intacto, sin importar cual de estas dos gemas utilicemos.

Configuración para la gema de carrierwave-aws 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

if Rails.env.test? CarrierWave.configure do |config| config.storage = :file config.enable_processing = false end else CarrierWave.configure do |config| config.storage = :aws config.aws_credentials = { :access_key_id => ENV['aws_access_key_id'], # required :secret_access_key => ENV['aws_secret_access_key'], # required :region => ENV['aws_region'], # optional, defa # :host => 's3.amazonaws.com' #:host => 's3.example.com', # optional, defa :endpoint => 'http://s3.amazonaws.com' # optional, defaults } config.aws_bucket = ENV['aws_dir'] # required config.aws_acl = 'public-read'

config.aws_attributes = { expires: 1.week.from_now.httpdate, cache_control: 'max-age=604800' }

end end

Separar los entornos no es necesario pero es útil, también es posible que en el entorno de desarrollo no utilizar amazon para no generar gastos innecesarios, pero de todoas formas deberíamos hacer una prueba con amazon localmente antes de subir los cambios. Los valores de aws_access_key_id, aws_secret_access_key, aws_region, aws_dir deben estar definidos dentro del archivo .env

IAM I AM es un sistema de permisos de Amazon basado en roles y polizas, su configuración es importante puesto que impide a una persona externa que obtiene tu clave de un servicio utilizarla para otros. Fuera de que no debemos agregar nuestra clave al código porque la hace vulnerable, además debemos configurar estas polizas para limitar el acceso a ámbitos específicos, en este caso nos interesa únicamente Amazon S3 el cual sirve para guardar y leer archivos Debemos crear un usuario, y agregar amazon s3 full access.

Agregando las claves de entorno a heroku 1 2 3 4

heroku heroku heroku heroku

config:set aws_access_key_id=tu_clave_de_acceso config:set aws_secret_access_key=tu_otra_clave_de_acceso config:set aws_region=region_de_s3 config:set aws_dir=nombre_del_bucket

Preguntas 1. ¿Para qué sirve amazon S3? 2. ¿Por qué en heroku no se pueden subir imágenes? 3. ¿Para qué sirve IAM? 4. ¿Por qué motivo debemos agregar las claves de entorno a heroku?

31) Optimización n+1 queries en ruby on rails El Active Record de Ruby on Rails tiene muchas cosas geniales, pero algunas de ellas si no las manejas bien pueden repercutir negativamente en el rendimiento de la aplicación. Uno de los errores más frecuentes de los desarrolladores novatos de rails es el problema de las N+1 queries. El problema sucede cuando intentando realizar una sola consulta a la base de datos pero esto gatilla internamente N+1 consultas, y aunque cuando uno tiene una base de datos con pocos datos el efecto es casi invisible, a medida de que crece el número de datos y el número de clientes este problema puede llegar a impactar de forma muy dura en el rendimiento de tu aplicación a tal punto de botarla.

¿Cuándo ocurre el problema de n+1 queries ? El problema ocurre cuando se itera sobre los hijos de uno de los objetos del modelo, para analizarlo sobre un caso práctica imaginemos que tenemos 2 modelos, uno de usuario y el otro de pins y cada usuario tiene muchos pins.

Modelo para el experimento Específicamente el problema se hace visible en la iteración de los resultados.

1 2 3 4 5

User.all.each do |u| u.pins.each do |p| puts p.name end end

El código que causa el problema es el siguiente:

Ahora cuando uno trabaja bajo un paradigma MVC es raro que uno tenga el código de esta forma, lo más probable es que el llamado a todos los usuarios se haga en la página index y luego dentro de la vista usuario se itere sobre los resultados mostrando por ejemplo los 5 mejores pins de cada usuario, pero el resultado es exactamente el mismo, n+1 llamados a la base de datos. Para este caso de pruebas se tienen 2 usuarios, Diego y Gonzalo y uno tiene 3 pins y el otro ninguno, y aquí podemos observar que que se hicieron dos queries a la base de datos en lugar de solo una.

Para solucionarlo en el mismo momento que hacemos el query debemos incluir a los hijos del modelo, en nuestro caso el query inicial debió haber sido.

1

User.all.includes(:pin)

De esta forma se hace una sola consulta a la base de datos, ahora repitamos el experimento anterior y comparemos resultados.

Y vemos que ahora solo hay una consulta.

32) Javascript, jQuery y Turbolinks El uso desparramado de javascript en una aplicación Rails se puede volver difícil de manejar muy rápidamente si no somos coherentes y ordenados. Lo que necesitamos son algunas técnicas y directrices que nos ayuden a mantener nuestro javascript organizado en nuestros proyectos. Tampoco queremos desactivar turbolinks porque, al no saber usarlo, nuestro javascript no se comporta como queremos. Muchas veces me encuentro con aplicaciones de Rails que tienen javascript por todas las vistas y en cualquier parte, mezclando estructura y comportamiento en el mismo archivo y cuando pregunto el por qué lo hicieron así o por qué pusieron ese javascript ahí, la respuesta suele ser que si dejaban el código en un archivo externo muchas veces el script no funcionaba o su comportamiento era errático, otras veces era porque no sabían donde debían ponerlo, etc … Esto es una muy mala practica ya que se hace difícil debuguear la aplicación, esteremos repitiendo código si tenemos un comportamiento que se repite en todas la paginas, la carga de javascript detiene la carga del HTML que resulta en paginas lentas que se sientes pesadas.

Como organizar nuestro javascript: Generalmente, podemos dividir los comportamientos de javascript en las siguientes categorías: Comportamiento del tipo "always on" Comportamiento que es provocado por el usuario A su vez estas pueden dividirse en: Comportamientos globales que están presentes a través de toda la aplicación. Comportamientos específicos para una o mas vistas, pero que no son necesarias en toda la aplicación. Los comportamientos globales deberían ser requeridos en el manifiesto para que de esa manera se carguen en toda la aplicación. Los comportamientos específicos NO deberían estar en el manifiesto y se deberían incluir en las vistas correspondientes sin olvidar de decirle a Rails que compile nuestros archivos (ver punto 2 paso 3). Otras veces tendremos comportamientos "always on" específicos para una vista en particular de un controlador. Para evitar tener que hacer un archivo distinto y usar el archivo javascript correspondiente al controlador podemos hacer lo siguiente: En nuestro /app/views/layouts/application.html.erb lo dejamos así:

modificamos la etiqueta y

1 2 3

<%= yield %>

Con esto nuestra etiqueta tendrá dos clases, una sera el nombre del controlador y la otra el nombre de la acción que llama a la vista. Por ejemplo, en una aplicación donde tenemos posts al acceder al detalle de un post nuestro quedaría así:

1 2 3 4 5

... resto del contenido ...

Una vez hecho lo anterior podremos tener un comportamiento especifico a una vista haciendo lo siguiente en nuestro archivo js:

1 2 3 4 5 6 7 8 9 10 11

$(document).ready(function() { function someBehavior() { ... comportamiento ... }; if ( $('.posts.show').length > 0 ) { someBehavior(); } })

Aquí lo importante es el if ( $('.posts.show').length > 0 ) que comprueba si existe algún elemento que contenga las clases posts y show, si existe ejecutamos la función someBehavior , si no existe no se ejecutará nada.

Turbolinks Muchos de nosotros nos hemos dado cuenta, y no de la mejor manera, que cuando Turbolinks está habilitado en nuestro proyecto (estado por defecto cuando creamos un proyecto), la función $(document).ready() tiene un comportamiento errático y nuestros js no se vuelven a ejecutar al cambiar de una pagina a otra y como consecuencia nuestro sitio no funciona como lo esperado. Esto sucede debido a como turbolinks maneja la carga de las paginas de nuestra aplicación. La función de turbolinks es hacer que nuestra aplicación se sienta mas rápida y fluida. En vez de dejar que el browser cargue y recompile los JavaScripts y CSS cada vez que nos cambiamos de pagina, turbolinks mantiene la pagina actual ‘viva’ y solo remplaza el contenido del o partes de el, y el titulo en el .

Esto quiere decir que no existe una recarga completa de la pagina, por lo que no podremos confiar en DOMContentLoaded o jQuery.ready() para ejecutar nuestro código. En su lugar turbolinks dispara eventos en el document que podremos usar para ejecutar nuestro código:

Evento

Descripción

page:beforechange

La pagina esta por cambiar.

page:fetch

Una nueva página está a punto de ser traída desde el servidor.

page:receive

Una página ha sido recibida desde el servidor, pero aún no analizada.

page:beforeunload

Los nodos están a punto de ser cambiados.

page:change

Nodos han cambiado. También se ejecuta en DOMContentLoaded.

page:update

Se ejecuta en page:change y ajaxSuccess de jQuery.

page:load

Un nuevo elemento body se ha cargado en el DOM. No se dispara en sustitución parcial o cuando una página se restaura desde la caché, a fin de no ejecutarse dos veces en el mismo body.

page:partialload

Nuevos elementos han sido cargados en el DOM a través de la sustitución parcial

page:restore

Un elemento body en caché se ha cargado en el DOM.

page:afterremove

Un elemento se ha eliminado del DOM.

Ejemplos de uso 1 2 3 4 5 6

$(document).on('page:fetch', function() { $(".loading-indicator").show(); }); $(document).on('page:change', function() { $(".loading-indicator").hide(); });

Como regla general, todos nuestros scripts asociados a un $(document).ready() deberían ser modificados para usar $(document).on('page:load') ó $(document).on('page:change') según sea necesario. Otra opción es hacer uso de la gema jQuery Turbolinks. En caso de querer hacer una carga completa al seguir un link –por ejemplo un link a una sección de

administrador que usa otro archivo de base (layout) que carga scripts que no se usan en las otras secciones– y así evitar tener problemas de que no se carguen estos nuevos scripts, podemos decirle a rails que no use turbolinks en ese links y así ejecutar una carga completa usando la opción data-no-turbolink . Ejemplo:

1

<%= link_to 'Admin', admin_path,

data: { no_turbolink: true } %>

Otra cosa importante para que nuestros javascript funcionen correctamente es el orden en el que los requerimos en el manifiesto, primero siempre jQuery, después las librerías externas, luego nuestros scripts y al final turbolinks para que sea el ultimo en instalar el manejador del evento click y así no interferir otros scripts.

1 2 3 4 5 6 7 8 9

// //= require jquery //= require jquery_ujs //= librerías externas //= nuestros scripts //= require turbolinks //

En caso de usar la gema jQuery.turbolinks , esta debe ir antes de jquery_ujs, para que pueda 'secuestrar' la llamada a (document ). ready()‘o‘ (function() { … })`

1 2 3 4 5 6 7 8 9 10

// //= require jquery //= require jquery.turbolinks //= require jquery_ujs //= librerías externas //= nuestros scripts //= require turbolinks //

33) Manejo de gráficos Hay diversas gemas para manejar gráficos, usualmente la parte de gráficos es un javascript donde se ponen los datos, la parte compleja es recuperar los datos específicos que necesitamos para nuestra aplicación, en este capítulo veremos como recuperar diversos tipos de datos para generar gráficos de

barra y de tipo pie. Vamos a necesitar agregar las siguientes gemas para hacer los gráficos

1 2

gem "chartkick" gem 'groupdate'

Para este capítulo vamos a construir un proyecto para administrar un fundacion donde tenemos donantes y donaciones.

1 2

rails g model donor rails g scaffold donations

Haciendo los queries 1 2 3 4 5 6 7

@donations = Donation.where(user_id: current_user.id) unless params[:company_filter].blank? @donations = @donations.eager_load(:donor).where("donors.company = ?", params[: end @donations_by_company = @donations.eager_load(:donor).group("donors.company").su @donation_by_day = @donations.group_by_day("donations.created_at" ).sum(:amount)

Generando los gráficos 1 2 3 4 5

<%= javascript_include_tag "//www.google.com/jsapi", "chartkick" %> <%= line_chart @donation_by_day %> <%= pie_chart @donations_by_company %>

34) Fullcalendar Creando un calendario de eventos, para este ejemplo vamos a crear un calendario de cumpleaños de usuarios.

Agregando el plugin 1 2 3

<script src='lib/moment.min.js'> <script src='fullcalendar/fullcalendar.js'>

Cargando el fullcalendar En el html tenemos que agregar un div, y dentro de este div agregaremos el calendario

1

1 2 3 4 5 6 7 8

<script> $(document).ready(function() { $('#calendar').fullCalendar({ theme: true, events: "#{}" }) });

35) Envió de correos con Action Mailer Intro Action Mailer nos permite enviar correos desde nuestra aplicación utilizando clases y vistas mailer . Estos funcionan muy parecido a los controladores en donde un método en la clase mailer tiene una vista asociada.

Creando nuestro mailer

Como casi todo en rails, existe un generador para crear los archivos mailer necesarios.

1

rails generate mailer UserMailer

Esto creara los siguientes archivos:

1 2 3 4 5 6 7 8 9

create create invoke create create create invoke create create

app/mailers/user_mailer.rb app/mailers/application_mailer.rb erb app/views/user_mailer app/views/layouts/mailer.text.erb app/views/layouts/mailer.html.erb test_unit test/mailers/user_mailer_test.rb test/mailers/previews/user_mailer_preview.rb

Como pueden ver, se generó un mailer y un directorio en las vistas para este, muy parecido a los controllers. Si revisamos el mailer generado podemos ver que un mailer hereda de ActionMailer::Base

1 2

class UserMailer < ApplicationMailer end

Modificando el mailer y como probarlo Los mailers son muy similares a los controladores, ellos tienen métodos, llamados ‘acciones’, y usan vistas para estructurar el contenido. La diferencia es que en ves de generar contenido tipo HTML para ser mostrado en el browser, se crea un mensaje para ser enviado por correo.

Crear un método para dar la bienvenida a quien se registra en nuestra pagina 1. Añadir un método llamado welcome_user

1 2 3 4 5 6 7 8 9 10 11 12 13

class UserMailer < ApplicationMailer default from: '[email protected]'

def welcome_email(user) @user = user @url = 'http://example.com/login' mail( to: @user.email, subject: 'Welcome to My Awesome Site', template_path: 'user_mailer', # opcional template_name: 'welcome_mail') # opcional end

end

El método default, que acepta un hash como parámetro: aquí estamos seteando el header

from:

para todos los mensajes en esta clase. Si queremos setear el from para todos lo mailer lo hacemos en el archivo application_mailer El método mail: es donde armamos el mensaje de correo. aquí estamos pasando a quien :to y el asunto :subject . template_path y template_name setean la carpeta en donde esta la vista y el nombre de esta respectivamente. Estos son campos opcionales y solo los agregaremos en caso de tener nombres personalizados o reutilizar una vista Al igual que en los controllers, todas las variables de instancia definidas en este método estarán disponibles para ser usadas en la vista. 1. Crear la vista Primero crearemos una vista HTML para el correo

1 2 3 4 5 6 7 8 9

Welcome to example.com, <%= @user.name %>

You have successfully signed up to example.com, your username is: <%= @user.login %>.

To login to the site, just follow this link: <%= @url %>.

Thanks for joining and have a great day!

Y también crearemos una vista en texto plano, ya que no todos los clientes usan HTML por lo que enviar las dos opciones es una buena practica.

1 2 3 4 5 6 7 8 9

Welcome to example.com, <%= @user.name %> =============================================== You have successfully signed up to example.com, your username is: <%= @user.login %>. To login to the site, just follow this link: <%= @url %>. Thanks for joining and have a great day!

Al tener las dos vistas, action mailer las detectara y enviara un correo de tipo multipart/alternative 1. Testeando el mailer En el ambiente de desarrollo podemos usar ActionMailer Preview para testear nuestros correos. Para eso iremos al archivo correspondiente a nuestro mailer: test/mailers/previews/user_mailer_preview.rb En el llamaremos a nuestro método welcome_email y le pasaremos un usuario cualquiera como parámetro

1 2 3 4 5

class UserMailerPreview < ActionMailer::Preview def welcome_email_preview UserMailer.welcome_email(User.last) end end

Y si ahora vamos a la siguiente url: http://localhost:3000/rails/mailers/user_mailer, tendremos un listado con los test creados, en este caso solo uno: welcome_email_preview . Si entramos a el veremos el correo que se enviara en sus dos verisones, HTML y Texto Plano, y podremos revisar si esta todo ok.

Enviando el correo usando ActionMailer y Gmail Por defecto rails trata de enviar los correos usando el protocolo SMTP. Para poder enviar los correos configuraremos nuestra aplicación para que use nuestra cuenta de gmail.

Es importante recordar que la información sensible, como por ejemplo nuestro nombre de usuario y contraseña de gmail, nunca deben ser usados de manera explicita en nuestros archivos de configuración, ya que existen pequeños programas, llamados [web crawlers] (https://en.wikipedia.org/wiki/Web_crawler) o web spiders, que se dedican a buscar este tipo de información sensible. Por lo tanto para usar estos datos los pasaremos de manera implícita a nuestros archivos de configuración usando variables de entorno con la gema `dotenv-rails` 1. Como implementar y usar variables de entorno

Primero instalamos la gema dot-env en nuestro gemfile: 1

gem 'dotenv-rails', groups: [:development, :test]

Luego creamos un archivo llamado

.env en nuestra aplicacion

Antes de cualquier otra cosa agregamos este archivo al .gitignore git le haga seguimiento y lo suba a github!!!

ya que NO queremos que

Dentro de ese archivo creamos las variables a usar: 1 2

GMAIL_USERNAME=ninombredeusurario GMAIL_PASSWORD=miclave

1

El nombre de la variable puede ser cualquier cosa y puede ir en mayusculas o min

Ahora para poder usar estas variables en algún archivo las llamamos de la siguiente forma:

1

ENV['GMAIL_USERNAME']

Donde GMAIL_USERNAME es el nombre de la variable que queremos usar. 1. Configuración de ActionMailer Para configurar ActionMailer la mejor opción es usar los archivos de ambiente (como enviroment.rb, production.rb, development.rb, etc…). Pueden revisar las opciones de configuración aqui. En nuestro caso usaremos /config/environments/development.rb ya que estamos trabajando en el ambiente de desarrollo, esta configuración también se debe hacer en /config/environments/production.rb para cuando estemos en producción.

1 2 3 4 5 6 7 8 9 10

config.action_mailer.raise_delivery_errors = true config.action_mailer.delivery_method = :smtp config.action_mailer.smtp_settings = { address: 'smtp.gmail.com', port: 587, user_name: ENV['GMAIL_USERNAME'], password: ENV['GMAIL_PASSWORD'], authentication: :login, enable_starttls_auto: true }

Para el ambiente de desarrollo recomiendo agregar lo siguiente:

1

config.action_mailer.perform_deliveries = false

Esto para que al hacer pruebas en nuestra aplicación no se envíen los correos. 1. Enviar el correo al usuario Para usar nuestro mailer y enviar el mensaje cuando se crea un nuevo usuario, lo llamaremos desde el UserController en el método create que es donde se crea y guarda el usuario. Es importante que sepan que para que el correo efectivamente se envíe tenemos que terminar de llamarlo con el método :deliver_now o :deliver_later , la diferencia entre ambos la veremos mas adelante.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save # Tell the UserMailer to send a welcome email after save UserMailer.welcome_email(@user).deliver_later format.html format.json else format.html format.json end end end end

{ redirect_to(@user, notice: 'User was successfully created.' { render json: @user, status: :created, location: @user } { render action: 'new' } { render json: @user.errors, status: :unprocessable_entity }

En el caso de estar creando un nuevo registro, como en este ejemplo, es importante que el envío del correo se realize una vez que el registro se ha guardado, no antes ya que no queremos enviar el correo y después al tratar de guardar el registro se presenta un error y este no se guarda.

ActionMailer y Devise Que pasa si queremos enviar un correo de bienvenida cuando se registra un nuevo usuario si estamos usando devise? Cuando usamos devise no tenemos un controlador para User como el del ejemplo anterior, por lo que tendremos que ver que opciones tenemos para poder enviar el correo.

Primera Opción: creando el controlador de devise para el usuario

1. Crear el controlador de devise Solo necesitamos crear el controlador de registros de devise, para eso corremos el siguiente comando, asumiendo que tenemos un modelo user hecho con devise

1

rails g devise:controllers users -c=registrations

Esto solo creara el controller registrations dentro de la carpeta user 2. Modificar el controller Ahora que tenemos el controller creado lo modificaremos y lo dejaremos así:

1 2 3 4 5 6

class Users::RegistrationsController < Devise::RegistrationsController def create super UserMailer.welcome_email(@user).deliver_later unless @user.invalid? end end

3. Decirle a devise que use el controller creado anteriormente En el archivo de rutas ( routes.rb ) le diremos a devise que use este nuevo controller

1 2 3

... devise_for :users, ...

controllers: { registrations: 'users/registrations' }

Eso es todo, ahora cuando un usuario se registre se enviara un correo de bienvenida.

Segunda Opción: modificando el modelo de usuario En esta segunda opción no es necesario crear nada adicional ya que solo modificaremos el modelo de usuario 1. Modificar el Modelo de usuario Creamos un método privado dentro del modelo de usuario

1 2 3 4 5 6 7 8 9 10

class User < ActiveRecord::Base # ... # código omitido

private def send_welcome_email UserMailer.welcome_email(self).deliver_later end

end

2. Ejecutar el método cada vez que se crea un nuevo usuario En el mismo modelo, usaremos un callback para llamar a el método que nos creamos anteriormente cava des que se cree un nuevo usuario. Para eso usaremos el callback :after_create

1 2 3 4 5 6

class User < ActiveRecord::Base after_create :send_welcome_email # código omitido # ... end

Eso es todo en esta segunda opción.

ActionMailer y ActiveJob: deliver_now, deliver_later? Como se menciono anteriormente, para enviar el correo hay que pasar el método :deliver_now o :deliver_later a nuestro mailer, en el caso del ejemplo seria así: UserMailer.welcome_email(user).deliver_now . La diferencia entre estos dos métodos la podemos deducir de su nombre: 1. deliver_now: (sincrona) envía el correo inmediatamente en el proceso en el que fue llamado, si han realizado pruebas se habrán dado cuenta que al crear un nuevo usuario este proceso demora un poco mas, y ¿por qué demora más?, demora más porque ahora cuando se crea un nuevo usuario se llama al mailer para que envíe el correo, el mailer a su vez tiene que hacer las conexiones con el servidor de correo y autenticarse para luego enviar el correo, una vez que se termina de enviar el correo el proceso de creación del usuario puede terminar. 2. deliver_later: (asíncrona) a diferencia de su hermano, este método no envía el correo de manera inmediata al ser llamado, lo que hace es dejarlo en una cola de trabajo (queue) a la espera de ser enviado, por lo que el proceso de creación del usuario no demora más ya que no tiene que esperar a que se envíe el correo para poder terminar su proceso. Si han hecho pruebas con deliver_later se habrán dado cuenta de que aun así el tiempo de creación del usuario no ha mejorado con respecto a deliver_now, ¿por qué? La respuesta es ActiveJob

ActiveJob y deliver_later A partir de la version 4.2 rails trae incorporado el framework ActiveJob para declarar ‘trabajos’ (jobs) y que estos puedan correr en alguno de los backends que manejan colas de trabajo (queueing). Estos ‘trabajos’ pueden ser cualquier cosa, desde mantenimientos programados, cobros, envío de correos, etc … Los backends que manejan estas colas de trabajo son gemas que podemos integrar en nuestra aplicación, ejemplo de estas son Delayed Job, Resque, Sucker Punch, Sidekiq, etc … Gracias a ActiveJob podemos usar cualquiera de estas e incluso cambiar en medio del desarrollo sin tener que

reescribir nuestros ‘trabajos’. Para saber mas sobre ActiveJob pueden leer la guia oficial aqui El punto que nos interesa a nosotros en esta guía es el uso de ActionMailer y ActiveJob. Gracias a que estos dos son parte de rails, ActiveJob esta integrado con ActionMailer, por lo que podemos enviar correos de manera asíncrona en una cola de trabajo utilizando el método deliver_later

1 2 3 4 5

# Si quieres enviar el correo inmediatamente usa #deliver_now UserMailer.welcome_email(@user).deliver_now # Si quieres enviar el correo mediante ActiveJob usa #deliver_later UserMailer.welcome_email(@user).deliver_later

Entonces, ¿por qué, si están integrados, al usar deliver_later se comporta como deliver_now? Por

defecto, cuando no tenemos ningún backend asociado a ActiveJob su comportamiento sera ejecutar los trabajos de manera ‘inline’, es decir, inmediatamente. Para poder aprovechar ActiveJob lo que haremos sera integrar un backend, en este caso usaremos sucker_punch ya que no necesita de muchos pasos para configurarlo. 1. Agregar la gema sucker_punch

1

gem 'sucker_punch'

Como ya saben después de agregar una gema corremos bundle en la terminal 2. Configurar ActiveJob para que use sucker_punch Esto lo haremos en el archivo /config/environments/production.rb , si queremos hacer pruebas en el modo de desarrollo tendremos que hacerlo también en /config/environments/development.rb

1

config.active_job.queue_adapter = :sucker_punch

3. NO HAY PASO 3 En serio, esto es todo lo que hay que hacer para poder enviar los correos de forma asíncrona usando ActiveJob y deliver_later Si hacen una prueba ahora se darán cuenta que el proceso de crear un usuario ya no demora como antes y el correo se envía igual!!!

36) Testings automatizado con Guard En rails es posible automatizar completamente los test ocupando guard. Uno se preguntaría para que automatizar más, puesto que con la simple instrucción rake se corren todos los test definidos, pero la gema Guard permite que se corran automatícamente los tests respectivo cada vez que modificas un archivo de un controller, fixture, modelo o test, y te avisa si producto de la introducción de alguna mejora rompiste alguna funcionalidad ya existente en el sistema. Esta guía se ha probado con: * Ruby version 2.1.2 o mayor * Rails version 4.1.5 o mayor * MiniTest version 5.4.0 o mayor

Instalar Guard en nuestro proyecto Primero vamos a añadir las gemas necesarias a nuestro Gemfile

1 2 3 4 5 6 7 8 9

group :development do gem 'guard' gem 'guard-minitest' gem 'minitest-reporters' # notificaciones, solo usuarios de Mac OS X 10.8 o mayor gem 'terminal-notifier' gem 'terminal-notifier-guard' end

si van a usar las notificaciones tienen que instalar terminal-notifier con brew (brew install terminal-notifier)

Que hace cada gema?

guard : añade soporte para la herramienta Guard que maneja eventos y modificaciones de archivos. guard-minitest : encargara de monitorear los cambios y ejecutar nuestros test usando minitest. minitest-reporters : nos permite customisar el output de nuestros test y darle color a los resultados. terminal-notifier y terminal-notifier-guard : solo para los usuarios de osx 10.8 o mayor, nos mostrara un mensaje en el centro de notificaciones cuando se ejecuten los test.

Añadimos estas gemas al grupo de desarrollo porque se ejecutarán desde el entorno de desarrollo y no afectan el entorno de testing.

Configurar Guard Ahora que tenemos guard guard instalado en nuestro proyecto proyecto tenemos que generar generar su archivo archivo de configuración, para esto ejecutamos lo siguiente en la terminal:

1

bundle exec exec guard guard init minitest

Esto va a crear un archivo llamado Guardfile en el root de nuestro proyecto. Lo que hace este archivo es decirle a Guard que archivos tiene que monitorear y que hacer cuando alguno de estos se ha modificado. En nuestro caso va a monitorear la carpeta app y todo su contenido y llamara los test correspondientes usando minitest. Al crear el Guardfile éste viene así:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

# A sample Guardfile # More info at https://github.com/guard/guard#readme guard :minitest do # with Minitest::Unit watch( watch (%r{^test/(.*)\/?test_(.*)\.rb$} %r{^test/(.*)\/?test_(.*)\.rb$}) ) watch( watch (%r{^lib/(.*/)?([^/]+)\.rb$} %r{^lib/(.*/)?([^/]+)\.rb$}) ) { |m| "test/ "test/#{ #{m m[1]}test_ test_#{ #{m m[2]}.rb" .rb" } } watch( watch (%r{^test/test_helper\.rb$} %r{^test/test_helper\.rb$}) ) { 'test' } 'test' } # # # #

with Minitest::Spec watch(%r{^spec/(.*)_spec\.rb$}) watch(%r{^lib/(.+)\.rb$}) { |m| "spec/#{m[1]}_spec.rb" } watch(%r{^spec/spec_helper\.rb$}) { 'spec' }

# # # # # # # #

Rails 4 watch(%r{âpp/(.+)\.rb$}) { |m| "test/#{m[1]}_ watch(%r{âpp/controllers/application_controller\.rb$}) { 'test/controllers' watch(%r{âpp/controllers/(.+)_controller\.rb$}) { |m| "test/integrati watch(%r{âpp/views/(.+)_mailer/.+}) { |m| "test/mailers/# watch(%r{^lib/(.+)\.rb$}) { |m| "test/lib/#{m[ watch(%r{^test/.+_test\.rb$}) watch(%r{^test/test_helper\.rb$}) { 'test' }

# # # # end

Rails < 4 watch(%r{âpp/controllers/(.*)\.rb$}) { |m| "test/functional/#{m[1]}_test.rb watch(%r{âpp/helpers/(.*)\.rb$}) { |m| "test/helpers/#{m[1]}_test.rb" } watch(%r{âpp/models/(.*)\.rb$}) { |m| "test/unit/#{m[1]}_test.rb" }

Como nosotros estamos usando Rails 4, descomentaremos las líneas 16 a la 22 y borraremos el resto de las líneas comentadas dejando el archivo así:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

# A sample Guardfile # More info at https://github.com/guard/guard#readme guard :minitest do # with Minitest::Unit watch( watch (%r{^test/(.*)\/?test_(.*)\.rb$} %r{^test/(.*)\/?test_(.*)\.rb$}) ) watch( watch (%r{^lib/(.*/)?([^/]+)\.rb$} %r{^lib/(.*/)?([^/]+)\.rb$}) ) { |m| "test/ "test/#{ #{m m[1]}test_ test_#{ #{m m[2]}.rb" .rb" } } watch( watch (%r{^test/test_helper\.rb$} %r{^test/test_helper\.rb$}) ) { 'test' } 'test' } # Rails 4 watch( watch (%r{âpp/(.+)\.rb$} %r{âpp/(.+)\.rb$}) ) { |m| "test/ "test/#{ #{m m[1]}_te watch( watch (%r{âpp/controllers/application_controller\.rb$} %r{âpp/controllers/application_controller\.rb$}) ) { 'test/controllers' 'test/controllers' } } watch( watch (%r{âpp/controllers/(.+)_controller\.rb$} %r{âpp/controllers/(.+)_controller\.rb$}) ) { |m| "test/integratio watch( watch (%r{âpp/views/(.+)_mailer/.+} %r{âpp/views/(.+)_mailer/.+}) ) { |m| "test/mailers/ "test/mailers/#{ #{m m watch( watch (%r{^lib/(.+)\.rb$} %r{^lib/(.+)\.rb$}) ) { |m| "test/lib/ "test/lib/#{ #{m m[1] watch( watch (%r{^test/.+_test\.rb$} %r{^test/.+_test\.rb$}) ) watch( watch (%r{^test/test_helper\.rb$} %r{^test/test_helper\.rb$}) ) { 'test' 'test' } } end

¿Qué hace cada línea?

1 2 3

guard :minitest do # ... end

Aquí le decimos a Guard Guard que el siguiente siguiente bloque se tiene que ejecutar ejecutar con Minitest. Guard Guard se puede configurar con multiples plugins que pueden realizar muchas otras cosas.

1

watch( watch (%r{^test/(.*)\/?test_(.*)\.rb$} %r{^test/(.*)\/?test_(.*)\.rb$}) )

Esta línea monitorea todos los archivos se ha modificado.

1

.rb en las subcarpetas de test/ y ejecuta el archivo que

watch( watch (%r{^lib/(.*/)?([^/]+)\.rb$} %r{^lib/(.*/)?([^/]+)\.rb$}) )

{ |m| "test/ "test/#{ #{m m[1]}test_ test_#{ #{m m[2]}.rb" .rb" } }

Esta línea monitorea todos los archivos .rb que se encuentran en el directorio lib y ejecutará el test correspondiente si es que existe alguno.

1

watch( watch (%r{^test/test_helper\.rb$} %r{^test/test_helper\.rb$}) )

{ 'test' 'test' } }

Esta línea monitorea el archivo test_helper.rb y si hay un cambio ejecuta todos t odos los test.

1

watch( watch (%r{âpp/(.+)\.rb$} %r{âpp/(.+)\.rb$}) )

{ |m| "test/ "test/#{ #{m m[1]}_test.rb" _test.rb" } }

Esta línea monitorea todos los archivos en el directorio app y ejecuta el test correspondiente. En una aplicación típica de rails estos serian los models, controllers, helpers y mailers.

1

watch( watch (%r{âpp/controllers/application_controller\.rb$} %r{âpp/controllers/application_controller\.rb$}) ) { 'test/controllers' 'test/controllers' } }

Esta línea monitorea el archivo aplication_controller.rb y ejecuta todos los test de controladores si se modifica.

1

watch( watch (%r{âpp/controllers/(.+)_controller\.rb$} %r{âpp/controllers/(.+)_controller\.rb$}) )

{ |m| "test/integration/

Esta línea monitorea los controladores y ejecuta el test de integración correspondiente correspondiente cuando hay modificaciones.

1

watch( watch (%r{âpp/views/(.+)_mailer/.+} %r{âpp/views/(.+)_mailer/.+}) )

{ |m| "test/mailers/ "test/mailers/#{ #{m m[1]

Esta línea monitorea la carpetas de las vitas de los mailers y ejecuta el test correspondiente cuando hay modificaciones.

1

watch( watch (%r{^lib/(.+)\.rb$} %r{^lib/(.+)\.rb$}) )

{ |m| "test/lib/ "test/lib/#{ #{m m[1]}_

Esta línea monitorea la carpeta lib y ejecuta el test t est correspondiente cuando hay modificaciones si es que lo existe un test asociado.

1 2

watch(%r{^test/.+_tests\.rb$} watch( %r{^test/.+_tests\.rb$}) ) watch( watch (%r{^test/test_helper\.rb$} %r{^test/test_helper\.rb$}) ) { "test" "test" } }

Estas líneas monitorear todos los archivos terminados en un cambio en alguno de ellos ejecutará el test.

_test.rb y test_helper.rb y si hay

Esta es la configuración básica de nuestro Guardfile y como ven es muy completa. Sin embargo podemos agregar unos monitores extras, que en lo personal encuentro de bastante utilidad. Agregaremos las siguientes líneas líneas a nuestro Guardfile:

1 2 3 4 5 6 7 8 9 10 11 12

# agregar la siguiente línea al inicio del archivo require 'active_support/inflector' guard :minitest do # ... código anterior omitido # extra tests watch( watch (%r{âpp/views/(.+)/.+} %r{âpp/views/(.+)/.+}) ) { |m| "test/controllers/#{ "test/controllers/#{m m[1]}_controllet_tes watch( watch (%r{^test/fixtures/(.+)\.yml} %r{^test/fixtures/(.+)\.yml}) ) { |m| "test/models/ "test/models/#{ #{m m[1]. ].singularize singularize} }_t watch( watch (%r{^test/fixtures/(.+)\.yml} %r{^test/fixtures/(.+)\.yml}) ) { |m| "test/controllers/ "test/controllers/#{ #{m m[1]}_controll end

El detalle de los ajustes adicionales

1

require 'active_support/inflector'

singularizar ’ los nombres de los fixtures. Esto nos Aquí añadimos la clase clase inflector de rails para poder ‘ singularizar permite convertir ‘Posts’ en ‘Post’ para cualquier modelo o controlador. controlador.

1

watch( watch (%r{âpp/views/(.+)/.+} %r{âpp/views/(.+)/.+}) ) { |m| "test/controllers/ "test/controllers/#{ #{m m[1]}_controller_test.rb

Esta línea correra el el test de controlador si cambia alguna de las vistas asociadas.

1

watch( watch (%r{^test/fixtures/(.+)\.yml} %r{^test/fixtures/(.+)\.yml}) ) { |m| "test/models/ "test/models/#{ #{m m[1]. ].singularize singularize} }_test.

Esta línea ejecutará los tests de modelo si los fixtures cambian. Aquí es donde usamos la clase inflector de rails

1

watch( watch (%r{^test/fixtures/(.+)\.yml} %r{^test/fixtures/(.+)\.yml}) ) { |m| "test/controllers/ "test/controllers/#{ #{m m[1]}_controller_t

Esta línea ejecutará los tests de controlador si los fixtures cambian.

Configurar Minitest-Repor Minitest-Reporters ters Antes de continuar con Guard vamos a configurar nuestro nuestro ambiente de testing para que haga uso de minitest-reporters y así el output de nuestros test se vera mejor y con colores.

1. Decirle a nuestros test que usaremos minitest-reporters En el archivo test/test_helper.rb añadimos lo siguiente:

1 2 3 4 5 6

ENV['RAILS_ENV' ENV[ 'RAILS_ENV'] ] ||= 'test' require File File. .expand_path expand_path( ('../../config/environment' '../../config/environment', , __FILE__) require 'rails/test_help' require "minitest/reporters" # línea que hay que añadir # ... resto del archivo omitido

reporters s y configurarlo 2. Iniciar minitest reporter

En el mismo archivo que en el paso anterior añadimos lo siguiente:

1 2 3 4 5 6 7

# ... código omitido class ActiveSupport ActiveSupport: ::TestCase # ... código omitido Minitest: Minitest ::Reporters :Reporters.use .use! ! Minitest Minitest: ::Reporters :Reporters: ::SpecReporter :SpecReporter. .new end

La primera parte Minitest::Reporters.use! le dice a nuestro test_helper que usaremos minitest-reporters. La segunda parte Minitest::Reporters::SpecReporter.new queremos usar, en este caso SpecReporter.

le dice que estilo de reporte

Para que vean la diferencia: Sin minitest-reporte minitest-reporters rs

1 2 3 4 5 6 7 8 9

Run options: --seed 34387 # Running: ... Finished in in 0.327633s, 0.327633s, 70.2005 runs/s, 109.8791 assertions/s. 3 runs, 3 assertions, 0 failures, 0 errors, 0 skips

Con minitest-repor minitest-reporters ters

1 2 3 4 5 6 7 8 9 10 11 12 13

Started with run options --seed 28340 ProductsControllerTest test_should_get_new

PASS (0.19s)

ProductTest test_should_not_create_product_withoud_description

PASS (0.00s)

UserTest test_user_owns_products

PASS (0.02s)

Finished in in 0.34634s 0.34634s 3 tests, 3 assertions, 0 failures, 0 errors, 0 skips

Correr Guard para automatizar el testing Ahora que nuestro nuestro Guardfile esta completo completo solo falta ejecutarlo desde nuestra línea de comando: comando:

1

bundle exec exec guard guard

Esto iniciara Guard, analizara el Guardfile y los plugins instalados y carrera nuestros test de manera automática. Al correr Guard nuestra consola quedara secuestrada por este proceso, al igual que cuando corremos el servidor de rails. Para salir de Guard escribimos exit Una vez iniciado Guard veremos un output similar a este en nuestra consola:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

13:07:02 - INFO - Guard::Minitest 2.4.4 is running, with Minitest::Unit 5.8.2 ! 13:07:02 - INFO - Running: all tests Started with run options --seed 46327 ProductsControllerTest test_should_show_product test_should_get_edit

PASS (0.18s) PASS (0.03s)

UserTest test_should_not_create_user_withoud_username test_should_not_create_user_without_name


ProductTest test_should_not_create_product_withoud_description test_price_should_be_a_float


Finished in 0.31300s 6 tests, 6 assertions, 0 failures, 0 errors, 0 skips 13:07:05 - INFO - Guard is now watching at '/Users/Username/Path/To/Project' [1] guard(main)>

Con guard cualquier cambio que hagamos en los archivos monitoreados gatillará los test relevantes y se ejecutarán automáticamente, y si estas en OSX e instalaste terminal-notifier recibirás una notificación. Si quieres forzar la ejecución de los test, simplemente presiona enter en el prompt de Guard ( [1] guard(main)> ) en la consola. Eso es todo, recuerda que para salir del prompt de Guard (y obviamente del testing automatizado) escribe exit en él. Eso es todo. No te olvides de siempre usar testing cuando desarrolles un proyecto!

37) Rails y Nginx con Passenger en Ubuntu: Preparando nuestro entorno de producción (DigitalOcean). Introducción Ruby on Rails (RoR) es un framework de desarrollo que le entrega a los desarrolladores una fácil y rápida

herramienta para crear aplicaciones web, y Nginx es un servidor web ligero de alto rendimiento. Estos dos programas puedes ser configurados fácilmente para que trabajen en conjunto en un VPS (Virtual Private Server) con Phusion Passenger. Pushion Passenger es un servidor web y de aplicaciones, diseñado para integrarse con Nginx o Apache.

Originalmente creado para aplicaciones hechas con RoR, lo que hace que sea la recomendada por la comunidad de RoR, ademas de ser estable, rápido y escalable. *Otros servidores de aplicaciones son Unicorn y Puma.

Acerca de esta guía. Esta guía esta pensada como un recetario para configurar y preparar nuestro servidor utilizando Nginx, Passenger, RVM, Ruby, Rails y Postgres; y se espera que ya tengan creada su maquina virtual (VPS) con Ubuntu 14.04 y 15.04 1 en DigitalOcean o Linode. Se espera que el lector de esta guía sepa como utilizar la terminal y tenga conocimiento de al menos comandos básicos de este. Así como también se espera sepan usar postgres.

Convenciones. 1. Los términos servidor, server o VPS hacen referencia a su maquina virtual. 2. El termino local hace referencia a su computador. 3. Para determinar el entorno en que tenemos que ejecutar los comandos y en cual estaremos trabajando en cada sección se usara: local para la maquina local o servidor para la maquina virtual. 4. Se usara para los ejemplos la IP: 111.11.111.11 , esta tienen que ser remplazada por la ip de su maquina virtual. 5. Para mostrar las instrucciones a ejecutar en el terminal se antepondrá el signo $ , que es la representación de su línea de comandos que esta lista para recibir una instrucción ( no hay que tipearlo ), y tendrán el siguiente estilo:

1

$ gem install postgres

*Cada línea que empieza con

$ se ejecuta por separado.

Para mostrar las respuestas, errores o advertencias que nos arroja el terminal al ejecutar una instrucción no se antepone el signo $ y tendrán el siguiente estilo:

1

Agent pid 32877

6. Se espera que tengan una llave ssh creada.

Paso 0 – Como acceder a nuestro servidor local

Para acceder a nuestro VPS usaremos el Terminal como interface de conexión mediante SSH. En nuestra terminal:

1

$ ssh [email protected]

La primera vez que nos tratemos de conectar se nos mostrara un mensaje como este:

1 2 3

The authenticity of host 'xx.xx.xx.xx (xx.xx.xx.xx)' can't be established. ECDSA key fingerprint is 79:95:46:1a:ab:37:11:8e:86:54:36:38:bb:3c:fa:c0. Are you sure you want to continue connecting (yes/no)?

Este nos advierte que no se puede establecer la autenticidad del host y si queremos conectarnos de todas formas. Obviamente le decimos que Yes. Sabremos que estamos iniciados porque veremos algo como esto en nuestra terminal servidor

1

$ root@ip-111-11-111-11:~$

Esto no indica que estamos logueados en la maquina con ip 111.11.111.11 en el usuario root, todo lo que escribamos ahora se ejecutará en el servidor.

Para desconectarnos del servidor y "volver" a nuestra maquina local escribimos lo siguiente: servidor

1

$ exit

Invalid Locale Warning servidor

En algunos casos puede ser que al entrar a su maquina les muestre esta advertencia:

1 2 3

WARNING! Your environment specifies an invalid locale. This can affect your user experience significantly, including the ability to manage packages.

O que al instalar un paquete les muestre esto:

1 2 3 4 5 6 7 8 9 10 11

perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_US:en", LC_ALL = (unset), LC_MESSAGES = "en_US.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory

Este es un error que tenemos que arreglar o si no tendremos problemas con los paquetes a instalar, sobre todo con Postgres. Para arreglarlo hacemos lo siguiente: 1. Primero generamos el locale que no esta definido:

1

$ sudo locale-gen "en_US.UTF-8"

2. Reconfiguramos lo locales:

1

$ sudo dpkg-reconfigure locales

Solo si por alguna razón con los comandos anteriores no se arregla el error haremos lo siguiente:

1. Abrimos el archivo environment con algún editor (vim, nano, emacs, etc):

1

$ sudo vim /etc/environment

2. Agregamos las siguientes líneas:

1 2

LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8

Ahora ya no deberíamos tener ese error al instalar un paquete

Configurar el timezone en nuestro servidor ¿Por qué? Cuando revisamos nuestros logs, estos tienen la marca de tiempo en GMT y no en nuestra zona horaria, lo que hace que revisar nuestros logs sea un poco mas difícil. Para configurar el timezone del servidor a nuestra zona horaria local haremos lo siguiente: 1. Revisaremos el timezone del servidor: 1

$ date

Esto imprime la fecha, hora y zona horaria de nuestro servidor:

1

Mon Aug 31 16:52:18 MST 2015

O podemos revisar solo la zona horaria, así:

1

$ more /etc/timezone

Que imprimira el timezone del servidor:

1

US/Arizona

1. Si el timezone del servidor no corresponde a nuestra zona horaria ejecutamos lo siguiente:

1

sudo dpkg-reconfigure tzdata

y seguimos las instrucciones en pantalla:

Una vez elegida nuestra zona horaria, podemos volver a comprobar ejecutando los comandos del paso

anterior.

Acerca del usuario Root servidor

En linux el usuario root es el usuario administrador y tiene demasiados privilegios. Debido a esto se recomienda no usarlo de manera regular, ya que por accidente podemos hacer cambios destructivos en nuestro servidor. ¿Que hacer entonces?

Para evitar lo anterior y seguir las recomendaciones y buenas practicas crearemos un nuevo usuario para el uso diario, al que le daremos los privilegios necesarios para cuando lo necesitemos. Dentro de nuestro VPS haremos lo siguiente: 1. Creamos un nuevo usuario, este se llamara deploy. Se nos pedirá crear una contraseña, esta no se nos puede olvidar, ya que con ella nos tendremos que conectar al VPS y ejecutar comandos sudo, y opcionalmente se nos pedirá información adicional.

1

$ adduser deploy

(El nombre deploy es un buen nombre para el usuario de deployment, pero no es necesario que sea este)

2. Añadimos el nuevo usuario al grupo de sudoers. En este paso al agregar al usuario al grupo de los sudoers le daremos la posibilidad de ejecutar comandos con privilegio de administrador cuando sea necesario, eso si tendrá que anteponer la palabra sudo (super user) al comando y se le pedirá su clave.

1

$ gpasswd -a deploy sudo

3. Salimos del servidor…

1

$ exit

4. *… y nunca más entramos como root

1


*Esta vez se nos pedirá la contraseña que pusimos al crear el usuario.

¿Cómo ingresar sin tener que ingresar la clave cada vez que nos queremos conectar a nuestro servidor? local

Para no tener que poner la clave cada vez que queremos conectarnos al servidor y también así evitar problemas en un futuro al usar Capistrano para hacer deploy, haremos lo siguiente: Copiamos nuestra llave publica al llavero del usuario deploy.

1

$ ssh-copy-id [email protected]

En esta etapa, que demora un poco, se nos pedirá la clave del usuario deploy para poder copiar la llave ssh en el llavero del usuario deploy Solo si el paso anterior falla porque no encuentra el comando ssh-copy-id, lo instalaremos de la siguiente forma: En Mac.

1

$ brew install ssh-copy-id

En Linux.

1

$ apt-get install ssh-copy-id

Ahora nos podremos conectar al servidor sin tener usar la contraseña!!!

1


Paso 1 – Instalación de RVM servidor

Ahora que ya podemos entrar a nuestro servidor con un usuario diferente a root, vamos a hacer el primer

paso para configurar nuestro entorno, instalaremos RVM (Ruby Version Manager) el cual nos permitirá instalar ruby y manejar distintas versiones de éste. 1. Antes de hacer cualquier cosa haremos un update para asegurarnos que todos los paquetes que bajaremos a nuestro VPS estén al día

1

$ sudo apt-get update

2. Instalación de RVM

1

$ curl -L get.rvm.io | bash -s stable

En este paso nos mostrara un warning y si leemos bien veremos las siguiente líneas:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

... gpg: Can't check signature: public key not found Warning, RVM 1.26.0 introduces signed releases and automated check of signatu Assuming you trust Michal Papis import the mpapis public key (downloading the GPG signature verification failed for '/home/deploy/.rvm/archives/rvm-1.26.11. try downloading the signatures: gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804 or if it fails: command curl -sSL https://rvm.io/mpapis.asc | gpg --import the key can be compared with: https://rvm.io/mpapis.asc https://keybase.io/mpapis

Ahi mismo nos dice que tenemos que descargar la firma para autenticar el paquete antes de instalar, y eso lo hacemos copiando la que dice: gpg –keyserver hkp://keys.gnupg.net –recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

Y la pegamos en el terminal

1

$ gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A17031138

después volvemos a ejecutar el instalador de RVM

1

$ curl -L get.rvm.io | bash -s stable

Ahora si se instalara sin problemas RVM. Eso si para poder usarlo tenemos que ‘cargarlo’ a nuestro terminal.

1

$ source /home/deploy/.rvm/scripts/rvm

(esto solo se hace una sola vez)

3. Ahora le diremos a RVM que instale todas las dependencias que necesita.

1

$ rvm requirements

Paso 2 – Instalación de Ruby y de Rails servidor

Ahora que tenemos RVM instalado, lo usaremos para instalar Ruby. 1. Le pedimos a rvm que instale la version de ruby que necesitamos

1

$ rvm install 2.2.3

A la fecha de la guía Ruby-2.2.3 es la ultima versión.

1. Ahora le diremos a RVM que use esa version por defecto

1

$ rvm use 2.2.3 --default

2. Ahora nos aseguraremos de que tenemos todos los componentes requeridos por RoR

1

$ rvm rubygems current

Si todo sale bien ahora podremos instalar RoR y otras gemas, pero antes de eso le diremos a nuestra

maquina que no descargue la documentación de las gemas al instalarlas, ya que ellas demoran el proceso y usan espacio innecesariamente.

1

$ echo "gem: --no-ri --no-rdoc" > ~/.gemrc

Ahora si instalamos RoR

1

$ gem install rails

Por un problema con la ultima version de rubygems y ruby (2.2.3), en el proceso de instalación de Rails tendremos un problema con la gema nokogiri , para solucionarlo haremos lo siguiente:

1

$ sudo apt-get install libgmp-dev

Después de eso instalamos la gema nokogiri :

1

$ gem install nokogiri

Y por ultimo volvemos a instalar rails:

1

$ gem install rails

Ahora si la instalación se hará correctamente.

Paso 3 – Instalación de Nginx y Passenger servidor

Una ves que tenemos RVM y Ruby instalaremos Nginx y Passenger, pero antes tenemos que preparar el servidor. 1. Lo primero que tenemos que hacer es instalar la llave GPG de Phusion Passenger

1

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 561F9B9CAC40B

2. Después descargaremos un paquete que le dará soporte HTTPS a APT

1

$ sudo apt-get install apt-transport-https ca-certificates

3. Luego añadimos el repositorio de passenger al source list de nuestra maquina para poder usarlo Para Ubuntu 14.04

1

$ sudo sh -c "echo 'deb https://oss-binaries.phusionpassenger.com/apt/passeng

Para Ubuntu 15.04

1

$ sudo sh -c "echo 'deb https://oss-binaries.phusionpassenger.com/apt/passeng

4. Después de agregarla tenemos que cambiar el grupo y permisos para poder hacer un update a los paquetes disponibles para incluirlo a ellos

1 2 3

$ sudo chown root: /etc/apt/sources.list.d/passenger.list $ sudo chmod 600 /etc/apt/sources.list.d/passenger.list $ sudo apt-get update

Ahora que tenemos el servidor preparado podemos instalar Nginx con Passenger:

1

$ sudo apt-get install nginx-full passenger

Y hacemos correr el servidor nginx

1

$ sudo service nginx start

Paso 4 – Habilitando Passenger en Nginx servidor

Para hacer el siguiente paso pueden usar vim, nano o emacs como editor de texto.

En el archivo de configuración de Nginx (nginx.conf) se tiene que especificar donde esta passenger. Para eso se tienen que descomentar (quitar el signo # que se antepone) las líneas que empiezan con:

1 2

# passenger_root .... # passenger_ruby ....

1. Primero abrimos el archivo de configuración de nginx con algún editor. (Nginx se encuentra en la carpeta /etc del servidor)

1

$ sudo vim /etc/nginx/nginx.conf

2. Ahora descomentamos las líneas antes nombradas y las dejamos asi:

1 2

passenger_root /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini; passenger_ruby /home/deploy/.rvm/wrappers/ruby-2.2.3/ruby;

Ojo que en la segunda línea la version de ruby, que en este caso es ruby-2.2.3, tiene que decir la version que tienen instalada Hecho esto guardamos los cambios y cerramos el archivo, y tenemos que reiniciar el servidor nginx para que aplique los cambios.

1

$ sudo service nginx restart

En caso de tener un problema al reiniciar el server puedes revisar los logs así:

1

$ sudo tail /var/log/nginx/error.log

Paso 5 – Instalación y configuración de Postgres. servidor

Instalación

Para poder trabajar con bases de dat os lo primero que tenemos que hacer es instalar Postgresql en nuestra maquina virtual junto con algunas dependencias necesarias. Para ello ejecutamos lo siguiente:

1

$ sudo apt-get install postgresql postgresql-contrib libpq-dev

Ahora para entrar al entorno de trabajo de postgres ejecutamos:

1

$ sudo -u postgres psql

El entorno de trabajo de postgres esta indicado con el siguiente prompt: postgres=# Para salir del entorno postgres y volver a nuestro usuario usamos

\q .

Creación de un usuario en postgres servidor

Ahora crearemos un superusuario en nuestro motor de base de datos, éste sera capas de crear bases de datos y tendrá todos los privilegios sobre esta, en lo personal utilizo el nombre de la aplicación con alguna variante o simplemente uso deploy. Crear el usuario:

1

$ sudo -u postgres createuser -s nombreUsuario

Ahora vamos a asignar un password al usuario de postgres que acabamos de crear (para el password usa uno seguro que sea distinto al del usuario de la VPS y que no se te olvide). Primero entramos al entorno de postgres:

1

$ sudo -u postgres psql

Para comprobar que el usuario se creo correctamente los vamos a listar usando \du , si nuestro usuario se encuentra en el listado es porque se creo correctamente. Ahora asignamos el password a nuestro usuario:

1

\password nombreUsuario

Se nos pedira ingresar la password y confirmarlo.

Creación de la base de datos En el entorno de postgres crearemos la base de datos asociada al usuario que creamos en el paso anterior.

1

CREATE DATABASE nombreBaseDatos OWNER nombreUsuario;

Una ves terminado salimos del entrono de postgres usando

\q .

Estos datos, nombre de usuario, contraseña y base de datos de postgres, son los que usaremos para configurar nuestro archivo database.yml en rails (en la guía de capistrano), por lo que es muy importante no olvidarlos.

Paso 6 – Crear un Server Block servidor

Cuando se usa Nginx, los server blocks (similar a los virtual hosts en Apache) se usan para encapsular los detalles de configuración y servir mas de un dominio en un único servidor. Ahora veremos como configurar los server blocks en nuestra maquina virtual. 1. Crear la carpeta donde se guardara nuestro proyecto o proyectos en caso de tener mas de uno. Nginx, por defecto, esta configurado para servir los documentos que están en el siguiente directorio:

1

/var/www/html

Nosotros no usaremos el default ya que es mas fácil trabajar desde nuestro directorio del usuario. Para eso nos podemos crear una nueva carpeta llamada /www o /apps (En esta guía vamos a trabajar con la carpeta /www ). En este directorio es donde cada uno de nuestros proyectos tendrá su propia carpeta, ej:

1 2

~/www/example/ ~/www/test/

Crear el directorio:

1

$ mkdir -p ~/www/example

**La opción -p le dice a mkdir que cree todos los directorios padres necesarios si estos no existen Ahora que tenemos creado el directorio vamos a continuar. 2. Crear una pagina de prueba Vamos a crear una pagina de ejemplo, para tener algo que mostrar al crear el server block. Ya que aun no subimos un proyecto de rails. Crear un archivo index.html dentro de nuestro proyecto.

1

$ vim ~/www/example/index.html

Dentro del archivo escribiremos esto:

1 2 3 4 5 6 7 8

Bienvenidos a Example.com
El server block esta funcionando!

Ahora guardamos y cerramos el archivo index.html 3. Crear el server block para nuestro proyecto Ahora que tenemos contenido para servir, necesitamos crear el server block que le ‘dirá’ a Nginx como hacer esto. Por defecto Nginx viene con un server block llamado default que usaremos como base para nuestros propios servers. Este se encuentra en el directorio /etc/nginx/sites-available/ , en este directorio creamos los server block que necesitamos. Para hacer esto copiaremos el archivo default, y el nombre que usaremos es el mismo nombre de la carpeta que nos creamos anteriormente:

1

$ sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/examp

Ahora abrimos el archivo recién creado:

1

$ sudo vim /etc/nginx/sites-available/example

Y eliminamos todo lo que esta en el y escribimos lo siguiente:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; server_name example.com www.example.com; passenger_enabled on; rails_env production; root /home/deploy/www/example;

# redirect server error pages to the static page /50x.html error_page 500 502 503 504 /50x.html; location = /50x.html { root html; }

}

Importante: todas las declaraciones terminan con un punto y coma

;

Las líneas 2 y 3 le dicen que puerto tiene que escuchar, en el caso de un request del tipo http el puerto es 80, y con el parámetro default_server le decimos que, en el caso de que se haga un request a un server_name que no coincide con ninguno de los server block disponibles, se cargue este server block; Solo uno de nuestros server block puede tener la especificación de default_server!!! En la línea 5 seteamos a que requests responderá este server block, en este caso example.com, y ademas podemos añadir alias, en este caso www.example.com, separados por un espacio. En la línea 7 activamos passenger para este server block. En la línea 8 seteamos en ambiente de rails que vamos a ejecutar, en este caso el ambiente de producción. En la línea 10 con la directiva root apuntamos al directorio de nuestro proyecto, el path tiene que ser absoluto. OJO Cuando estamos trabajando con una aplicación de rails la ruta queda así: root /home/deploy/www/example/current/public; De la línea 12 a la 16 le estamos diciendo que las paginas de error de servidor apunten a una pagina estática. Guardamos el archivo y lo cerramos. 4. Habilitar el server block

Ahora que tenemos nuestro server block creado, tenemos que habilitarlo. Esto se hace creando un enlace simbólico de nuestro server block, que se encuentra en el directorio /etc/nginx/sites-available/ , en el directorio /etc/nginx/sites-enabled , este es el directorio que Nginx lee cuando se inicia el servidor. Podemos crear los links de la siguiente manera:

1

$ sudo ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/

Ahora nuestro archivo se encuentra habilitado, pero también se encuentra habilitado el archivo default que usamos para crear nuestro server block y esto nos dará problemas ya que como lo mencione anteriormente el parámetro default_server solo puede estar en un server block. Para arreglar esto simplemente eliminamos el enlace simbólico a este:

1

$ sudo rm /etc/nginx/sites-enabled/default

Ahora solo falta reiniciar Nginx:

1

$ sudo service nginx restart

5. Probando nuestro server block Para probar si todo salió bien, en el navegador vamos a visitar nuestro servidor, como aun no tenemos un dominio usaremos la ip de la maquina, en el caso de esta guía seria http://111.11.111.11. Deberíamos ver el mensaje que pusimos en nuestro archivo index.

Paso 7 – Ultimos detalles servidor

Para que nuestra aplicación RoR funcione bien y en caso de usar capistrano para hacer el deployment, tenemos que instalar los siguientes paquetes:

1 2 3 4

$ $ $ $

sudo sudo sudo sudo

apt-get update apt-get install git # necesario para el uso de capistrano apt-get install nodejs # obligatorio tener un ambiente js en el VPS apt-get upgrade

Con esto ya hemos terminado de configurar y dejar lista nuestra VPS para el deployment de una

aplicación RoR

Extras Algunos comandos importantes

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ ssh deply@ip_del_servidor $ sudo apt-get install paquete $ sudo apt-get update $ sudo apt-get upgrade $ sudo -u postgres psql $ $ $ $

sudo sudo sudo sudo

service nginx service nginx service nginx service nginx

stop start reload restart

$ sudo ln -s ruta/original/archivo ruta/destino $ sudo tail -n 50 /var/log/nginx/error.log

38) Deployment con Capistrano. Introducción Cuando yo estaba aprendiendo Rails, como un novato, no tenía ni idea de cómo llegar de esta cosa que estaba trabajando en mi máquina de desarrollo a un verdadero servidor web que otras personas pudieran ver. Todas estas cosas Unix CLI (Command Line Interface o terminal) parecían como magia negra para mí (probablemente, en parte porque mi terminal es de color negro) y me sentí como que necesitaba un doctorado en Cirugía Robótica para poder hacerlo. Rails ha hecho tan fácil el desarrollo de aplicaciones! Seguramente existe una manera de hacer deploy a mis creaciones sin que explote mi cabeza!!! Bueno, si y no. Servicios como Heroku están tratando de quitar una gran parte de la complejidad a la hora de hacer deploy una aplicaciones web, y están haciendo un buen trabajo. Pero como yo estaba tratando de aprender sentí que aquellos servicios no me ayudaban a comprender lo que se estaba haciendo. Sentía que al menos en la CLI, estaba en control y podia ver con mis propios ojos lo que estaba pasando (o lo que no estaba pasando). Y así, poco a poco logre comprender un poco mas cómo mi servidor web funcionaba. En un principio hice todo manualmente (la copia de archivos, la migración de bases de datos, la instalación de las gemas, reiniciar servicios, etc). Pero rápidamente me di cuenta de por qué nadie hace esto!!! En primer lugar, es terriblemente propenso a errores escribir todos los comandos con mis torpes manos humanas. En segundo lugar, a veces las cosas no funcionaban y yo no sabía por qué, y tenia que pasar horas averiguando dónde fue que perdí un signo o puse uno de mas. La moraleja de la historia es: encontrar la manera de hacerlo una vez, y después, guardarlo en un script que se pueda repetir sin problemas (aparentemente los computadores (ordenadores) son muy buenos haciendo lo mismo una y otra vez; ¿quién sabe?). Y es por eso que uso Capistrano y Git! Configuraremos nuestra aplicación de Rails para hacer deploy en el servidor remoto utilizando Capistrano y Git para que este proceso de implementación sea automatizado, rápido y libre de dolores de cabeza. Creo que los dos aspectos clave de cualquier proceso de implementación son la velocidad y consistencia. Velocidad significa que podemos repetir y corregir errores rápido y mantener nuestro código de producción en sintonía con nuestro código de desarrollo. Consistencia significa que sabemos que va a hacer lo mismo cada vez, así que no t endremos miedo de hacerlo y estar al día. El uso de un sistema de control de versiones como Git, junto con las recetas de implementación automatizadas de Capistrano satisface estos criterios con facilidad.

Acerca de esta guía. En esta guía usaremos un servidor remoto que tenga Ubuntu, Passenger y Nginx instalados y configurados, así como también acceso SSH a este. Si no t ienes un servidor remoto con los requerimientos antes mencionados, te recomiendo que sigas la guía " Rails y Nginx con Passenger en

Ubuntu: Preparando nuestro entorno de producción ", que disponible para servidores Amazon,

DigitalOcean o Linode. Se espera que el lector de esta guía sepa como utilizar la terminal y tenga conocimiento de al menos comandos básicos de este. Así como también se espera sepan usar postgres.

Convenciones. 1. Los términos servidor, server o VPS hacen referencia a su maquina virtual. 2. El termino local hace referencia a su computador. 3. Para determinar el entorno en que tenemos que ejecutar los comandos y en cual estaremos trabajando en cada sección se usara: local para la maquina local o servidor para la maquina virtual. 4. Se usara para los ejemplos la IP: 111.11.111.11 , esta tienen que ser remplazada por la ip de su maquina virtual. 5. Debes tener Git instalado y tener una cuenta en Github o en Bitbucket. Y saber usarlos. 6. Para mostrar las instrucciones a ejecutar en el terminal se antepondrá el signo $ , que es la representación de su línea de comandos que esta lista para recibir una instrucción ( no hay que tipearlo ), y tendrán el siguiente estilo:

1

$ gem install postgres

*Cada línea que empieza con

$ se ejecuta por separado.

Para mostrar las respuestas, errores o advertencias que nos arroja el terminal al ejecutar una instrucción no se antepone el signo $ y tendrán el siguiente estilo:

1

Agent pid 32877

Paso 0 – La Aplicación local

Para empezar, vamos a necesitar algo para implementar Capistrano y hacer deploy. Para eso vamos a crear una aplicación sencilla aquí (el proceso de implementación debe ser más o menos el mismo, independientemente de lo que esté haciendo su aplicación). Mi objetivo, aquí, es explicar un método muy simple para la automatización de sus deployments para darle un lugar donde empezar. Quizás esta no es la manera más rápida o la manera más elegante, pero va a hacer su proceso coherente, y sin duda será mucho más rápido que hacerlo manualmente. Mi pensamiento es que si funciona, al menos ustedes

pueden darse el tiempo para aprender las técnicas más avanzadas. Empecemos: 1. Crear una aplicación de tareas (usando Postgres porque eso es lo que he instalado en mi servidor): Vamos a crear una pequeña aplicación de tareas con rails y vamos a hacer un sca !old y vamos a revisar que funcione!

1 2 3 4 5 6

$ $ $ $ $ $

rails new todoapp -d postgresql cd todoapp bundle install rails g scaffold todo name:string finished:boolean rake db:migrate rails s

Listo tenemos nuestra aplicación creada, no hace mucho, pero nos servirá para lo que necesitamos. De ahora en adelante trabajaremos en la carpeta de nuestra app en la terminal

2. Iniciar GIT y el repo en Github Antes de instalar capistrano, es muy importante que nuestra aplicación este en un sistema de control de versiones. Para eso vamos a "gittear" nuestra app. Recuerden que es muy importante , antes de hacer cualquier commit, crear el archivo .gitignore y añadir los archivos con información sensible a este. Por ejemplo el config/database.yml , config/secrets.yml y el .env en caso de estar usando la gema dotenv-rails .

1 2 3

$ git init $ git add --all $ git commit -m 'Primer Commit'

Ahora que nuestra app esta "gitteada", tienen que ir a su cuenta en Github o en bitbucket y crear un repositorio nuevo en donde pushearemos nuestra app, yo los espero aquí mientras tanto… … … Ok ahora que tenemos nuestro repo creado vamos a configurar nuestra app para linkearla con el. En los ejemplos usare github!

1

$ git remote add origin [email protected]:username/your-repo-name.git

Una vez linkeado, pushearemos la app para que este disponible en nuestro repo.

1

$ git push -u origin master

Listo, podemos seguir con capistrano!!!

Paso 1 – Añadir Capistrano a nuestra app. Entonces, ¿qué es Capistrano? Capistrano es una aplicación open-source escrita en Ruby para automatizar tareas en uno o varios servidores remotos via SSH e incluye un conjunto de flujos de trabajo de implementación predeterminados. La instalación de Capistrano es tan fácil como añadir la gema al Gemfile de nuestra aplicación y ejecutar bundle install. Nosotros no necesitamos Capistrano en el servidor de producción, por lo que la añadimos bajo el grupo de "desarrollo" del Gemfile. Como referencia, estoy usando la ultima version ‘3.4.0’ 1. Abrimos nuestra app en nuestro editor de texto favorito (para mi ese es Sublime Text 3. ) y vamos a editar nuestro archivo gemfile y añadimos lo siguiente:

1 2 3 4 5 6 7 8

group :development do gem 'capistrano' gem 'capistrano-bundler' gem 'capistrano-rails' gem 'capistrano-rvm' gem 'capistrano-passenger' gem 'capistrano-ssh-doctor' end

Oye, pero ahi añadimos mas de una gema!!! Tranquilos, ahora voy a explicar que es cada una de ellas. gem 'capistrano' : es la que nos permitirá instalar capistrano y ejecutar sus tareas. gem 'capistrano-bundler' : añade la tarea bundler:install a Capistrano, y se ejecuta automáticamente en el servidor remoto como parte de las tareas que se realizan cuando hacemos un deploy con capistrano. gem 'capistrano-rails' : añade 2 tareas especificas a Capistrano, deploy:migrate y deploy:compile_assets , y se ejecutan automáticamente en el servidor remoto como parte

de las tareas que se realizan cuando hacemos un deploy con capistrano. gem 'capistrano-rvm' : Asegura que todas las tareas usen la version de Ruby correcta y le dice a capistrano que use rvm ... do ... para correr rake, bundle, gem y ruby. gem 'capistrano-passenger' : Añade la tarea passenger:restart , y reiniciará el

servidor passenger después de hacer un deploy con capistrano.

gem 'capistrano-ssh-doctor' : Añade la tarea ssh:doctor , para verificar si las conexiones mediante ssh están correctas y si no ayudarnos a resolverlas.

2. Ahora el respectivo bundle Recuerden que estamos trabajando en el directorio de nuestro proyecto

1

$ bundle install

3. Y ahora instalamos Capistrano (o "capify" nuestro proyecto)

1

$ cap install

Esto va a crear los siguientes archivos:

1 2 3 4 5 6 7 8 9

!"" Capfile !"" config #

!"" deploy

#

#

!"" production.rb

#

#

$"" staging.rb

#

$"" deploy.rb

$"" lib $"" capistrano $"" tasks

En nuestro caso solo queremos tener un solo stage, el de producción, para eso lo instalamos así: ~~~bash $ cap install STAGES=production ~~~ Esto va a crear los siguientes archivos:

1 2 3 4 5 6 7 8

!"" Capfile !"" config #

!"" deploy

#

#

#

$"" deploy.rb

$"" production.rb

$"" lib $"" capistrano $"" tasks

¿Para que tener distintos stages? Sirven por si queremos tener configuraciones especificas para diferentes deployments de nuestro proyecto. Listo, nuestro proyecto esta "capify". En la siguiente sección prepararemos nuestro proyecto!

Paso 2 – Preparación de nuestro proyecto En esta sección vamos a revisar cada archivo que la instalación de capistrano creo, vamos a entender que hacen y los vamos a editar con nuestras preferencias. 1. Capfile El archivo Capfile que se encuentra en la raíz de nuestro proyecto es la primera capa de configuración de capistrano, es decir, contiene la instrucciones iniciales que le dirán a Capistrano que plugins incluir y que tareas tendremos disponibles para usar. El archivo recién creado se ve así:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

# Load DSL and set up stages require 'capistrano/setup' # Include default deployment tasks require 'capistrano/deploy' # # # # # # # # # # # # # # # # # #

Include tasks from other gems included in your Gemfile For documentation on these, see for example: https://github.com/capistrano/rvm https://github.com/capistrano/rbenv https://github.com/capistrano/chruby https://github.com/capistrano/bundler https://github.com/capistrano/rails https://github.com/capistrano/passenger require require require require require require require

'capistrano/rvm' 'capistrano/rbenv' 'capistrano/chruby' 'capistrano/bundler' 'capistrano/rails/assets' 'capistrano/rails/migrations' 'capistrano/passenger'

# Load custom tasks from `lib/capistrano/tasks` if you have any defined Dir.glob('lib/capistrano/tasks/*.rake').each { |r| import r }

Como vemos, tenemos varias líneas comentadas por lo que vamos a editar el archivo e incluir los plugins que necesitamos en nuestro proyecto, estos están relacionados con las gemas que agregamos al gemfile y limpiar lo que no necesitamos. El archivo tiene que quedar asi:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

# Load DSL and set up stages require 'capistrano/setup' # Include default deployment tasks require 'capistrano/deploy' # Include tasks from other gems included in your Gemfile require 'capistrano/rvm' require 'capistrano/bundler' require 'capistrano/rails' require 'capistrano/passenger' require 'capistrano/ssh_doctor' # Load custom tasks from `lib/capistrano/tasks` if you have any defined Dir.glob('lib/capistrano/tasks/*.rake').each { |r| import r }

Ahora tenemos todas las tareas extras, de las gemas de capistrano que agregamos, disponibles para usar al hacer deploy. 2. deploy.rb El archivo deploy.rb que se encuentra en config/deploy.rb de nuestro proyecto (no confundir con la carpeta deploy que también esta dentro de config), es donde configuraremos las variables globales de Capistrano; globales porque afectan a todos los stages que tengamos creados. Al igual que el archivo Capfile, este viene con contenido por defecto y lo vamos a remplazar por lo siguiente:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

# config valid only for current version of Capistrano lock '3.4.0' set :rvm_type, :user set :rvm_ruby_version, '2.2.2' set set set set set

:application, 'YourApplicationName' :deploy_to, "/home/username/#{fetch(:application)}" :scm, :git :repo_url, '[email protected]:your-username/your-repository-name.git' :branch, 'master'

set :linked_files, %w{config/database.yml config/secrets.yml .env} set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets vendor/bundle pub set :keep_releases, 4

Ahora les voy a explicar que es lo que estamos haciendo en este archivo: lock : seteamos la version de capistrano que estamos usando.

set :rvm_type : le decimos cual es el path de rvm a usar. En nuestro caso el el path desde el user. set :rvm_ruby_version : seteamos que version de ruby queremos usar de las que tenemos instaladas con rvm en el servidor. set :application : el nombre de nuestra aplicación. set :deploy_to : la ruta en el servidor donde se hará el deploy. Remplazar username por "deploy" para digitalocean o linode y "ubuntu" para amazon. set :scm : que sistema de control de versiones estamos usando, en este caso git. set :repo_url : la url de nuestro repositorio donde tenemos pusheada la app. set :branch : el branch que queremos que se use para hacer el deploy. En este caso master. set :linked_files : listado de archivos que necesitamos que sean persistentes entre cada deploy mediante links simbólicos, aquí añadimos los archivos config/database.yml , config/secrets.yml y .env . Estos archivos TIENEN que estar en el .gitignore ya que NO los debemos subir a nuestro repo porque que contienen información sensible. set :linked_dirs : listado de directorios que necesitamos que sean persistentes entre cada

deploy mediante links simbólicos, por ejemplo: para no perder los archivos que se han subido a nuestra app cuando hacemos un nuevo deploy añadimos public/uploads . keep_releases : le decimos a capistrano que solo mantenga los ultimos X deploy y borre todo lo demas. En este caso 4.

Existen más variables que se pueden configurar, pero estas son las que, en la mayoría de los casos, vamos a necesitar cambiar. Para conocer que otras variables y profundizar en el tema les recomiendo que lean http://capistranorb.com/documentation/getting-started/configuration/ 3. production.rb Para las configuraciones que son especificas de cada stage, editamos cada uno de los archivos que tengamos en config/deploy/ . En este caso solo tenemos el stage production, que se encuentra en config/deploy/production.rb . Al igual que antes el archivo creado viene con contenido por defecto y lo vamos a remplazar por lo siguiente:

1 2 3 4

set :stage, :production set :rails_env, :production server '111.11.111.11', user: 'username', roles: %w{web app db}, primary: tru

Aqui va la explicación: :stage : le damos el nombre a nuestro stage, en este caso producción, que usaremos al hacer deploy. :rails_env : le decimos a rail que corra en el ambiente que necesitamos, en este caso

producción.

server... : En esta línea le decimos a Capistrano como tiene que acceder a nuestro vps. Le damos el ip de la maquina y el usuario con el cual conectarse, "deploy" en digitalocean o linode y "ubuntu" en amazon. La variable :roles le dice a capistrano que el server de PostgreSQL ( db ), el server de Nginx ( web ) y el server de passenger ( app ) corren el la misma maquina. La opción primary: true le dice a capistrano que este es nuestro server de base de datos primario

y correrá todas las migraciones en este. Estamos casi listos para hacer deploy, pero antes vamos a añadir unas tareas personalizadas a capistrano.

Paso 3 – Tareas personalizadas Por si no lo saben, Capistrano hace mucho de su trabajo con la ayuda de tareas. Por ejemplo, cuando hicimos cap install lo que hicimos fue invocar una tarea llamada "install" que crea los archivos y carpetas que hemos estado editando. Ahora nosotros vamos a crear nuestras propias tareas, para esto crearemos archivos .rake en la siguiente carpeta lib/capistrano/tasks para cada una de ellas. La primera nos ayudara a setear algunos archivos en el server, la segunda sera para limpiar nuestros assets en el server y la tercera para comprobar que nuestro repo esta al día antes de hacer deploy. 1. setup.rake Para el primer grupo de tareas crearemos el archivo setup.rake en lib/capistrano/tasks y escribimos lo siguiente:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

namespace :setup do desc "Upload database.yml file." task :database do on roles(:app) do execute "mkdir -p #{shared_path}/config" upload! StringIO.new(File.read("config/database.yml")), "#{shared_path} end end desc "Upload secrests.yml file." task :secrets do on roles(:app) do execute "mkdir -p #{shared_path}/config" upload! StringIO.new(File.read("config/secrets.yml")), "#{shared_path}/ end end desc "Upload .env file." task :env do on roles(:app) do execute "mkdir -p #{shared_path}/config" upload! StringIO.new(File.read(".env")), "#{shared_path}/.env" end end desc "Seed the database." task :seed do on roles(:app) do within "#{current_path}" do with rails_env: :production do execute :rake, "db:seed" end end end end end

Aquí hemos creado cuatro tareas bajo un namespace llamado :setup . ¿Recuerdan que los archivos config/database.yml , config/secrets.yml y .env están en el .gitignore ? Bueno, esto nos va a traer problemas y errores ya que no estarán disponibles al hacer deploy, por eso las tres primeras tareas se encargaran de subir estos archivos directamente al servidor sin pasar por nuestro repo. La primera tarea es :database . Esta se encarga de subir el archivo config/database.yml al servidor. La segunda tarea es :secrests . Esta se encarga de subir el archivo

config/secrets.yml al servidor.

La tercera tarea es :env . Esta se encarga de subir el archivo

/.env al servidor.

En el caso de la tarea :env , solo lo usaremos si estamos trabajando con la gema dotenv-rails , y si es así, esta gema tiene que estar disponible en el ambiente de producción, ósea, sacarla del grupo development de nuestro gemfile. La cuarta tares es :seed . Esta se encarga de ejecutar rake db:seed en el servidor si lo necesitamos. 2. assets.rake Ahora crearemos el archivo assets.rake en lib/capistrano/tasks y escribimos lo siguiente:

1 2 3 4 5 6 7 8 9 10 11 12 13

namespace :clean do desc 'Runs rake assets:clobber on server to remove compiled assets' task :assets do on roles(:app) do within "#{current_path}" do with rails_env: :production do execute :rake, 'assets:clobber' execute :touch, release_path.join('tmp/restart.txt') end end end end end

La tarea que hemos creado se llama :assets y esta bajo el namespace :clean , esta tarea lo que hace es eliminar todos los assets en el servidor en caso de que estos nos estén causando problemas. 3. deploy.rake Ahora crearemos el archivo deploy.rake en lib/capistrano/tasks y escribimos lo siguiente:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

namespace :deploy do desc "Makes sure local git is in sync with remote." task :check_revision do unless `git rev-parse HEAD` == `git rev-parse origin/master` puts "WARNING: HEAD is not the same as origin/master" puts "Run `git push` to sync changes." exit end end before :deploy, "deploy:check_revision" end

Esta tarea se encargara de revisar si nuestro repo esta al día con los cambios locales antes de hacer el deploy. Si no es así, se cancelara el deploy y nos dará una advertencia. Estamos listos con las tareas personalizadas!

Paso 4 – Conectando el servidor con el repositorio Para este paso es necesario tener el servidor configurado y haber seguido la guía " Rails y Nginx con Passenger en Ubuntu: Preparando nuestro entorno de producción" Como ya sabemos, capistrano usa git y un repositorio para automatizar nuestro deployment. Es por esto que es necesario que nuestro servidor tenga acceso a este repositorio y se pueda autenticar automáticamente cuando se hace el deployment. Para esto usaremos ssh y deploy keys *Todos los comando que usaremos a continuacion tienen que ser ejecutados en el servidor remoto (AWS o DO).

1. Lo primero que tenemos que hacer es revisar si existe alguna llave ssh en nuestro servidor. Para eso entramos al servidor desde nuestro terminal y ejecutamos:

1

$ ls -al ~/.ssh

Si en el listado tenemos alguna llave publica ssh, del tipo id_rsa.pub o terminado en .pub , podemos usarla para la conexión. En caso contrario crearemos una nueva llave. 2. Creación de una llave ssh en nuestro servidor

1

$ ssh-keygen -t rsa -b 4096 -C "[email protected]"

Es recomendable usar las opciones por defecto como estan, por lo que cuando nos pregunte "en que archivo queremos guardar la llave" simplemente de damos Enter

1

Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]

Se nos pedirá crear una password

1 2

Enter passphrase (empty for no passphrase): [Type a passphrase] Enter same passphrase again: [Type passphrase again]

Finalmente se nos mostrara la ‘huella’ o id de nuestra llave ssh. Sera algo parecido a esto:

1 2 3 4

Your identification has been saved in /Users/you/.ssh/id_rsa. Your public key has been saved in /Users/you/.ssh/id_rsa.pub. The key fingerprint is: 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db [email protected]

3. Copiar la llave publica de nuestro servidor Para copiar la llave en ubuntu tendremos que installar

1

xclip

$ sudo apt-get install xclip

Una vez instalado ejecutamos:

1

$ xclip -sel clip < ~/.ssh/id_rsa.pub

4. Pegar la llave publica en nuestro repositorio como una deploy key Una deploy key es una llave ssh que se guardara en el repositorio de nuestro proyecto (github o bitbucket) y permitirá que capistrano se pueda autenticar en el. Esta llave solo esta vinculada con el repositorio y no con nuestra cuenta. Lo primero que tenemos que hacer es entrar a nuestra cuenta de Github o Bitbucket e ir al repositorio del proyecto al cual le vamos hacer deployment

Añadir la llave en Github

1 2 3 4 5

![Timezone 1](https://dl.dropboxusercontent.com/s/0j63ztcppxkr0am/github-01.png ![Timezone 1](https://dl.dropboxusercontent.com/s/9957iuj75a1zw8a/github-02.png ![Timezone 1](https://dl.dropboxusercontent.com/s/ol0c5ms7igichqv/github-03.png

Añadir la llave en Bitbucket

Una ves añadidas las llaves a nuestro repositorio estamos listos para continuar.

Paso 5 – Deploy! Cómo se hace? y qué hace?

Ok, tenemos todo listo para seguir, Capistrano instalado y configurado y tareas personalizadas creadas. Solo nos falta hacer el push a nuestro repo con todos los cambios que hemos echo hasta ahora.

1 2 3

$ git add --all $ git commit -m 'Add Capistrano and custom task' $ git push origin master

Listo, ahora si, como hacemos el deploy. Hacer un deploy es tan fácil como escribir esto en la consola en el root de nuestro proyecto:

1

$ cap production deploy

La instrucción anterior esta compuesta de 3 partes, cap hace referencia a Capistrano, production es el stage que vamos a usar, y deploy es la tarea a realizar en el stage. Podemos ejecutar cualquier tarea que tengamos disponible. Para ver cuales son (incluidas las nuestras) ejecutamos lo siguiente:

1

$ cap -T

Esto nos devolverá un listado de todas las tareas que podemos usar y su descripción; de toda esa lista las tareas que más usaremos y las que nos interesan son:

1 2 3 4 5 6 7

cap cap cap cap cap cap cap

deploy deploy:check setup:database setup:secrets setup:env setup:seed ssh:doctor

# # # # # # #

Deploy a new release Check required files and directories exist Upload database.yml file Upload secrests.yml file Upload .env file Seed the database Perform ssh doctor

Si ya ejecutaron cap production deploy lo mas probable es que les arrojara un error y no se completara la tarea. No nos preocuparemos de eso por ahora. Primero vamos a entender que pasa cuando ejecutamos cap production deploy . Capistrano utiliza una jerarquía de directorios estrictamente definido en cada servidor remoto para organizar el código fuente y otros datos relacionados con el deployment. La ruta raíz de esta estructura es la definida en la variable de configuración: :deploy_to que modificamos en el archivo config/deploy.rb Si revisamos la ruta raíz e inspeccionamos los directorios veremos algo como esto:

1 2 3 4 5 6 7 8 9 10 11 12

!"" current -> /var/www/my_app_name/releases/20150120114500/ !"" releases #

!"" 20150080072500

#

!"" 20150090083000

#

!"" 20150100093500

#

!"" 20150110104000

#

$"" 20150120114500

!"" repo #

$""

!"" revisions.log $"" shared $""

/releases : cada vez que se hace un deploy un nuevo directorio se creara aquí, y contiene todo el código de ese deploy. /current : es un enlace simbólico que apunta al último directorio creado en

/releases .

/shared : mantiene los archivos y directorios que son persistentes a lo largo de los deploy. /repo : contiene un clon de su .git. /shared , encontraremos: Dentro de la carpeta /shared

1 2 3 4 5 6 7 8 9

$"" shared !"" .env !"" config !"" public !"" log !"" tmp !"" bin !"" bundle $"" vendor

Los que nos interesan son: .env : el archivo que contendrá nuestras variables privadas. /config : tendrá nuestro database.yml y secret.yml . /log : contiene el production.log . Este tendrá todo el historial de nuestra app, no solo del ultimo deploy. /public : contiene todos los assets y también la carpeta upload en nuestro caso.

Cuando corremos cap production deploy lo que estamos haciendo es llamar una tarea de Capistrano llamada deploy, quede manera secuencial invocara otras tareas. Las principales son: starting : crea la estructura de directorios y comprueba que puede obtener el repo de github. updating : copia el repo de github a un nuevo directorio en /releases , y añade los links

simbólicos que apuntan a /shared , corre Bundler, las migraciones y compila los assets. publishing : crea el links simbólico entre /current y el nuevo directorio en /releases . Solo si no hubo errores en alguna de las tareas anteriores. finishing : elimina los directorios mas antiguos de

/releases .

En caso de que Capistrano se encuentre con un error en el momento de hacer deploy y no termine la tarea completa, /current siempre apuntara a la ultimo directorio de /releases que estaba funcionando, de esta manera el sitio siempre estará disponible.

Ahora que sabemos cómo y qué hace Capistrano haremos un deploy de nuestra app 1. Si es el primer deploy de nuestra app, ejecutaremos las siguientes tareas, una a una, en el orden en que aparecen a continuación:

1 2 3 4 5

$ $ $ $ $

cap cap cap cap cap

production production production production production

ssh:doctor setup:database setup:secrets setup:env deploy

ssh:doctor : comprueba que todas las conexiones mediante ssh estén correctas. setup:database|secrets| : suben los archivos database y secrets respectivamente. si falta alguno de ellos el deploy nos dará error. setup:env : sube el archivo .env , este solo se ejecuta si estamos utilizando la gema dotenv-rails en nuestro proyecto para definir variables de configuración privadas. deploy : finalmente ejecutamos deploy.

Si siguieron todos los pasos de esta guía y los de la guía de "Rails y Nginx con Passenger en Ubuntu…" no deberían tener ningún error. En el caso de que el deploy nos de un error, revisaremos bien los mensajes que nos da la terminal y buscaremos en google alguna respuesta. 2. Para los siguientes deploys de la misma app, solo ejecutaremos

1

$ cap production deploy

*Sólo en caso de que cambiemos algún dato en database.yml , secrets.yml o .env

volvemos a ejecutar la tarea correspondiente a cada archivo. Si ahora abrimos nuestro navegador favorito (espero que no sesea Internet Explorer) y escribimos la dirección IP de nuestro servidor en la barra de direcciones, podremos ver nuestra aplicación; si no la

vemos, no se preocupen. La implementación es difícil y toma un tiempo para asimilar. Si las cosas no funcionan, lo mejor es comenzar con los registros y googlear cualquier error que encontremos allí. Pero lo más importante es no desanimarse. Cuando quise configurar mi servidor de producción a partir de cero la primera vez, me llevó una semana completa ( no estoy bromeando) para que funcionara. Fue frustrante, desalentador, y es la razón por la que me decidí a escribir esta guía (ademas de que me la pidieron los alumnos :D), porque no quiero que otras personas que pasan por lo mismo. No tiene por qué ser de esa manera, y espero que no sea así.

Genero	Selecionar
<%= genre.name %>	<%= check_box_tag 'genres_ids[]', genre.id, 'Yes' %>
<%= genre.name %>	<%= check_box_tag 'genres_ids[]', genre.id %>

Libro Rails (2)

Recommend Documents

New Task

<%= pluralize(@task.errors.count, "error") %> prohibited this task fro <% @task.errors.full_messages.each do |message| %> <%= message %> <% end %>

<%= pluralize(@task.errors.count, "error") %> prohibited this task fro <% @task.errors.full_messages.each do |message| %> <%= message %> <% end %>

Generos

Welcome to example.com, <%= @user.name %>

El server block esta funcionando!

<%= pluralize(@task.errors.count, "error") %> prohibited this task fro
<% @task.errors.full_messages.each do |message| %>
<%= message %>
<% end %>

<%= pluralize(@task.errors.count, "error") %> prohibited this task fro
<% @task.errors.full_messages.each do |message| %>
<%= message %>
<% end %>