martes, 3 de noviembre de 2015

Mi primer rspec en Rails

Bueno, ¡Ya va siendo hora de hacer tests! Por que, nos aseguramos de que nuestro codigo funciona en cada nuevo cambio que hacemos o incluso antes de hacerlo. hay varios tipos de tests en rails, el que esta por defecto es el unity test, pero Rspec es el más famoso por se fácil de interpretar y de entender, aunque, eso si, un poco largo, Es una muy buena practica y podeis empezar con este tutorial, a hacer test driven developmnent!

Empezamos, con los más básico, vamos a isntalar el Gem o libreria dentro de nuestor proyecto.
en mi caso, uso rails 3.2.13 el rspec compatible, teneis que buscar cual es la compatibilidad en vuestro caso, ya sea en Rubygems  es  gem 'rspec-rails', '~> 3.2', '>= 3.2.1'
Otra cosa a tomar en cuenta es si necesitamos require 'spec_helper' o 'rails_helper' en el archivo spec.
Si falla algo lo mejor es ir buscando ell error en algun buscador, pero creo que no os he dicho nada nuevo ^^.
ejecuto para actualizar la libreria o gems:

bundle

Si la acualización de los gems fue bien,  ahora genero con rails los archivos para empezar a utilizar rspec.
rails generate rspec:install

Si creamos un modeo nuevo con rails generate model, nos generará unos archivos para poder hacer los tests y migrará los test también, si ya lo tenemos generado, tendremos que migrar los test (que es es este caso) nosotros mismos así:

bundle exec rake db:test:prepare

Usando el modelo hecho en el anterior post crearemos un archivo dentro de rspec/model/

un archivo con el nombre:

setup_rspec.rb

Y de contenido:

require "rails_helper"

RSpec.describe Setup, type: :model do

  before(:all)do
    @setup = Setup.new(title:"My Body")
    @sb4_setup = Sb4_Setup.new(san_type:"123456")
  end
  it "should have a matching title" do
    expect(@setup.title).to eq("My Body")
  end
  it "should have a matching san_type" do
    expect(@sb4_setup.san_type).to eq("123456")
  end
end

Ahora trata primero o escribelo y a ver si falla. Es bueno que falle. Así nos entrenaremos a hacer primero los tests y luego el codigo.
Y bueno, esa seria la primera versión, pero nos faltaria hacer tests de validators y de controllers.
Eso sera en el siguiente post :)

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.

viernes, 11 de septiembre de 2015

Calcular la fecha en x semanas

Ruby es muy practico para pequeños calculos, por ejemplo en este caso:
Quiero saber que fecha sera en 7 semanas a partir del 4 de Septiembre.
Paso la fecha que quiero calcular usando la clase Date, y parse en formato normal de fecha.
Luego agrego los días que quiero de más. Por ejemplo como quiero calcular la fecha en 7 semanas puedo poner 7*7 o directamente 49 días.
Una vez calculado, me dara el resultado en Date. Pero me parece más comodo de ver en string,así que lo convierto en string con "to_s". Y voila!

(Date.parse('4/9/2015') + 7*7).to_s

ó

(Date.parse('4/9/2015') + 49).class (Date.parse('4/9/2015') + 7*7).to_s
=> "2015-10-23"
Así que ya se que sobre que día tengo que ir al doctor cuando me dijo, "en siete semanas concierta una cita" :)