GIT: ¿CÓMO GENERAR UNA CLAVE SSH?

http://blog.xenodesystems.com/2012/06/deploy-de-rails-en-heroku-quicktut.html

Las claves SSH también conocidas como llaves SSH, son una manera de identificar las computadoras de confianza, sin tener que ingresar una contraseña.

Las claves SSH se deben generar para cada usuario. Luego de realizar la generación obtendremos una clave privada y una clave pública.

En este artículo te mostraremos como generar claves SSH para tu usuario, siguiendo estos sencillos pasos:

VALIDAMOS SI TENEMOS UNA CLAVE SSH EXISTENTE

Para ello escribimos lo siguiente en nuestro terminal:


ls -al ~/.ssh | grep ".pub"

Si ya tenemos una clave SSH nos aparecerá algo similar a esto:


-rw-r--r--  1 frontend frontend  399 Aug 22 17:04 id_rsa.pub

Pero si aún no la hemos generado entonces nos pueden salir estos 2 mensajes:


ls: cannot access /home/frontend/.ssh: No such file or directory

ó también:


Sí, nos puede salir vacío o en blanco, ya que puede que tengamos la carpeta .ssh pero no haya ningún archivo dentro de esta.

GENERANDO UNA NUEVA CLAVE SSH

Si aún no tenemos una clave .ssh entonces la procederemos a generar escribiendo en nuestro terminal lo siguiente: Claro, colocando tu correo electrónico en vez de tu_correo@tu_dominio.com.


ssh-keygen -t rsa -C "tu_correo@tu_dominio.com"

De preferencia dejemoslo con los ajustes por defecto, por lo que cuando nos haga las 3 preguntas, simplemente pulsamos Enter.

Luego del proceso nos quedará algo parecido a esto:


ssh-keygen -t rsa -C "tu_correo@tu_dominio.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/frontend/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/frontend/.ssh/id_rsa.
Your public key has been saved in /home/frontend/.ssh/id_rsa.pub.
The key fingerprint is:
1f:34:f9:06:de:55:db:c0:6d:4c:03:97:cf:d3:15:56 tu_correo@tu_dominio.com
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|    . o S        |
|o+oo.o * E       |
|*+o...= o        |
|+o.+.o           |
|o o++..          |
+-----------------+

Esto quiere decir que ya generamos nuestras claves SSH correctamente. Como podemos apreciar, la clave privada a sido guardada en: /home/frontend/.ssh/id_rsa y la clave pública en/home/frontend/.ssh/id_rsa.pub.

Entonces ya podemos agregar nuestra nueva clave SSH al ssh-agent, escribiendo lo siguiente en nuestro terminal:


eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_rsa

Con esto hemos agregado nuestra clave al pequeño programa ssh-agent para que administre nuestras llaves por nosotros. Lo que quiere decir es que tu sólo ingresaras tu clave una sola vez, y después de eso, ssh-agent mantendrá la clave en memoria y cada vez que sea requerida ssh-agent la entregará por nosotros y si todo nos fue bien nos saldrá algo como esto:


Agent pid 6026
Identity added: /home/frontend/.ssh/id_rsa (/home/frontend/.ssh/id_rsa)

AGREGANDO NUESTRA CLAVE PÚBLICA A GITHUB

Primero instalamos xclip, para poder copiar el contenido de nuestra clave pública por consola.


sudo apt-get install xclip

Luego seleccionamos y copiamos el contenido de nuestra clave pública con la siguiente línea de código:


xclip -sel clip < ~/.ssh/id_rsa.pub

Con esto tenemos nuestra clave pública en el portapapeles, entonces ingresamos a Github, y En la sección Settings elegimos la opción SSH Keys e ingresamos.

Hacemos click en el botón Add SSH Key(Agrega tu clave SSH).

En el campo Title escribimos algo descriptivo sobre esta clave y en el campo Key pegamos el contenido del archivo ~/.ssh/id_rsa.pub(contenido que tenemos en nuestro portapapeles listo para pegar).

Y luego hacemos click en el bóton Add Key, nos pedirá nuestra contraseña de Github para validar y listo.

VALIDANDO NUESTRA CLAVE SSH CON GITHUB

Para comprobar que todo anda bien, simplemente escribimos lo siguiente en nuestra terminal:


ssh -T git@github.com

Si todo anda bien, debemos obtener lo siguiente:


Warning: Permanently added the RSA host key for IP address '178.10.123.50' to the list of known hosts.
Hi jansanchez! You've successfully authenticated.

Con esto ya tenemos registrada nuestra clave pública en github, lo cual nos permitirá subir cambios al servidor de Github creando una conexión segura.

Si deseas realizar la configuración básica de git te recomendamos leer el siguiente artículo:
Comandos básicos Git.

EXTRA: CÓMO “INSTALAR” TU CLAVE PÚBLICA EN UNA MAQUINA REMOTA

Para no estar poniendo siempre la clave del usuario de la pc a la que nos queremos conectar por ssh dejamos esta linea de código para que cuando te intentes conectar por ssh a una pc nunca más te pida la clave del usuario ya que la pc remota sabra que eres un usuario autorizado gracias a tu clave publica.


cat ~/.ssh/id_rsa.pub | ssh usuario@ip_remota "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Bueno eso es todo, espero que les haya servido de algo este pequeño artículo, no se olviden de enviar sus comentarios, compartir los posts en las redes sociales, Gracias.

GIT: ¿CÓMO GENERAR UNA CLAVE SSH?

https://git-scm.com/book/es/v1/Git-en-un-servidor

Cuando se es programador, una de las herramientas que se convierten en nuestras mejores amigas es Git. Se trata de un sistema de control de versiones creado por nada más y nada menos que Linus Torvalds, el creador del Kernel Linux y es la mejor manera de evitar catástrofes en nuestro código además de ser un excelente gestor del trabajo cuando se trabaja en equipo.

Git principalmente se usa para código, incluso hay lugares en la web (Como BitBucket yGitHub) que se dedican a crearnos un frontend para la gestión de nuestro código controlado por Git; Sin embargo, no veo razón alguna por la cual Git no pueda ser usado por otras personas para otros ámbitos (diseño, arquitectura, qué se yo) en proyectos que requieran trabajar con más de una versión de un archivo y varias modificaciones. Dicho esto, aprendamos Git pues:
NOTA: Para éste tutorial usaré un sistema Linux (Ubuntu) como referencia, pero (exceptuando las instrucciones de instalación) las mismas instrucciones de uso de Git aplican para cualquier otra distro Linux, además de para MacOS o bien, gente que use CygWin en Windows  por ejemplo.
1) Instalando Git
Para instalar Git en Ubuntu Linux por ejemplo, haríamos lo siguiente en Terminal:
sudo apt-get install git git-core

2) ¿Primera vez? Configura tus Opciones

Ahora tendremos que correr éstos comandos (Globales entre sistemas) para configurar nuestras opciones de Git:

1. git config --global user.name "Tu Nombre"
2. git config --global user.email tu-email@servicio.com
3. git config --global push.default simple

Como podrán notar, el nombre va entre comillas, el e-mail no.

3) Editor predeterminado

Cuando necesitemos añadir un mensaje a nuestros Commits y no lo hagamos directamente desde consola por ejemplo, necesitamos que un editor aparezca y nos recuerde/permita hacerlo, para configurar ésta opción hacemos:

git config --global core.editor "editor"

Algunas opciones a usar en lugar de “editor” son por ejemplo: subl -w (Para SublimeText en todas las plataformas) mate -w (Para TextMate en Mac) gvim -f  (Para GVim en Linux) o bien, mvim -f (Para MacVim en Mac); Yo personalmente uso nano para el editor nano (de consola) en Linux. Recuerda que debes seleccionar una opción según tu sistema operativo y asegurarte de que el editor está instalado… Para Linux por ejemplo usaremos GVim y lo instalaremos de la siguiente manera antes de establecer la opción (en Ubuntu):

sudo apt-get install vim vim-gtk vim-gnome

4) Nuestro primer Repo!

Ahora sí, es hora de empezar a trabajar con Git para conocer sus beneficios: Crea unanueva carpeta en algún lugar y añade unos 2 o 3 archivos de texto (o HTML o de cualquier tipo de script o código que quieras) además de una imagen .jpg o .png por ejemplo, unacarpeta vacía (con el nombre “empty”) y un archivo vacío con extensión “.dumm” (y de nombre “archivo”) jaja. En tu terminal haz cd hacia la ruta de la carpeta donde pusiste todo, luego inicializa un repositorio Git… Éstos dos pasos se hacen así:

cd ruta/a/carpeta
git init

5) Git Ignore

Por defecto, Git siempre toma todo el contenido de la carpeta del proyecto donde se inicializó el repo y lo utiliza cuando trabajamos con el repositorio… El problema con ésto es que hay ciertos archivos que ciertamente no queremos en nuestro repositorio o es más, no queremos que se les tome en cuenta porque son constantemente cambiados. Éstos son aquellos como por ejemplo los “Logs” o también, el famoso “Thumbs.db” en Windows por solo mencionar algunos. Para evitar que éstos archivos se nos interpongan, tenemos que crear un archivo llamado .gitignore (obviamente oculto) en la raíz de la carpeta del proyecto y debe de tener el siguiente formato según nuestras necesidades:

# Ignorando grupos de archivos individuales por extensión

rutas/de/locación/*.extensión

# Ignorando una Carpeta

ruta/a/carpeta/ignorada

# Ignorando un Archivo Individual

ruta/a/archivo.ext

Si ésto de arriba no tuvo mucho sentido para ti, veamos un ejemplo: Por decir, supongamos que quiero evitar que Git cargue las imágenes que puse en mi carpeta de ejemplo que hice arriba, el archivo “.dumm” que me inventé y la carpeta vacía. Mi archivo.gitignore quedaría algo así:

# Ignorando JPG's y PNG's

/*.jpg
/*.jpeg
/*.png

# Ignorando la Carpeta Vacía

/empty

# Ignorando un Archivo Individual

/archivo.dumm

Si estás acostumbrado a trabajar con rutas de carpetas en Linux o MacOS por ejemplo, entonces éste archivo no te parecerá raro: es lo mismo. La única diferencia es que toma como Raíz a la carpeta del proyecto y de ahí uno selecciona los archivos que quiere ignorar. En el caso de querer ignorar en base a  las extensiones usamos el comodín (*) para que ignore todos los archivos que sean de ésa extensión. Si te das cuenta, en ningún momento pasamos parámetros (Como -R) puesto que Git está muy bien configurado y hará su trabajo a la perfección de manera recursiva, ésto quiere decir que aplicará las reglas adecuadas en directorios y subdirectorios (además de en todos sus archivos) cuando se amerite según nuestras instrucciones del archivo .gitignore.

6) Añadiendo archivos

Lo siguiente que se hace es añadir los archivos a nuestro árbol git. Dentro de la terminal (estando en la ruta de la raíz de nuestro proyecto) hacemos lo siguiente:

git add .

Éso es simplemente para hacer que todos los archivos (nuevos y modificados) sean añadidos a una especie de “lista de espera” de Git. El mismo comando lo tenemos que correr al borrar y/o añadir archivos/carpetas para que git tome en cuenta las modificaciones en el proyecto.

7) Haciendo válidos los cambios

Ahora tenemos que realizar un commit, para hacer válidos los cambios en nuestro proyecto. Ésto se hace con:

git commit -m "Mensaje"

Lo que va después de -m es el mensaje que describe a éste commit, siempre hagan sus commits con un mensaje de preferencia. Si no quieren añadir mensaje, omitan el -m. git commit hace válidos los cambios de manera Local en nuestro árbol del proyecto.

NOTAS: Cabe destacar que puedes usar los comandos git status y git log para monitorizar tu proyecto con Git de cuando en cuando. Por otro lado, si haces cambios menores en tu proyecto (como renombrar archivos, editarlos etc) Puedes usar el siguiente comando para añadir y hacer el commit:

git commit -a -m "Mensaje"

Pero recuerda que si haces cambios importantes (Como añadir nuevos archivos o eliminar otros por ejemplo) debes de usar el comando de add . y luego el de commit como lo harías regularmente.

8) Git y su Utilidad

Supongamos que por alguna razón eliminaste de manera forzada e irrecuperable (rm -rfjajajaja) algún archivo o carpeta de tu proyecto desde tu último commit. Bueno, pues siempre puedes volver al último snapshot de tu código (es decir, al código como estaba al momento de realizar el último commit registrado) con el comando:

git checkout -f

El parámetro -f hace que git force a sobreescribir los cambios hechos por accidente en el proyecto y se restauren los archivos y carpetas de nuestro último commit.

9) A la Nube!

Todo ésto que hemos estado viendo es en el ámbito Local. Pero, ¿Qué pasa si estoy colaborando con varios programadores en un mismo proyecto? Qué tal si quiero tener un backup de mi código en alguna parte que no sea mi PC? Qué tal si quiero que más y más gente me conozca y tenga acceso a lo que hago? Aquí es donde entran en juego los servicios de almacenamiento de repositorios Git como podrían ser GitHub y BitBucket o bien, Gitorious. Personalmente, prefiero BitBucket debido a que ofrece prácticamente las mismas funciones que GitHub y similares además de algunas ventajas que se agradecen, como el hecho de poder tener todos los repositorios públicos y privados que quieras completamente gratis. Es por ésto que en éste tutorial usaremos ése servicio, pero estás en libertad de irte con el que más te convenza.

Lo primero que haremos será sacar una cuenta de BitBucket en bitbucket.org, configuraremos nuestras preferencias y validaremos la cuenta. Más adelante, crearemos un nuevo repositorio PRIVADO que funcione con Git como control de versiones:

Le ponemos un nombre, seleccionamos un lenguaje (la selección de lenguaje ahorita es indiferente, pero trata de seleccionarlo según el tipo de lenguaje más utilizado en tu proyecto) y de momento no marcamos ni Wiki ni Issue Tracking, pues no los vamos a usar. Añadimos una descripción y nuestra web si así lo queremos también.
10) Git Push
Una vez teniendo un lugar en la web que nos sirva de alojamiento para nuestro repo, tenemos que pasar nuestros cambios a la web, así como hacemos commits locales. Justo después de hacer un commit local, si uno quiere que ésos cambios pasen a la nube (usando bitbucket) hace:

git push -u origin master

Reemplazando “usuario” por tu nombre de usuario en bitbucket y “repo” por el nombre del repo hacia donde quieres enviar tu código.

Y eso hará que Git sepa que tiene que subir la rama principal del proyecto (es decir todo el proyecto pues) a BitBucket. Para fines prácticos (no tener que introducir credenciales) uno usa integración con SSH pero eso está para explicarse en otra ocasión. También debo recalcar que el comando 1 se tiende a usar una sola vez cada que añadimos un nuevo origen remoto (por cada repo inicializado) según las instrucciones que se nos hayan dado en el mismo, y el 2 pasa a ser simplemente git push en la mayoría de sistemas tras haberlo usado como aquí se muestra la primera vez en cada repo inicializado.

11) Branching

Imaginemos a nuestro proyecto en Git como un árbol donde la raíz es el proyecto principal y de ahí crecen varias ramas. El branching en Git es justo lo que te imaginarás: Se trata de crear ramificaciones del proyecto en base a copias del código del proyecto original en las cuales podemos realizar modificaciones sin preocuparnos por comprometer el proyecto en sí. Ésto quiere decir que si yo tengo un proyecto en el cual se me ocurre añadir una nueva característica que quizá no sea lo suficientemente confiable a nivel estabilidad puedo hacerlo en una rama de mi proyecto y dejar el original intacto. Para crear ramas, usamos el siguiente comando:

git checkout -b NombredeRama

Donde “NombredeRama” es el nombre que le pondremos a nuestra rama que se creará entonces. Podemos usar el comando git branch para saber en qué rama estamos trabajando actualmente en el proyecto. Si queremos saltar de rama en rama, usamos el comando:

git checkout rama

Donde reemplazaremos “rama” (obviamente) por el nombre de la rama a la que queramos saltar.

12) Merging

Supongamos que creaste una rama nueva donde hiciste algunas modificaciones que resultaron ser una buena idea y quieres que el proyecto original (rama master) las integre. Para ésto sirve el merging… Si queremos combinar 2 ramas, nos moveremos a la rama donde queramos integrar el código nuevo (en el ejemplo la master) y haremos el merge con:

git merge Rama-a-Mezclar

Donde “Rama-a-Mezclar” es el nombre de la rama que mezclaremos con la rama a la que nos movimos. Si vamos a mezclar “ramapatito” con “master” por ejemplo entonces haríamos:

git checkout master
git merge ramapatito

Y eso añadiría los cambios realizados en “ramapatito” a la rama principal del proyecto.

13) Borrando Ramas

Cuando queramos borrar una rama que ya haya sido mezclada, lo haremos con:

git branch -d Rama

Donde “Rama” es obviamente el nombre de la rama…

Y si queremos borrar una rama que no ha sido mezclada tendríamos que usar -D en lugar de -d como en el ejemplo de arriba. Ojo que ésto no elimina los archivos mezclados, sino simplemente la rama como contenedor, para eliminar los archivos mezclados (si al final no te gustó) harías un rollback como mostramos en el paso 8.

Básicamente esas son las opciones fundamentales de Git y para qué nos sirve cada una. Espero que éste tutorial haya sido de su agrado y que a partir de ahora valoren la posibilidad de usar Git para sus proyectos… Quieras que no, te permite tener un ambiente de trabajo más ordenado y tranquilo.

Ruby on Rails desde Cero: Procesamiento Asíncrono (http://codehero.co/ruby-on-rails-desde-cero-procesamiento-asincrono/)

¿Por qué necesitamos procesamiento asíncrono?

En todo momento de una aplicación queremos que el usuario esté lo más a gusto posible cuando se encuentre utilizando la aplicación. Es por esto que utilizamos “client side frameworks”, Ajax, procesamiento asíncrono entre otras cosas… Todo para que la experiencia del usuario dentro de nuestra aplicación sea la mejor y más rápida posible.

¿En que partes de nuestra aplicación podríamos utilizar dicho procesamiento asíncrono?

El uso más común y frecuente es en el registro de usuario con funcionalidad de correo de bienvenida. Por lo general el proceso de envío de correos es bastante lento, desde que el usuario presiona el botón de “registrar” hasta que el servidor de correos devuelve una respuesta pueden pasar más 5 segundos, es por esta razón que la solución obvia es utilizar este tipo de tareas asíncronas. Otro posible ejemplo es un “contador” de visitas, sea a un post o página particular. Actualización de algún campo en base de datos, procesamiento de imágenes, entre otros.

El resúmen general el procesamiento asíncrono lo utilizamos cuando cierta funcionalidad dentro de una aplicación no requiera de la intervención del usuario, sea una tarea lenta o simplemente algo que queramos ejecutar en un horario específico.

En la versión 4.0 de Rails se pretendía que existiera la funcionalidad para manejo de procesamiento asíncrono, lamentablemente no pudo ser posible (no conozco el motivo) y se postergó hasta la versión 4.1 que está próxima a salir. En lo que sea oficial posiblemente tendremos un post para enseñar como funciona.


¿Por qué esta librería y no otra?

Elegí la librería sucker_punch para esta entrada por lo simple que es, funciona sobre el mismo proceso de la aplicación, no necesita configuración alguna ni tampoco una base de datos “key/value” como Redis, todo esto quiere decir que podemos utilizar esta librería en Heroku sin coste adicional al que recibimos de la aplicación actualmente.

La otra posible opción (sencilla) era utilizar delayed_job pero requiere algo más de configuración, otro proceso para funcionar y por esto no la elegí.

Cuando el procesamiento asíncrono es muy grande, ejemplo: encolar miles o millones de tareas diarías, monitoreo y control exahustivo de tareas realizadas, interfaz gráfica, recomiendo evaluar sidekiq o resque.

Cómo mencioné anteriormente en este capítulo utilizaremos la librería sucker_puch para realizar dos simples tareas. Enviar un email de bienvenida y actualizar un contador que representa un campo en base de datos cada vez que alguien se meta en cierta página o post.


Instalación

Para instalar esta libreria basta con agregar a el Gemfile de nuestra aplicación la siguiente línea:

 

 

Luego hacemos bundle install. Cabe destacar que esta libreria no es dependiente de Rails, la podríamos utilizar en una aplicación Sinatra o Padrino.

Empleando la librería

Dentro de nuestra aplicación Rails, debemos generar un Mailer si es que no tenemos y configurarlo como aprendimos en la entrada Enviar Emails (Action Mailer) a su vez utilizaremos el mismo mensaje dentro del correo.

 

 

Luego debemos configurar todo como lo explica la entrada antes mencionada. Una vez que estemos seguros que es posible enviar correos agregamos sucker_punch a la formula.

Para esto vamos a crear un directorio llamad jobs dentro del directorio app donde alojaremos el código para nuestro procesamiento asíncrono.

 

 

Luego crearemos un archivo llamado user_welcome_job.rb dentro del directorio app/jobs

 

 

Dentro de este archivo agregaremos lo siguiente:

 

 

Podemos apreciar lo siguiente: – include SuckerPunch::Job esta llamada incluye las funcionalidades de la librería y hace posible el procesamiento síncrono y asíncrono. – método perform se utiliza obligatoriamente y es el encargado del procesamiento.

Luego para poder llamar a este proceso y poder enviar el email debemos hacer la llamada desde el controlador o modelo en la acción create de la siguiente manera.

 

 

Rails automaticamente incluye cualquier archivo que tenga extensión .rb y se encuentre en el directorio app por lo tanto podemos llamar directamente a la clase UserWelcomeJob y crear una nueva tarea que se ejecutará asíncronamente al indicarle async y llamará al método perform pasando como parámetro un usuario. De igual manera podríamos ejecutar la tarea síncrona eliminando la llamada asyncUserWelcomeJob.new.perform(@user).

Para nuestro segundo caso: incrementar el contador de visitas a cierta página dentro de nuestra aplicación luego de 1 minuto. Por ejemplo: el perfil de un usuario.

Suponemos existe un campo en base de datos llamado profile_view cuya finalidad es almacenar esta información.

Lo primero que debemos hacer crear un archivo de “jobs” nuevo:

 

 

En este archivo agregamos el siguiente código que nos permitirá actualizar la cantidad de visitas cada vez que ingrese alguien a una página.

 

 

En esta tarea podemos apreciar nuevos detalles.

  • workers 4 indica la cantidad de procesos ligeros “simultaneos” que se podrán crear para cumplir cierta tarea, el valor predeterminado es 2.
  • Cuando se modifica información con ActiveRecord debemos tener en cuenta el “pool” de conexiones a la base de datos. Para no agotar las conexiones utilizamos la siguiente línea de códigoActiveRecord::Base.connection_pool.with_connection la cual permite que una vez finalizada la ejecución de dicha tarea la conexión retorne al “pool”.
  • método later se encarga de llamar al método perform luego de ciertos segundos, en nuestro caso 60segundos.

Dentro del controlador de usuarios en el método show agregamos el siguiente código.

 

 

De esta manera llamamos directamente al método later asíncronamente y el mismo se encargará de llamar al métodoperfom que se encargará de actualizar la información en base de datos.

Ruby on Rails desde Cero: Procesamiento Asíncrono (http://codehero.co/ruby-on-rails-desde-cero-procesamiento-asincrono/)

Ruby on Rails desde Cero: ActiveRecord parte 1 (http://codehero.co/activerecord-parte-1/)

¿Qué es ActiveRecord?

Active Record es una clase para la administración y funcionamiento de los modelos. Esta clase proporciona la capa objeto-relacional que sigue rigurosamente el estándar ORM (Tablas en Clases, Registros en Objetos, y Campos en Atributos), facilita el entendimiento del código asociado a base de datos y encapsula la lógica específica haciéndola más fácil de usar para nosotros los programadores.

Ventajas del ActiveRecord

  • Manejo de entidades con objetos de Ruby.
  • Las acciones del CRUD (Insertar, leer, modificar y eliminar) están encapsuladas así que se reduce el código y se hace más fácil de comprender.
  • Código fácil de entender y mantener
  • Se reduce el uso de código SQL considerablemente lo que implica sierta independencia del manejador de base de datos que usamos.

Recuperando objeto único

ActiveRecord ofrece cinco maneras para obtener un objeto único que iremos demostrando una a una:

Find

Esta función nos permite obtener un objeto de la base de datos buscándolo por el identificador primario (primary key), un Ejemplo de esto seria:

 

 

Suponiendo que ‘Usuario’ es el modelo que accede a base de datos, este ejemplo ejecuta el siguiente comando MySQL:

 

 

take

Esta función simplemente toma un objeto de la base de datos sin un orden específico. Veamos un ejemplo y la ejecución SQL que éste ejecuta:

 

 

Este ejemplo ejecuta por detrás del código el siguiente comando SQL:

 

 

first y last

Estas útiles funciones nos dan el primer y último registro del objeto que estemos solicitando respectivamente. Veamos ejemplos de estas funciones y la equivalencia en sintaxis SQL:

 

 

El equivalente a la ejecución de estos ejemplos sería lo siguiente:

 

 

find_by

Esta última función recupera el primer registro que coincida con las características dadas, veamos un ejemplo con su equivalencia SQL para entender mejor:

 

 

El equivalente comando SQL para este ejemplo es el siguiente:

 

 


Recuperación de varios objetos en lotes

Las funciones que mostraremos a continuación nos permite obtener listas de objetos.

all

Esta función como su nombre nos dice recupera todos los registros de una tabla retornando en un arreglos de objetos. Ejemplo y equivalencia en SQL:

 

Su equivalente sentencia SQL:

 

 

find_each

El find_each método recupera un lote de registros y a continuación podemos manipular cada uno de los registros de forma individual. Este proceso ocurre hasta que haya procesado todos los objetos. Veamos unos ejemplos para comprender mejor esto:

 

 


Condiciones

ActiveRecord también nos provee métodos que nos permite especificar las condiciones para limitar los registros devueltos, lo que representa el ‘WHERE’ en sentencias SQL. Estas condiciones bien se pueden especificar de tres formas diferentes.

Primero mostraremos un ejemplo estableciendo como condición una cadena de caracteres (‘String’ es la que menos les recomiendo):

 

 

Estos ejemplos ejecutan la siguiente sentencia SQL respectivamente:

 

 

A continuación mostraremos unos ejemplos más seguros para establecer condiciones de búsqueda, al igual que lo hemos hecho hasta ahora mostrando la sentencia SQL para ayudarnos a entrar en contexto:

 

 

Su equivalente SQL:

 

 

Por último también podemos establecer nuestras condiciones de búsqueda como si fueran objetos (‘Hash’), veamos un ejemplo para explicar esto mejor:

 

 

Su equivalente SQL:

 

 


Ordenando

Al igual que con las condiciones ActiveRecord también nos permite solicitar una lista registros ordenados por algunos de los campos (El equivalente al ORDER BY en SQL).

Por ejemplo ordenaremos en este caso los usuarios por fecha de última modificación (‘updated_at’ campos que se crean automáticamente para auditoria) de la siguiere manera:

 

 

Su equivalente SQL:

 

 


Limit y Offset

Estas dos funciones nos permiten limitar la cantidad de elementos solicitados a la base de datos empezando desde un punto específico. un ejemplo de esto es lo siguiente:

 

 

Su equivalente SQL:

 

 


Group y Having

Al igual que con sintaxis SQL ActiveRecord nos permite hacer agrupaciones por algún campo de la base de datos y especificar condiciones a estos grupos veamos un ejemplo:

 

Ruby on Rails desde Cero: ActiveRecord parte 1 (http://codehero.co/activerecord-parte-1/)

Asignación masiva de parámetros en Rails 4

Asignación masiva de parámetros en Rails 4

El 12 de agosto del 2013 en ProgramaciónRuby on Rails. Por Ricardo.

La semana pasada fue movidita en Diacode. Uno de nuestros clientes en San Francisco nos propuso que le desarrollasemos un MVP para una nueva idea de negocio que tenía en mente. Se trataba de un pequeño ecommerce donde iba a poner a la venta una serie de productos nuevos, y teníamos que hacer el diseño, logo, envío de notificaciones por correo, gestión de stock, pedidos, etc y todo esto tan solo en 3 días.
Para desarrollar algo así de rápido, poder ofrecerle resultados visibles al cliente desde el primer momento sobre la evolución de nuestro trabajo, y permitirnos reaccionar de manera ágil y flexible a los cambios que nos sugería cada vez que recibíamos feedback suyo, optamos por usar Rails 4, ya que además nos vendría bien para poder probar alguna de las funcionalidades nuevas con respecto a la versión anterior.

Una de las cosas que más me gusta controlar a la hora de programar es que un usuario no pueda enviar peticiones a la aplicación con datos que no deberían ir en esa petición, y justo en la nueva versión de Rails han añadido un mecanismo para poder controlar esto. Veamos un ejemplo muy sencillo:

El ejemplo más sencillo

Supongamos que tenemos este modelo Usuario en nuestra aplicación:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# app/models/user.rb
# == Schema Information
#
# Table name: users
#
#  id                     :integer          not null, primary key
#  email                  :string(255)      default(“”), not null
#  name                   :string(255)
#  is_admin               :boolean          default(false), Especifica si el usuario tiene privilegios de administrador o no
#  …
class User < ActiveRecord::Base
  …
end

Es un modelo muy sencillo, con su email, su nombre y un campo para determinar si el usuario tiene privilegios de administrador o no. Para permitir la creación de nuevos usuarios, podríamos presentarle al usuario un formulario tal que así:

1
2
3
4
5
<form method=”post” action=”/users”>
  <input type=”text” name=”user[email]” />
  <input type=”text” name=”user[name]” />
  <input type=”submit” />
</form>

Y en nuestro controller solo tendríamos que crear el nuevo User con los parámetros recibidos del formulario:

1
2
3
4
5
6
7
8
9
# app/controllers/users_controller.rb
def create
  @user = User.create params[:user]
end

A simple vista esto parece que puede funcionar bien, y de hecho lo hace. El usuario podría darse de alta, y gracias al esquema de nuestra base de datos, no tendría activo el campo is_admin, con lo que según la lógica de este ejemplo no tendría privilegios de administrador. Pero en realidad este ejemplono es nada seguro, ya que un usuario un poco avispado podría colarse como administrador simplemente cambiando el formulario un poco:

1
2
3
4
5
6
7
8
<form method=”post” action=”/users”>
  <input type=”text” name=”user[email]” />
  <input type=”text” name=”user[name]” />
  <input type=”hidden” name=”user[is_admin]” value=”true” /> <!– Campo añadido con el inspeccionador web del navegador –>
  <input type=”submit” />
</form>

Una vez el usuario ha añadido ese campo, se añadiría a los atributos del nuevo Usuario a crear, con lo que se auto asignaría esos privelegios que no queremos que tenga de ninguna de las maneras. ¿Qué mecanismos tenemos para evitar esto?

Atributos accesibles y atributos protegidos

Para evitar esto, Rails 3 implementó un sistema para marcar los atributos de un modelo de tal manera que pudieran ser asignados de manera masiva o no. Esto se realiza a través de dos métodos, uno llamado attr_accessible donde se listan los atributos que si pueden ser asignados de manera masiva, y otro llamadao attr_protected que hace lo contrario, marcar atributos para evitar ser asignados de manera masiva.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# app/models/user.rb
# == Schema Information
#
# Table name: users
#
#  id                     :integer          not null, primary key
#  email                  :string(255)      default(“”), not null
#  name                   :string(255)
#  is_admin               :boolean          default(false), Especifica si el usuario tiene privilegios de administrador o no
#  …
class User < ActiveRecord::Base
  attr_accessible :email, :name
  …
end

Ahora ya tenemos protegido a nuestro modelo de tal manera que si se le asignase de manera masiva otro parámetro que no estuviera incluido en la lista de attr_accessible, sería ignorado.

En un principio parece que ya está solucionado y podría ser cierto, pero este es un ejemplo muy sencillo y lo malo de usar attr_accessible y attr_protected era que la responsabilidad de que funcionase correctamente racaía directamente sobre el desarrollador y que decidiese o se acordasede marcar todos los atributos importantes como accesibles. Y reconozcámoslo, todos cometemos errores tarde o temprano, y olvidarse añadir un atributo con attr_accesible puede ser más común de lo que uno cree.

Egor Homakov, su hack a GitHub y el cambio en Rails

Uno de los ejemplos más conocidos sobre alguien que explotó esta debilidad en la seguridad de Rails, fué Egor Homakov, quien analizando y haciendo conjeturas sobre GitHub y la estructura de su base de datos, fué capaz de añadir su clave pública al repositorio de Rails y conseguir permisos para poder hacer commits. Entonces se decidió hacer attr_accessible seguro siempre, y no permitir añadir ningún parámetro de manera masiva al no ser que fuera especificado de esa manera previamente.

Esto ha desatado otra polémica. ¿Dónde se debería controlar qué atributos son permitidos y qué no? ¿En el modelo o en el controlador? Por un lado, y estando acostumbrados a ello, el sitio más lógico sería en el propio modelo, pero ¿qué pasa con esos atributos que podrían ser asignados dependiendo de un estado concreto del sistema ajeno al propio modelo? Imaginad, por ejemplo, que en nuestro caso quisiéramos que un usuario administrador pudiera asignar de manera masiva ese campo para crear otros usuarios administradores… para estos casos, lo más lógico sería que esto se hiciera en el controlador, ya que es el sitio que parece más óptimo para controlar si un usuario conectado puedo tener privilegios para hacer eso o no.

Rails 4 y strong parameters

Con la llegada de la última versión, el equipo de Rails ha decido que el responsable de marcar qué atributos son permitidos para la asignación masiva tiene que ser el controller, prohibiendo de manera predeterminada la asignación directa de parámetros. Esto se consigue usando la gemastrong_parameters, la cual han añadido al propio core de Rails 4. Para usarla en nuestro ejemplo, sería muy sencillo, solo tenemos que eliminar el método attr_accessible de nuestro modelo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# app/models/user.rb
# == Schema Information
#
# Table name: users
#
#  id                     :integer          not null, primary key
#  email                  :string(255)      default(“”), not null
#  name                   :string(255)
#  is_admin               :boolean          default(false), Especifica si el usuario tiene privilegios de administrador o no
#  …
class User < ActiveRecord::Base
  …
end

Y en nuestro controller simplemente especificar qué parámetros son permitidos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# app/controllers/users_controller.rb
def create
  # De esta manera tendríamos un ActiveModel::ForbiddenAttributes
  # @user = User.create(params[:user])
  # Manera correcta ahora:
  @user = User.create(user_params)
end
private
def user_params
  # Aquí podríamos añadir lógica para aceptar
  # unos parámetros u otros dependiendo del tipo de usuario
  params.require(:user).permit(:email, :name)
end

De esta manera, le estamos diciendo que dentro de los parámetros, y mas concretamente dentro de los que estén bajo la clave :user, están permitidos los que se llamen email y name. Si se le asignase cualquier otro parámetro, dependiendo de nuestra configuración, podríamos hacer que saliese por ellog o que lanzase una excepción. En el caso de que nos olvidemos de usar este método, Rails nos lanzaría un ActiveModel::ForbiddenAttributes recordándonos que estamos asignando directamente parámetros de manera masiva, con el peligro que esto conlleva.

Asignación masiva de parámetros en Rails 4

git – la guía sencilla una guía sencilla para comenzar con git. sin complicaciones ;)

configuración

Descarga git para OSX

Descarga git para Windows

Descarga git para Linux

crea un repositorio nuevo

Crea un directorio nuevo, ábrelo y ejecuta
git init
para crear un nuevo repositorio de git.

hacer checkout a un repositorio

Crea una copia local del repositorio ejecutando
git clone /path/to/repository
Si utilizas un servidor remoto, ejecuta
git clone username@host:/path/to/repository

flujo de trabajo

Tu repositorio local esta compuesto por tres “árboles” administrados por git. El primero es tu Directorio de trabajo que contiene los archivos, el segundo es el Index que actua como una zona intermedia, y el último es elHEAD que apunta al último commit realizado.

add & commit

Puedes registrar cambios (añadirlos al Index) usando
git add <filename>
git add .
Este es el primer paso en el flujo de trabajo básico. Para hacer commit a estos cambios usa
git commit -m "Commit message"
Ahora el archivo esta incluído en el HEAD, pero aún no en tu repositorio remoto.

envío de cambios

Tus cambios están ahora en el HEAD de tu copia local. Para enviar estos cambios a tu repositorio remoto ejecuta
git push origin master
Reemplaza master por la rama a la que quieres enviar tus cambios.

Si no has clonado un repositorio ya existente y quieres conectar tu repositorio local a un repositorio remoto, usa
git remote add origin <server>
Ahora podrás subir tus cambios al repositorio remoto seleccionado.

ramas

Las ramas son utilizadas para desarrollar funcionalidades aisladas unas de otras. La rama master es la rama “por defecto” cuando creas un repositorio. Crea nuevas ramas durante el desarrollo y fusiónalas a la rama principal cuando termines.

Crea una nueva rama llamada “feature_x” y cámbiate a ella usando
git checkout -b feature_x
vuelve a la rama principal
git checkout master
y borra la rama
git branch -d feature_x
Una rama nueva no estará disponible para los demás a menos que subas (push) la rama a tu repositorio remoto
git push origin <branch>

actualiza & fusiona

Para actualizar tu repositorio local al commit más nuevo, ejecuta
git pull
en tu directorio de trabajo para bajar y fusionar los cambios remotos.
Para fusionar otra rama a tu rama activa (por ejemplo master), utiliza
git merge <branch>
en ambos casos git intentará fusionar automáticamente los cambios. Desafortunadamente, no siempre será posible y se podrán producir conflictos. Tú eres responsable de fusionar esos conflictos manualmente al editar los archivos mostrados por git. Después de modificarlos, necesitas marcarlos como fusionados con
git add <filename>
Antes de fusionar los cambios, puedes revisarlos usando
git diff <source_branch> <target_branch>

etiquetas

Se recomienda crear etiquetas para cada nueva versión publicada de un software. Este concepto no es nuevo, ya que estaba disponible en SVN. Puedes crear una nueva etiqueta llamada 1.0.0 ejecutando
git tag 1.0.0 1b2e1d63ff
1b2e1d63ff se refiere a los 10 caracteres del commit id al cual quieres referirte con tu etiqueta. Puedes obtener el commit id con
git log
también puedes usar menos caracteres que el commit id, pero debe ser un valor único.

reemplaza cambios locales

En caso de que hagas algo mal (lo que seguramente nunca suceda 😉 puedes reemplazar cambios locales usando el comando
git checkout -- <filename>
Este comando reemplaza los cambios en tu directorio de trabajo con el último contenido de HEAD. Los cambios que ya han sido agregados al Index, así como también los nuevos archivos, se mantendrán sin cambio.

Por otro lado, si quieres deshacer todos los cambios locales y commits, puedes traer la última versión del servidor y apuntar a tu copia local principal de esta forma
git fetch origin
git reset --hard origin/master

datos útiles

Interfaz gráfica por defecto
gitk
Colores especiales para la consola
git config color.ui true
Mostrar sólo una línea por cada commit en la traza
git config format.pretty oneline
Agregar archivos de forma interactiva
git add -i

git – la guía sencilla una guía sencilla para comenzar con git. sin complicaciones ;)