martes, 27 de octubre de 2015

Crear un projecto test para ver como funcionan las herencias dentro de un modelo (inheritance)

Voy a crear un  proyecto de cero para ver como y si funcionan las herencias dentro de las classes de un determinado modelo.

Asi que:


rails new single_t_inheritance_rails_test

ahora genero un modelo con scaffold generators:

rails generate model Setup setup_installations:string type:string
Es la forma más fácil de crear un proyecto.

Ahora migramos la base de datos:

bundle exec rake db:migrate

Vamos a usar herencias dentro del modelo, aquí esta la explicación en ingles con otro ejemplo


Ahora queremos migrar de un supuesto producto 1 en nombre del cliente. que seria, Customer, por ejemplo.

rails generate migration AddCustomerToProduct1Setup

Y vamos a:
db/migrations/add_customer...setup.rb
cambiamos.

def change 
  add_column :setups :customer :string 
end

bundle exec rake db:migrate

*tambien podemos hacer bundle exec rake:rollback y poner el nuevo atributo dentro de la primera migración, lo hago así para que saber como hacer en caso de que queramos agregar más atributos.

Una vez tenemos migrados los datos tenemos que crear las classes heredadas(Inherit classes).
En este caso.

single_t_inheritance_rails_test/app/models/product_1.rb

Y adentro

class Product_1 < Setup
  attribute_accessor :customer
end
Y Ahora podemos probar si funciona en la consola dentro de la terminal y nuestro proyecto:

rails console

Setup.create(setup_installations:"instalation 4")
Funciona.
Setup.create(customer:"New Customer 1")
protected attribute....
No tendria que funcionar
Es correcto! No podemos guardarlo por que solo podemos acceder si creamos una nueva clase.

Setup.create(customer:"New Customer 1")
Funciona!

Ahora ya sabes como crear herencias :). Ahun así ten en cuenta los pros y contras de estas.



jueves, 8 de octubre de 2015

Como fusionar o hacer "merge" en Git si tengo muchos cambios en diferentes ramas. Mi opción favorita

Este es un problema común si por alguna razón te enfermaste o hiciste muchos cambios en diferentes ramas con diferentes commits y evitar tener conflictos antes de intentar subir tus cambios a master.

Imaginemos que tengo La rama A, B y Master

Nuestro master esta actualizado (already updated)

En A tengo los commits: A5,A4,A3,A2,A1 adelante de master(ahead master)
En B tengo los commits: B2, B1 adelante de master(ahead master)

A es mucho más grande pero eso nos da igual. Lo primero que tenemos que tener claro es que las 2 ramas ya han sido revisadas y aprobadas por nosotros a algún otro compañero y están preparadas para enviar(ready to ship).

Pasos.

1. Hacer rebase en una de las ramas

git checkout A

usamos rebase y por ejemplo usamos "squash", aqui puedes ver la documentación:

git rebase -i HEAD~5

m A5 "el primero"
squash A4
s AX
s ""
...

realizar los cambios en nuestor editor de texto y guardarlo para convertir todo un solo commit.
Este commit lo puedo usar ahora en otra rama.

2. Hacer rebase en la otra rama.

git checkout B

ahora hago el mismo procedimiento que arriba, la diferencia es que ahora solo son 2 commits.

Esto lo hago por que una vez que pase un commit a la rama que hare merge en master no podre cambiar los commits anterirores al comit que copiare de una de las ramas y lo pasare a la que quiero enviar el codigo a master. Así quedará todo más limpio


3. Elegir cual de las 2 hare merge.
Aconsejo usar la rama más importante de las 2. En caso de que las 2 sean imporantes también puedes crear una nueva rama  prepararla explicarlo todos los cambios de las otras 2 . Para evitar malentendidos con los comapañeros lo mejor es poner los 2 links en comentarios en las 3 y cerrar las otras 2 dejando solo la nueva. 

En este caso suponemos que B es solo una serie de bugs(errores) y A es la imporante.

4. elegír commit (cherry-pick), pasarlo y resolver conflictos.

git checkout B

Copiar el los comentarios del commit en si en algún lugar, más adelante lo podras usar.
Copiar numero de commit, será algo así como "asgfh3658" al lado del commit a la derecha.

git checkout A

git cherry-pick #num_del_commit

Ahora, cruza los dedos a ver si no hay ningun conflicto, sino, no pasa nada, a resolver conflictos :). Borra una de las 2 opciones dejando la otra y borrando las lineas extra.

Una vez resueltos los conflictos:

git add .
git commit -m "aquí pega los comentarios, si todo está en ordén tienes que poner la misma info del commit" 

5. Pequeños detalles finales como cambiar info del commit y fecha de publicación.

cambiar la info del ultimo commit:

git commit --amend -m "nuevo commit" ó
git commit --amend 
Con este ultimo te lleva a tu editor predeterminado, puedes borrar parte del commit antiguo y dejar el resto.

Listo!
No fue tan difícil verdad? Quiza es un poco lio, pero creeme, es una de las formas más sencillas de hacerlo.