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

:)

 

Deshacer cambios en git

Una de las cosas interesantes que git nos ofrece es que podemos deshacer cambios, vayamos a un ejemplo, dentro de nuestro proyecto first_app tenemos la carpeta app que a su vez tiene la subcarpeta controllers, si vemos el contenido (mediante un ls), hay un archivo llamado application_controller.rb, supongamos que accidentalmente eliminamos el archivo.

En la imagen siguiente listo los archivos en app/controller y despues vemos que la carpeta esta vacía

Veamos el status mediante el comando

$git status

El estatus nos muestra que un archivo ha sido eliminado, sin embargo como aun no le hemos dado commit podemos recuperar el archivo, para lograrlo ejecutamos lo siguiente:

$git checkout -f

El argumento -f indica que sobreescriba los cambios que se hayan hecho, es asi como deshace el delete del archivo.

Muestro la manera en que lo hice:

Bien creo que el post anterior lo debí hacer en 2 partes, pero no fue así, es por eso que este post es algo corto :) .

Posteriormente hablaremos de usar git con repositorios remotos, estuvo interesante la práctica, espérenlo!!

Control de versiones con Git

Los sistemas de control de versiones nos permiten rastrear cambios en el código de nuestro proyecto, conveniente si trabajamos en equipos porque nos permiten integrar el código fácilmente y deshacer los errores involuntarios (como eliminar archivos accidentalmente ).

Saber utilizar un sistema de control de versiones es una habilidad necesaria para todos los desarrolladores de software.

Hay muchas opciones para utilizar un sistema de control de versiones, en rails se tiene estandarizado el uso de git, asi que hoy hablaremos de el y haremos un ejercicio.

Primera configuración del sistema

Ya hemos instalado git en el post Instalación y configuración de Ruby, ahora nos pasamos a nuestra primera configuración, se debe realizar una serie de pasos una sola vez. Estas son las configuraciones del sistema, lo que significa que sólo se tiene que hacer una vez por equipo:

$git config –global user.name “Nombre”
$git config –global user.email email@example.com

A continuación configuramos el editor de textos para git, yo quiero usar gedit, puedes usar vi, emacs etc.

$git config –global core.editor “gedit”

Primera configuración de repositorio

Los siguientes pasos se deben ejecutar cada vez que queremos crear un nuevo repositorio, tal vez no lo hagamos seguido pero es necesario por lo menos una vez, para nuestras prácticas.

Para generar nuestro repositorio, vamos a tomar como ejemplo nuestro primer ejercio first_app, nos situamos en la carpeta padre de la aplicación y ejecutamos el comando
$git init

Tendremos una salida como la siguiente

El siguiente paso es agregar los archivos del proyecto a nuestro repositorio, no hay muchas complicaciones debido a que git toma todos los archivos del proyecto, pero no es recomendable, por ejemplo no queremos tener los logs en nuestro repositorio.

Para ignorar ciertos archivos, editaremos el archivo .gitignore, (que lo explico en Entendiendo la estructura de nuestra primera aplicación Ruby on Rails), basta con incluir el archivo .gitignore en el directorio raíz de rails con algunas reglas para que Git ignore los archivos que deseamos, como vimos en el post anterior git lo crea por default asi que solo lo editaremos.
A continuación vemos el contenido del archivo

Lo que vemos en el archivo es que git va a ignorar

  • todos los archivos que tengan extensión .sqlite3 dentro de la carpeta db
  • todos los archivos que tengan extensión .log dentro de la carpeta log
  • y todos los archivos que esten en la carpeta tmp

Como ejercicio vamos a editar el archivo y agregar los que se muestra a continuación
tmp/*
doc/api
doc/app
*.swp
* ̃
.DS_Store
el archivo nos queda asi

Agregando y guardando

Finalmente agregaremos los archivos de nuestro proyecto a nuestro repositorio git y veremos los resultados lo hacemos mediante el siguiente comando

$git add .

A continaución muestro como lo ejecute

Para ver el estatus y lo que se agrego ejecutamos
$ git status

Para deshacer los cambios ejecutamos
$git rm –cached archivo1 …

Yo me equivoque y como estaba en la ruta equivocada agregue toda la carpeta del proyecto para deshacer los cambios tuve que hacer
$git rm -r –cached *

Nos resta decir a git que tome los cambios y lo hacemos mediante el siguiente comando

$git commit -m “Primer ejercicio con control de versiones git”

con el argumento agregamos un mensaje descriptivo a lo que acabamos de agregar al repositorio
A continuación muestro parte de lo que obtuve

En caso que no escribimos el argumento -m, debemos poner
$git commit -a
lo cual nos abrira un archivo con el editor que indicamos en el inicio de este post, y debemos introducir un mensaje descriptivo de lo contrario no nos tomará el commit

Es importante recordar que el commit es local es decir en la maquina donde estamos trabajando, en contraste con subversion(otro controlador de versiones que lo hace remotamente), git divide esta tarea en 2 piezas,

  • Registro de cambios locales mediante (git commit )
  • Registro de cambios en un repositorio remoto (git push)

Por último podemos ver los logs mediante
$git log

Entendiendo la estructura de nuestra primera aplicación Ruby on Rails

Después de instalar nuestro entorno ruby on rails y hacer nuesta primera aplicación, vamos analizar la estructura del proyecto que generamos con el comando rails new,  el objetivo es comprender para que es utilizada cada carpeta creada, a continuación muestro una breve explicación del contenido del proyecto luego una breve explicacion del patron MVC, que tiene que ver con la carpeta app, como ven ya vamos profundizando :)

app/

Es el corazón de la aplicación, incluyendo modelos, vista, controlador y ayudas

config/

Contiene la configuración de la aplicación

db/

Archivos que sirven para manipular la base de datos

doc/

Documentación de la aplicación

lib/

Modulos de biblioteca

log/

Contiene los logs de la aplicación

public/

Contiene datos disponibles para el público, como por ejemplo css(hojas de estilo), imagenes, etc.

script/rails

Contiene un script proporcionado por rails para generar código, abrir una consola de sesión o iniciar el servidor web local.

test/

Pruebas de aplicación

tmp/

Archivos temporales.

vendor/

Contiene la tercera parte del código, tales como plugins y gems

Rakefile

Utilidad disponible a través del comando rake

Gemfile

Gems requeridos para la aplicación

config.ru

Un archivo de configuración para rack middleware

.gitignore

Patrones que ignora git

Modelo Vista controlador
Dentro de nuestra aplicación llamada firs_app hay un directorio llamado app que a su vez contiene otras carpetas, por el momento nos interesan 3, models, views y controllers

Lo interesante de rails es que sigue el patron modelo-vista-controlador, quien se encarga de separar el modelo, es decir, la logica de negocio (domain logic o business logic) de las entradas y logica de presentacion o views, es decir, interfaces graficas de usuario (GUI).

El funcionamiento de una aplicación rails comienza con una petición del usuario (request), que es recibida por el servidor web, posteriormente se le pasa el controlador, quien se encarga de interactuar con la vista o el modelo, en caso de la vista unicamente envia una página html o si necesita interactuar con el modelo (un objeto Ruby que representa un elemento del sitio y se encarga de tener comunicación con la base de datos), posteriormente necesita ir a la vista para mostrar los resultados.

Por el momento ya tenemos una idea general del proyecto, en la siguiente entrada hablaremos de los sistemas de control de versiones …

Seguir

Get every new post delivered to your Inbox.