Ruby: Diferencias entre “and” y “&&”, “or” y “||”

Hace unos días me preguntaban por la diferencia en ruby sobre los operadores en sus diferentes formas, esto es and Vs. && y or Vs. ||.
Mucha gente piensa que uno de los dos no sigue los atajos de los circuitos lógicos, sin embargo esto es falso. Las dos formas son igual de eficientes a la hora de evaluarse, es decir, en caso de and y && si la primera condición es falsa no se evalua la segunda, y en caso de or y || si la primera condición es verdadera no se evalua la segunda.
Ahora bien, la diferencia se encuentra en la preferencia de los operadores a la hora de evaluarse. && y || tienen mas preferencia que and y or. Para verlo claramente:

 a = false or true #=> true
 a #=> false

 a = false || true #=> true
 a #=> true

En el primer caso se evalua antes el operador =, con lo que a la variable a se le asigna el valor false. Sin embargo el resultado de la operación es true.
En el segundo caso se evalua primero el operador ||. La expresion devuelve true y a la variable a se le asigna el valor true.

Espero que haya quedado claro, para cualquier cosa.. los comentarios!

Detectando cambios en los atributos: self.changes

Hoy se nos planteaba el problema de enviar un e-mail a los usuarios inscritos a un evento cuando cuando las fechas cambiasen, para así mantenerlos informados.
Como siempre Ruby y Rails al rescate con el metodo changes, que nos devuelve un completo hash con los cambios en el objeto, y va más allá incluso devolviéndonos el cambio exacto, es decir, estado anterior y estado actual del valor.

  evento = Evento.create(:titulo => "Prueba", :fecha_inicio => Date.today) #Creamos el evento con la fecha de hoy
  evento.fecha_inicio = Date.tomorrow #Cambiamos la fecha..
  evento.changes # Nos devuelve {"fecha_inicio" =>[Wed, 22 Sep 2010, Thu, 23 Sep 2010] }

Como veis, las keys del hash son los nombre de los atributos, y los values el array [valor_anterior, valor_actual].

En nuestro caso solo necesitábamos avisar a los usuarios si el evento estaba pendiente de fecha y ahora ya la tenía, así que aprovechando los callbacks nos queda algo así:

  def after_save
    #Si cambia la fecha de inicio (antes no la tenia y ahora si.. hay que mandar un mail a los inscritos)
    if self.changes.has_key?("fecha_inicio") and self.changes["fecha_inicio"][0].nil?
        self.inscripciones.all(:conditions => ["estado != ?",Inscripcion::ESTADO_CANCELADA]).each do |inscripcion|
          InscripcionMailer.deliver_nueva_fecha(inscripcion)
        end
    end
  end

No será un método desconocido para muchos de vosotros pero tampoco está de más recordar de vez en cuando su funcionamiento!

P.D.: Una vez que el objeto se ha salvado podeis recurrir al método previous_changes

Curiosidades de Ruby y de Rails

Algunas notas curiosas sobre Ruby y Rails

• El id de false es 0 y su clase FalseClass
• El id de true es 2 y su clase TrueClass
• El id de nil es 4 (especialmente util cuando algo referencia constantemente al id 4 y no sabemos porqué)
• 1/0 es una excepción, pero 1/0.0 o 1.0/0 son Infinity
• 0/0 es una excepcion, pero 0/0.0 y 0.0/0 son NaN
• Infinity y NaN son de tipo float
• Cualquier operacion con NaN es NaN
• Cualquier cosa dividido entre Infinity es 0
• Cualquier cosa menos Inifity es -Inifinity
  

Otro dia pongo alguna más… pero estas son cuando menos, interesantes.

Trabajando en Rails con tablas de otros esquemas

Cuando trabajamos en proyectos grandes, en múltiples ocasiones podemos necesitar acceder a diferentes tablas en diferentes esquemas. En algunos lenguajes esto puede ser un caos de configuraciones, sin embargo en Rails podemos configurar la tabla para el modelo en otro esquema con una sola línea en nuestro modelo:

class Customer < ActiveRecord::Base
  set_table_name 'other_schema.customers'
end

Puede parecer una tontería pero es muy útil para hacer cargas de contenidos desde viejos proyectos, probar inconsistencias en base de datos respecto a la base de datos de producción y de desarrollo sin falta de tener varios servidores arrancados, etc.

Mejorando el rendimiento: find_in_batches y find_each

Ruby on Rails no deja de sorprenderme con la cantidad de métodos útiles que te puedes encontrar por su API un día aburrido. En esta ocasión os traigo dos métodos para tratar grandes cantidades de registros sin saturar la memoria del servidor.

El primero es find_in_batches, que nos permite traer los registros de la base de datos en lotes, pudiendo pasarle condiciones de búsqueda, tamaño de los lotes, offset…

El segundo es find_each, que es un iterador aprovechando el método anterior.

Estos dos métodos nos permiten procesar simulatenamente en dos (o más) hilos todos los registros de la base de datos, pudiendo estar un worker con los registros del 0 al 10000, otro del 10000 al 20000… etc.

No hay que olvidarse de la nota al pie en la API, estos métodos estan orientados a grandes cantidades de datos, si sólo vas a tratar unos pocos usar el find normal!

Ejecutar tareas no periodicas en segundo plano

En muchas ocasiones nuestras aplicaciones necesitaran hacer tareas que tarden bastante tiempo en dar respuesta y esto provocará que el servidor nos devuelva un timeout y veamos la página de error de la aplicación.
Una solución para ejecutar estas tareas es realizarlas en segundo plano, de forma que la aplicación se olvide del proceso y conteste al navegador rapidamente evitando así el dichoso timeout.
Para esto Ruby on Rails combinado con la potencia de Linux nos proporciona una magnífica herramienta que es el script/runner, que nos permite ejecutar una función cargando todo el entorno de la aplicación.

Vamos a suponer que tenemos una función Boletin.enviar, que envía boletines a todos los usuarios registrados en la web (y nuestra web es impresionante y tiene miles de usuarios). La función completa envia por lotes, tiene una cola, etcetera, con lo cual tarda bastante en ejecutarse, no podemos dejar al usuario que envía el boletín esperando respuesta.
Así pues nuestro action para enviar el boletín sera algo asi:

def enviar_boletin
  system("ruby script/runner \"Boletin.enviar\"&")
end

Con el & de unix le indicamos que se ejecute en segundo plano. Los lectores más avispados ya os habreis dado cuenta de que si el proceso padre, en este caso el hilo de ruby que está ejecutando el servidor, se muere pues tambien morirá su hijo y nunca llegaremos a terminar la tarea. Para ello otroa solucion de sistemas usando nohup

def enviar_boletin
  system("nohup ruby script/runner \"Boletin.enviar\"&")
end

Y por ultimo, ¿qué ocurre si queremos pasarle argumentos a la función? pues se los pasamos como si fuese una funcion normal:

def enviar_boletin
  from = "nuestro_email@nuestrodominio.es"
  system("nohup ruby script/runner \"Boletin.enviar('#{from}')\" &")
end

Espero que os sea tan util como me ha sido a mi en varios proyectos de gran envergadura.

Zerofill en Rails

Para hoy, uno rápido, pero que siempre te hace ir a buscar a google… Mostrar un número en una vista con un formato zerofill, es decir, 14 => 00014.
Para ello vamos a seguir la convención de Rails DRY y hacerlo en un helper, así que en el application_helper.rb de tu aplicación

  def zerofill(dato,tam=8)
    "%0#{tam}d" % dato
  end

Una vez lo tenemos ya solo nos queda llamarlo desde la vista con el número de dígitos que nos interesen como segundo parámetro.

 <%=zerofill(14, 5)%>

Prometo no ser tan vago para el próximo post!

Exportar SQL a CSV desde Rails

En muchas ocasiones nos encontramos con la problemática de tener que exportar muchos datos rapidamente de la base de datos SQL a un fichero CSV.

La forma mas cómoda es delegar el trabajo a la base de datos, que para eso ya lo tiene implementado. Por ejemplo vamos a exportar el archivo de libros de una biblioteca a un CSV desde nuestra aplicación rails.
En el modelo:

CSV_PATH = "#{RAILS_ROOT}/private/arhivo_biblioteca.csv"
def self.all_to_csv(path=CSV_PATH,separator=',',delimitator='"')
  #Esta es la consulta sql
  query = "SELECT l.id, l.autor, l.titulo, l.descripcion,  l.tema, l.editorial, l.paginas, l.localizacion, l.isbn  FROM `libros` l INTO OUTFILE '#{path}' FIELDS TERMINATED BY '#{separator}' ENCLOSED BY '#{delimitator}' LINES TERMINATED BY '\\n'" 
  ActiveRecord::Base.connection.execute(query) #Ejecutamos la consultar
  path #devolvemos la ruta del path 
end

Como podeis ver el método recibe 3 argumentos, que tienen valores por defecto:

El path donde dejar el fichero
El separador de los campos
Y por último el delimitador

Si queremos usarlo desde el controlador nos valdrá algo como

  def exportar
    path = Libro.all_to_csv
    send_file(path)
  end

Ahora toca experimentar… podeis pasarle más parametros, como unas conditions para no sacar todos los libros, el orden, etc…

Utilizar una columna en la misma migración en la que se crea

En muchas ocasiones nos encontramos con este problema: Creamos una migración para añadir una columna a nuesto modelo y queremos inicializarla con valores que dependen de otros. Al iniciar el enviroment de la migración se precargan en memoria los datos de las clases (también sus columnas), y la función add_column no hace que se vuelvan a interpretar dichas clases.

Por ello tenemos que recurrir la función Model.reset_column_information que nos proporciona ActiveRecord::Base.

Un ejemplo de uso sería:

class AddPrecioOfertaProductos < ActiveRecord::Migration
  def self.up
   add_column :productos, :precio_oferta, :decimal
   Producto.reset_column_information #Recargamos la información de las columnas
   Producto.all.each do |producto|
     maravilloso_codigo_que_inicializa_el_precio_en_oferta
   end
  end
  def self.down
    remove_column :productos, :precio_oferta
  end
end

La primera vez que necesite esto me volví loco para encontrarlo y creo que termine por hacer dos migraciones, así qué para que eso no os ocurra…

Will Paginate: Ir a la ultima página con elementos (out of bounds?)

En mis últimos proyectos uso el plugin (ahora gema) ‘will paginate‘ para la paginación de listados. Uno de los problemas que nos encontramos es cuando el listado tiene, por ejemplo, 4 paginas y el usuario intenta ir a la página 5. Esto ocurre normalmente cuando se borra el último elemento de una página.

El propio will_paginate nos ofrece una función para este tipo de casos y su aplicación es bastante trivial.

per_page = 10
@noticias = @noticias.paginate :page => params[:page], :per_page => per_page
@noticias = @noticias.paginate :page => @noticias.page_count, :per_page => per_page if @noticias.out_of_bounds? and @noticias.total_entries > 0

La idea es bastante sencilla. Paginamos por primera vez normal, y, en caso de que la página que nos devuelve el paginate este fuera de los limites (out_of_bounds ) y exista algun elemento (total_entries > 0) volvemos a paginar usando como parametro de página la ultima página con entradas (page_count).

Espero que haya quedado claro! Un saludo.