Segunda aplicacion, parte II

Después de generar y explorar los recursos de los usuarios, vamos a trabajar sobre los recursos Microposts que van a estar relacionados con los usuarios.

Al igual que con los recursos de usuarios, vamos a generar el código con scaffold para el recurso Microposts

$rails generate scaffold Micropost content:string user_id:integer

Para actualizar nuestra base de datos con el nuevo modelo de datos, es necesario ejecutar:

$ rake db:migrate

Ahora estamos en condiciones de crear microposts de la misma manera que hemos creado los usuarios.

El comando scaffold ha actualizado el archivo de ruteo de Rails con una regla para los recursos Microposts, el contenido se encuentra en el archivo config/routes.rb.

Al igual que con los usuarios, la regla del ruteo resources: microposts mapea las URLs de los microposts con las acciones en el controlador Microposts, como vemos en la Tabla.

HTTP request URL Action Proposito
GET index Pagina para listar todos los micropost
GET show Pagina para mostrar el micropost con id 1
GET new Pagina para crear un nuevo micropost
POST create Crea un nuevo micropost
GET edit Edita el micripost con id 1
PUT update Actualiza el micropost con id 1
DELETE destroy Elimina el micropost con id 1

El controlador de microposts aparece en forma esquematica en el archivo app/controller/microposts_controller.rb, el contenido es casi identico al que se encuentra en el archivo app/controller/users_controller.rb

class Micropostscontroller < Applicationcontroller

def index

end

def show

end

def new

end

def edit

end

def create

end

def update

end

def destroy

end

end

Vamos a insertar algunos micropost, en la url http://localhost:3000/microposts/new en el campo user, insertar el id 1, o algun id de usuario que estemos seguros haber insertado.

Para hacer los micropost similares a twitter vamos a poner una restriccion del tamaño de caracteres permitidos (140), para eso usaremos una validacion.

Editar el archivo app/models/micropost.rb y le agregamos lo siguiente

validates :content, :length => { :maximum => 140 }

class Micropost < ActiveRecord::Base

validates :content, :length => { :maximum => 140 }

end

Con la validacion que hemos agregado, si excedemos los 140 caracteres tendremos un mensaje de error como el siguiente

Un usuario tiene muchos micropost

Una de las características más potentes de Rails es la capacidad para formar asociaciones entre los diferentes modelos de datos. En el caso de nuestro modelo de usuario, cada usuario tiene muchos microposts.

Para implementar esto en código vamos a editar el archivo app/models/user.rb

y le agregamos lo siguiente has_many :microposts y el archivo app/models/micropost.rb le agregamos belongs_to :user y nos queda de la siguiente manera

class User < ActiveRecord::Base

has_many :microposts

end

class Micropost < ActiveRecord::Base

belongs_to :user

validates :content, :length => { :maximum => 140 }

end

Por ahora, podemos examinar la asociación de usuarios-micropost mediante la consola, una herramienta útil para interactuar con aplicaciones Rails.
Primero invocamos la consola con rails console y luego recuperar el primer usuario de la base de datos y la asignamos a una valiable utilizando first_user = User.first

Como pueden ver para obtener los microposts asociados ejecutamos first_user.microposts

MVC de nuestra segunda aplicación

Continuamos con la explicación de parte de lo que hicimos en nuestra segunda aplicación, veamos un resumen rápido de los recursos de usuarios, vamos a examinar una parte de él en el contexto del Modelo-View-Controller (MVC) con una consulta.

El proceso para obtener los usuarios fluye de la siguiente manera

    1. El explorador manda una solicitud a la URL de /users

    2. Rails rutea /users a la accion index del users model.

    3. La accion index pregunta al users model por todos los usuarios (User.all).

    4. El users model obtiene todos los usuarios de la base de datos.

    5. El users model devuelve la lista de usuarios al controlador (controller).

    6. El controlador pone los usuarios en la variable @users, que se pasa al index view

    7. La vista utiliza Ruby incrustado para representar la página como HTML.

    8. El controlador pasa el código HTML al browser.

Comenzamos con una petición desde el navegador, es decir, el resultado de escribir una dirección URL en la barra de direcciones o hacer clic en un enlace (Paso 1).

Esta petición llega a Rails router (Paso 2), que envía a la acción al controlador apropiado (controller action) que se basa en la URL.

El código para mapear las URLs con las acciones del controlador para el recurso de los usuarios se encuentra en demo_app/config/routes.rb, en la tabla se muestra la acción que le corresponde a cada url, y el proposito de cada una.

URL

Action

Proposito

/users

index

Pagina que lista todos los usuarios

/users/1

show

Muestra el usuario con id 1

/users/new

new

Pagina para crear un nuevo usuario

/users/1/edit

edit

Pagina para editar el usuario con el id 1

Las páginas de nuestra aplicación (para realizar las operaciones de crear, eliminar, editar y mostrar los usuarios) corresponden a las acciones en el controlador de usuarios, es una coleccion de acciones relacionadas, el controlador que fue generado mediante el comando scaffolding se encuentra en el archivo app/controllers/users_controller.rb

Tengan en cuenta la notación class UsersController <ApplicationController, es un ejemplo de una clase de Ruby con herencia.

Si revisan el codigo podrán notar que hay más acciones que no son páginas, las acciones index, show, new, y edit, todas corresponden al modelo de usuarios, pero hay otras adicionales create, update, y destroy.

Estas acciones no suelen representar páginas (aunque a veces lo hacen), sino que su objetivo principal es modificar la información sobre los usuarios en la base de datos. El conjunto completo de las acciones del controlador, se resumen en la tabla siguiente

HTTP request

URL

Action

Propósito

GET

/users

index

Página para listar todos los usuarios

GET

/users/1

show

Página para mostrar el usuario con id 1

GET

/users/new

new

Página para crear un nuevo usuario

POST

/users

create

Crea un nuevo usuario

GET

/users/1/edit

edit

Página para edtar el usuario con id 1

PUT

/users/1

update

Actualiza el usuario con id 1

DELETE

/users/1

destroy

Elimina el usuario con id 1

Notar que en la tabla existe cierta superposición en las direcciones URL, por ejemplo, tanto la acción show y la acción update correspondientes a la URL /users/1. La diferencia entre ellos es el método de petición HTTP que responden (GET vs PUT). Eso lo veremos mas adelante

Para examinar la relación entre el controlador de usuarios y el modelo de usuario, vamos a revisar el archivo app/controllers/users_controller.rb

Esta acción tiene la línea @users = @User.all (Paso 3), quien pide al User model una lista de todos los usuarios de la base de datos (Paso 4), y luego los coloca en la variable @users (se pronuncia “at users”) (Paso 5).

El User model en sí aparece en el archivo app/models/user.rb, aunque es bastante simple, tiene una gran funcionalidad debido a la herencia que mencionamos eso lo veremos mas adelante. En particular, por el uso de una de las librerias de Rails llamada Active Record, el código de app/models/user.rb se encarga de la operacion User.all para devolver todos los usuarios.

Una vez que la variable @users se define, el controlador llama a la vista (Paso 6), esa vista se encuentra en el archivo app/views/users/index.html.erb.

Las variables que comienzan con el signo @, llamadas variables de instancia, automáticamente están disponibles para la vista(view), en este caso, la vista index.html.erb (archivo app/views/users/index.html.erb) itera a través de la lista @users y cada user lo va poniendo en HTML.

La vista convierte su contenido ToHTML(Paso 7), se devuelve por el controlador para que el navegador lo muestre(Paso 8).

Los inconvenientes de este recurso de usuarios

A pesar de bueno para conseguir una visión general de Rails, el recurso que obtuvimos con scaffold Users sufre de una serie de graves deficiencias.

    • No hay validaciones de datos. Nuestro modelo Usuario acepta datos como nombres y direcciones en blanco,el email no se válida.

    • No hay autenticación. No tenemos idea de quien se loguea o quien esta fuera, y no hay manera de evitar que cualquier usuario pueda realizar cualquier operación.

    • No hay pruebas. Esto no es técnicamente cierto, scaffolding incluye pruebas rudimentarias, pero las pruebas generadas son feas e inflexible, y no prueba la validación de datos, autenticación, o cualquier otro requisito necesario.

    • No tiene Layout. No hay un diseño o navegación de sitio consistente

    • No hay una verdadera comprensión. Para los que no usamos scaffolding

Transferencia de Estado Representacional (Representational State Transfer)

REST es un estilo arquitectónico para el desarrollo distribuido, sistemas de redes y aplicaciónes de software, tales como la WWW y las aplicaciones web.

Aunque la teoría de REST es más bien abstracto, en el contexto de Rails, las aplicaciónes REST significan que la mayoría de los componentes de la aplicación (por ejemplo, los usuarios y microposts) se modelan como recursos que se pueden crear, leer, actualizar y eliminar — operaciones que corresponden las operaciones CRUD de bases de datos relacionales.

REST describe todo un paradigma de arquitectura para aplicaciones que solicitan y manipulan recursos en la web utilizando los métodos estándar de HTTP: GET, POST,PUT y DELETE.

En REST todo recurso es una entidad direccionable mediante una URL única con la que se puede interactuar a través del protocolo HTTP.

Dichos recursos pueden representarse en diversos formatos como HTML, XML o RSS,segun lo solicite el cliente.

El estilo de desarrollo REST ayuda a que un desarrollador tome decisiones acerca de que controladores y que acciones escribir: simplemente la estructura de la aplicación que utiliza los recursos que se crean, leer, actualizar y eliminar.

Fuente

Desarrollo REST con Rails

Ubuntu problemas con Heroku

La solución propuesta para el error que tuve viene de este blog http://blog.project-sierra.de/archives/1534

Al igual que en el blog, después de instalar heroku con gem install heroku y ejecutar el comando: heroku create, obtuve un error como este

 

Para resolver este problema es necesario instalar la libreria libreadline-dev:

 sudo apt-get install libreadline-dev

 Luego nos situamos en el siguiente directorio

cd ~/.rvm/src/ruby-1.9.2-p290/ext/readline

 Ejecutamos los siguientes comandos

 ruby extconf.rb

make

make install

 

Y listo no debería de haber mayor complicación

Deployar Aplicación Ruby on Rails con Heroku

Deploying

Aun no tenemos una aplicación funcional, pero después de lo que hemos hecho, ya estamos listos para hacer nuestro primer deploy con la aplicación que creamos (fist_app), veamos el proceso de deployado para ir resolviendo problemas que nos podremos encontrar, y sobre todo ver de que se trata.

Dicen que el deployado ha sido algo complicado, pero ha mejorado mucho, eso lo veremos, hay varias opciones, puede ser en hosts compartidos, mediante servidores privados virtuales que corren Phusion Passenger (un módulo para Apache y servidores web Nginx24) particularmente no los había oido pero es solo comentario informativo, existen otros mas, pero no hablaremos de ellos y nos centraremos en el que vamos a utilizar

Heroku, suena como el nombre de alguna serie de anime xD, deployar con Heroku es realmente muy fácil.

Configuración de Heroku

Los que no tienen una cuenta primero crear una en https://api.heroku.com/signup, después de crear una y de loguearnos, nos situamos en la ruta de nuestro proyecto ( en mi caso es ~/rails_projects/first_app) y lo instalamos mediante el siguiente comando

 gem install heroku

 

Al igual que con GitHub con Heroku necesitamos crear claves SSH, y decirle a Heroku nuestra clave pública, eso ya lo hemos hecho con GitHub en mi caso no fue necesario realizar algo mas, para mas informacion http://devcenter.heroku.com/articles/quickstart#prerequisites

Finalmente usemos Heroku para crear un lugar en los servidores para nuesta aplicacion

$heroku create

Al hacer heroku create tuve errores, los resolví en esta entrada

El comando heroku crea un nuevo subdominio solo para nuestra aplicación, que rapidamente estará disponible.

Pasos para deployar

Para deployar en heroku, lo primero que tenemos que hacer es usar git para mandar la aplicación a heroku

 $git push heroku master

 Y vuala! Tenemos nuestra aplicación deployada

 Para ver nuestra aplicacion nos vamos a la direccion que obtuvimos al hacer heroku create, o mas facil ejecutamos

 $heroku open

 

Segunda aplicacion, agregando funcionalidad

Con varios ejercicios que hemos hecho en las entradas anteriores, nos hemos dado una idea general sobre el funcionamiento de ruby on rails.

Hoy realizaremos otra aplicacion pero le agregaremos algo de funcionalidad, solo para ver todo el poder que tiene rails, y comprobaremos lo realmente sencillo que es, a lo largo de este blog en cada entrada trabajaremos sobre la misma aplicacion, e iremos agregando funcionalidad y a la par veremos nuevos conceptos hasta que esta se convierta en algo realmente complejo,

Con el resultado de esta aplicacion podemos interactuar con la url, y nos vamos adrentar en su estructura, asi como tambien empezaremos a ver la arquitectura REST.

La aplicacion consiste en tener usuarios relacionados con micropost. Los comandos a continuacion los hemos visto en los post anteriores, asi que solo me remito a ejecutarlos

Crear la aplicación

$cd ~/rails_projects

$ rails new demo_app

$ cd demo_app

Editamos el archivo Gemfile y lo dejamos de la siguiente manera

$bundle install

Creamos nuestro repositorio git

$ git init

$ git add .

$ git commit -m “Initial commit”

Creamos nuestro repositorio gitHub

Para no perder la practica crearemos otro repositorio nuevo en la pagina GitHub y se llamara demo_app GH, luego ejecutaremos lo siguiente

$git remote add origin git@github.com:rozaRuby/demo_appGH.git

$git push origin master

Tipicamente el primer punto para realizar una aplicacion ruby es crear el data model, es una representacion de las estructuras que se van a necesitar en nuestra aplicacion. En nuestro caso, la aplicación será un microblog, con sólo usuarios y los mensajes cortos.

MODELO USUARIOS (USERS)

Los usuarios tendrán un identificador único llamado ID de tipo entero, un nombre disponible públicamente (de tipo string), y una dirección de correo (también string) que tambien puede ser el nombre de usuario. La tabla siguiente muestra como queremos a nuestro user.

user

id

integer

name

string

email

string

MODELO MICROPOST

El modelado de datos de micropost es más sencillo que ell usuarios: un micropost sólo tiene un identificador y un campo para el texto del micropost (de tipo string).
Para hacerlo mas interesante, vamos asociar cada micropost a un usuario concreto, mediante el campo user_id del dueño del post. Nuestro modelado queraria asi:

micropost

id integer
content string
user_id integer

RECURSOS DEL USUARIO

Vamos a implementar el modelado de datos de los usuarios, junto con una interfaz web para ese modelo. La combinación (la interfaz web y el modelado ) constituyen los recurso de usuarios(Users resource), que nos permitirá pensar en los usuarios como objetos que se pueden crear, leer, actualizar y eliminar a través de la web mediante el protocolo HTTP.
Los recursos de usuario serán creados por el programa generador llamado “scaffold”, viene incluido en cada proyecto Rails que generemos.

La palabra Scaffold está en inglés y en español significa Andamio, pero en programación el scaffolding es un método para contruir aplicaciones basadas en bases de datos, esta técnica está soportada por algunos frameworks del tipo MVC en el cuál el programador escribe una especificación que describe cómo debe ser usada la base de datos. Luego el compilador utiliza esa especificación para generar el código que la aplicación usará para crear, leer, actualizar y eliminar registros de la base de datos, esto es conocido cómo CRUD (create, read, update, delete).

Tomado de http://techtastico.com/post/que-es-el-scaffolding-o-scaffold/

El argumento para el comando scaffold es el nombre del recurso (en este caso, el User), seguido de parámetros opcionales que serian los atributos del modelo de datos:

En para el ejemplo que tenemos y guiandonos de la tabla que tenemos en el apartado MODELO USUARIOS, nos queda de la siguiente manera

$rails generate scaffold User name:string email:string

En el comando al incluir name:string, email:string, tenemos una estructura para el modelo de usuario (Tengan en cuenta que no hay necesidad de incluir un parámetro id,se crea automáticamente).

Para continuar con la aplicación, primero tenemos que migrar la base de datos utilizando el comando Rake:

$rake db:migrate

El comando anterior simplemente actualiza la base de datos con nuestro nuevo modelo de datos de usuario.

 Rake
En la tradición Unix, el comando make ha jugado un papel importante en la creación de programas ejecutables desde el código fuente, muchos programadores solo hacen lo siguiente

$ ./configure && make && sudo make install

comúnmente utilizado para compilar el código en los sistemas Unix (incluyendo Linux y Mac OS X).
Rake es Ruby make, Rails utiliza ampliamente Rake, especialmente para las innumerables tareas administrativas necesarias en el desarrollo aplicaciones web con BD.

El comando rake db:migrate es probablemente el más común, pero hay muchos otros, se puede ver una lista de tareas de base de datos con -T db:
$ rake -T db
Para ver todas las tareas Rake disponible, ejecuten
$ rake-T

Con esto, podemos ejecutar el servidor web local usando rails s, es un atajo de
rails server:

Tuve problemas al ejecutar mi aplicacion, para resolverlo tuve que hacer lo siguiente

http://cjohansen.no/en/ruby/ruby_version_manager_ubuntu_and_openssl

sudo apt-get install libssl-dev

cd ~/.rvm/src/ruby-1.8.7/ext/openssl

ruby extconf.rb

make && make install

Tour por nuestra aplicacion

La direccion http://localhost:3000/ muestra la mima pagina por defecto de Rails, pero al generar los recursos de usuarios con scaffolding también se han creado un gran número de páginas para la manipulación de los usuarios.

Por ejemplo, la página para mostrar todos los usuarios se encuentra en /users (http://localhost:3000/users), y la página para crear un nuevo usuario se encuentra en /users/new (http://localhost:3000/users/new)

A continuacion veamos el objetivo de cada pagina.

URL Action Proposito
/users

index

Pagina que lista todos los usuarios
/users/1

show

Muestra el usuario con id 1
/users/new

new

Pagina para crear un nuevo usuario
/users/1/edit

edit

Pagina para editar el usuario con el id 1

Control de versiones remotos GitHub

En los posts anteriores pusimos nuestro repositorio de manera local, en este post hablaremos de como manejar nuestro repositorio de manera remota, es decir tener nuestro codigo en un servidor.

Aqí hablaremos de gitHub un sitio público que se encarga de manejar y hostear repositorios git, el código se almacena de forma pública, aunque también se puede hacer de forma privada, creando una cuenta de pago.

El proposito de poner nuestro repositorio git en gitHub nos da 2 ventajas, una es que tendremos un completo backup de nuestro codigo (incluye historial de los commits) y la otra ventaja es la que comentamos en las entradas iniciales del blog, y es que nos permite integrar nuestro código de una manera mas fácil, las ventajas se ven donde en un proyecto trabajan varias personas y es necesario llevar el control de como ir integrando y controlando el codigo de cada una.

GitHub tiene una variedad de planes(pagados) mediante el cual podremos administrar nuestro código, pero para open source tiene servicio que no es de paga y es sobre el que nosotros trabajaremos.

Veamos los pasos

Paso 1

Para los que no tengan una cuenta, vayan a la pagina https://github.com/signup/free

Ya que estemos registrados nos mostrará una página como la siguiente

 

Paso 2

Ahora vamos a crear un repositorio, le damos click en create a repository, seguimos los pasos que nos pide y tendremos nuestro primer repositorio remoto.

Paso 3

Nos queda subir nuestro código, yo tuve problemas porque no tenia sincronizada las claves, para los que no lo han hecho aquí la liga de ayuda http://help.github.com/linux-set-up-git/ en la parte de abajo hay un apartado Set Up SSH Keys.

 

Paso 4

Despues de tener las claves sincronizadas, ejecutamos el siguiente comando

$git remote add origin git@github.com:<username>/<repositorioRemoto>.git

Ese comando crea una entrada en el archivo config dentro de la carpeta .git, si tenemos problemas con el nombre que lo hayamos escrito mal lo podemos editar. En mi caso quedo de la siguiente manera

$git remote add origin git@github.com:rozaRuby/firstAppRemote.git

El nombre que le di a mi repositorio remoto (el que creamos en la página) es firstAppRemote y mi user es rozaRuby

Paso 5

Luego para subir el código ejecutamos

$git push origin master

A continuación muestro lo que obtuve en mi consola

 

 

Al actualizar la página debemos ver algo similar

🙂

 

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.