Rubyconf 2012

Update: ya estan disponibles todos los videos de la conferencia aca

Este fin de semana fui a la rubyconf que se organizo en la Argentina, pais donde vivo en el cual fue la segunda vez consecutiva que se organiza un evento de tal magnitud con Ruby como tema central.
En la foto principal de articulo pueden ver el pin rojo de la RubyConf 2011 y el nuevo pin amarillo de RubyConf 2012.

Como lo plantearon los organizadores del evento en un principio, esperaba la aparición de figuras relacionadas con el desarrollo del lenguaje provenientes de Japon al igual que el año pasado vinieron a presentar Yutaka Hara, Koichiro Eto y Narihiro Nakamura (pueden ver sus charlas y otras mas aca), por lo visto este año no fue posible pero mas alla de eso considero que el nivel de las charlas y la organiacion mejoraron en comparación al año pasado y no faltaron las grandes personalidades del mundo ruby local, paises vecinos y varios paises lejanos del "otro lado del charco", con visitar la pagina se puede saber quienes son

Todas las charlas estuvieron buenisimas, doy mis comentarios de las charlas que mas me gustaron
Update: tambien incluyo los videos de las mismas

Ship it: Staying Lean at LivingSocial


Andy Atkinson de livingsocial nos explica como aplican Lean a la hora de evaluar la incorporación de nuevas features. Una de las cosas mas interesantes que conto es que en lugar de desarrollar la feature completa y largarla, hacen "pedacitos de feature" o incluso solo un "preview" para que todos o un grupo seleccionado de usuarios envien feedback, si el feedback es bueno siguen adelante y van avanzando en el desarrollo de esa funcionalidad en caso contrario la dejan de lado.
Conto como ejemplo el caso de una funcionalidad hypercompleja de implementar (ahora no me acuerdo que era) que a los usuarios no les importaba y una cosa tan sencilla de implementar como un "boton de express checkout" tuvo mucho exito y les genero un monton de ganancia.

The web of tomorrow

Excelente charla de @cuerbot, con una buena presentación y graficas vintage acordes transmite un mensaje de Javascript, P2P y libertarismo digital. Basicamente explico con ejemplos puntuales como las aplicaciones en javascript usan WebRTC pueden comunicar directamente browser con browser sin servidor de por medio a excepcion de una intervencion minima al principio de la conexion similar a como lo hacen hoy VoIP y las redes P2P de intercambio de archivos. Las claras consecuencias de esto segun mi forma de ver:

• Streaming de audio y/o video entre browsers sin servers como intermediarios
• Drastica baja de requisitos de performance en el lado del server al trasladar casi la totalidad de la carga de la aplicacion a los browsers
• Descentralizacion de las comunicaciones mitigando la censura en la web
• Solo la imaginacion es el limite....

Otra cosa interesante de esta charla es que fue la única en mostrar puro codigo javascript, constituye un puesto de avanzada de invasion de javascript en el espacio de ruby, pero le doy la bienvenida

Aca los slides: https://speakerdeck.com/u/elcuervo/p/the-web-of-tomorrow

Rails 4 en 30 minutos

Introducción a Rails 4 que se liberara en pocas semanas la versión estable, fueron asombrosas las cosas que mostro como por ejemplo las queues (antes habia que recurrir a una gema adicional para eso) y ActionController::Live


Comida

Merienda con brownies de chocolate explosivo, medialunas, budines, sangunches, almuerzo con sanguches, metasushi, comida vegetariana y desayuno también.
La comida es una de las cosas en la que los organizadores se superaron












REST in peace

No se preocupen, todavia REST no murio (de hecho falta muucho para eso). Martin Salias ataca de nuevo y esta vez nos explica como hay que desarrollar interfaces REST como es debido.
Principales lecciones que me quedaron:

• Usar verbos y status codes que corresponden (ej: no usar un verbo GET para borrar algo)
• No devolver identificadores de obetos relacionados en el json/xml, porque el cliente tiene que construir las URLs (y estas podrian cambiar con el versionado, etc...)
• Sinatra parece ser mejor que rails para hacer algo simple como esto :D

Rapid Prototyping with Sass, Compass and Nanoc

No me acuerdo muchos detalles ahora, pero básicamente explicaron el toolkit de herramientas que usan para prototipar interfaces usando lo que ya se sabe de lenguajes markup de ruby, una de las que mas me intereso fue middleman,  un server de paginas estáticas muy util para prototipar cosas sin necesidad de tener que lidiar con alguna complejidad innecesaria de un framework web

Infrastructure as Ruby code

Explica como Ruby es extremadamente util  (mucho mas de lo que yo me imaginaba) al servicio de un Sysadmin, herramientas como vagrant y chef para administrar/deployar múltiples servidores, ya no en la forma "tradicional" de tener una maquina física que dure mucho tiempo, sino de una manera adaptada a la era del cloud computing en la cual los servidores son "efímeros" y el scripteo, la automatización  la escalabilidad horizontal y la posibilidad de repetir fácilmente las configuraciones se vuelve una herramienta crucial para aprovechar bien los recursos que hay ahora.

Slides: https://speakerdeck.com/u/abecciu/p/infrastructure-as-ruby-code

Fin de semana de lisp

El fin de semana pasado fui a la jsconf, y a partir de una charla de ajlopez (Implementando lenguajes de programacion en javascript) y una incidencia de lenguajes formales (una materia que estoy cursando ahora en la facultad) me plantee el objetivo de hacer el interprete de lisp en ruby

Lo que no estaba tan al tanto, es que como lisp es una influencia importante en muchos lenguajes actualmente vigentes (principalmente lenguajes dinamicos) como javascript, python y por supueso ruby, tiene caracteristicas que permiten hacer una "conversion" mas o menos legitima

Y es que, como explico ajlopez en su presentacion, muchos interpretes de X lenguaje hechos en otro lenguaje Y podrian utilizar la generacion de codigo, que es la tecnica que me llego a parecer mejor cuando estaba escribiendo las primeras lineas de dslisprb, 

Entonces...

Atomos numericos de lisp son Fixnum, Float, Bignum, o sea objetos numericos de ruby

Las listas de lisp son obviamente Arrays de ruby 

Los lambdas de lisp son lambdas de ruby, y por lo tanto...
Las variables de lisp son variables de ruby

Las funciones de lisp, no son mas que variables con un lambda asignado, por lo tanto son lambdas de ruby (ejemplo: la funcion car que se define como un lambda)

Para ejecutar el codigo lisp, este se parsea a un ast, el ast se convierte a ruby, y finalmente se evalua. Las variables lisp se representan en variables de ruby y todo se ejecuta en el mismo binding para cada instancia de DsLisp (de esta manera, si se asigna una variable en una llamada a evaluate esta sera accesible en las sucesivas llamadas)

Instalar y usar

gem install dslisprb


Para usarlo seguir las instrucciones en el README, igualmente lo hice lo mas intuitivo que me salio para Ruby 1.9, aunque no podria descartar que funcione tambien en el viejo ruby

Al final lo unico raro de este proyecto es que no implica absolutamente nada de javascript, ese lenguaje me resulta muy interesante, pero para otras cosas (webgl, jueguitos, UI, :D )

Menos precision por favor

Estoy cursando numerico en fiuba y se dio la necesidad de probar varios algoritmos en distintos grados de precision (el ejemplo mas claro de esto, es el tipo de datos double y float de C)

, como todo rubyfan decidi hacerlo en ruby, pero ruby solo tiene un tipo de dato de punto flotante, llamado Float, que wrappea el double nativo de C

El truco, como en otros lenguajes con solo una precision de punto flotante, es emularlo; es decir, truncarlo a la precision deseada despues de cada operacion. Ruby tiene soluciones interesantes para hacer este tipo de cosas.

El decorator

En un principio, usamos un patron llamado decorator, con la idea de modificar el comportamiento del float:

Nuestro FloatDecorator repite cada operacion en el objeto "decorado", pero al retornar el resultado lo trunca y lo decora tambien asi mantiene el comportamiento

Asi, la raiz cuadrada de dos 2**0.5 da 1.41 y no 1.4142135623730951

La manera mas rubyway de implementar un decorator es usando method_missing En este caso se implementaria asi:

class FloatPrecisionDecorator
  def initialize(inner, factor)
    @factor = factor
    @inner = inner.to_f
  end

  def method_missing(m,*x)
    # todas las operaciones sobre el numero se ejecutan sobre el float verdadero
    # y se obtiene el verdadero resultado con precision completa del Float original
    verdadero_resultado = @inner.send(m,*x)
    # se reduce la precision, multiplicando por el factor, redondeando y volviendo a dividir
    reduced = (verdadero_resultado.to_f * @factor).round.to_f / @factor
    FloatPrecisionDecorator.new(reduced, @factor)
  end
end

# esto da un FloatPrecisionDecorator con un 1.41, adentro, no un 1.4142135623730951
p FloatPrecisionDecorator.new(2,100)**0.5

Inspect

Pero cuando se hace el print por salida estandar, aparece algo asi:

#..floatprecisiondecorator:0x8cd63f8 factor="10," inner="1.4"...

¿ No seria mejor que simplemente mostrara el 1.41 ? Para eso hay que sobrecargar el metodo inspect

class FloatPrecisionDecorator
  def inspect
    # para que llame al inspect del float decorado
    @inner.inspect
  end
end

# ahora si va a mostra simplemente 1.41
p FloatPrecisionDecorator.new(2,100)**0.5

Numeric

Es mejor si se puede hacer asi:

4.0.to_reduced_precision(:decimals => 2)

4.0.to_rp(:decimals => 2)

Para eso lo mejor es agregarle el metodo a la clase numeric:

class Numeric
  def self.reduce_precision(number, factor)
    (number.to_f * factor).round.to_f / factor
  end

  def to_single_precision(options)
    unless options[:factor]
      options[:factor] = (options[:base]||10) ** (options[:decimals]||10)
    end

    factor = options[:factor]

    FloatPrecisionDecorator.new(Numeric.reduce_precision(to_f, factor), factor)
  end
end

Coerce

Puede surgir que se tenga que sumar un numero de precision reducida a un float, pero el metodo + de la clase Float de ruby no tiene forma de saber como sumar el numero que implementamos nosotros. Esos casos ruby lo contempla con el metodo coerce, que habilita conmutar los numeros en una operacion matematica, asi:

class FloatPrecisionDecorator
  def coerce(other)
    return self, other
  end
end

inifinite?, nan? y demas

Si se hace a nuestro numero

p 2.to_sp(:decimals => 10).infinite?

Va a devolver 0.0, cuando se supone que el metodo inifnite debe devolver true o false, esto ocurre porque inifnite? tambien llama a method_missing y este trata de truncar y wrappear lo que sea, lo mejor en estos casos es evitar modificar objetos que no sean numeros. Habra que modificar method_missing:

class FloatPrecisionDecorator
  def method_missing(m,*x)
    # todas las operaciones sobre el numero se ejecutan sobre el float verdadero
    # y se obtiene el verdadero resultado con precision completa del Float original
    verdadero_resultado = @inner.send(m,*x)

    # si es numeric, truncar y wrappear
    if Numeric === verdadero_resultado
      # se reduce la precision, multiplicando por el factor, redondeando y volviendo a dividir
      reduced = (verdadero_resultado.to_f * @factor).round.to_f / @factor
      FloatPrecisionDecorator.new(reduced, @factor)
    else
      # si no, devolve el resultado como es
      verdadero_resultado
    end
  end
end

Codigo completo

class Numeric
  def self.reduce_precision(number, factor)
    (number.to_f * factor).round.to_f / factor
  end

  def to_single_precision(options)
    unless options[:factor]
      options[:factor] = (options[:base]||10) ** (options[:decimals]||10)
    end

    factor = options[:factor]

    FloatPrecisionDecorator.new(Numeric.reduce_precision(to_f, factor), factor)
  end
end

class FloatPrecisionDecorator
  def initialize(inner, factor)
    @factor = factor
    @inner = inner.to_f
  end

  def method_missing(m,*x)
    # todas las operaciones sobre el numero se ejecutan sobre el float verdadero
    # y se obtiene el verdadero resultado con precision completa del Float original
    verdadero_resultado = @inner.send(m,*x)

    # si es numeric, truncar y wrappear
    if Numeric === verdadero_resultado
      # se reduce la precision, multiplicando por el factor, redondeando y volviendo a dividir
      reduced = (verdadero_resultado.to_f * @factor).round.to_f / @factor
      FloatPrecisionDecorator.new(reduced, @factor)
    else
      # si no, devolve el resultado como es
      verdadero_resultado
    end
  end

  def coerce(other)
    return self, other
  end

  def inspect
    # para que llame al inspect del float decorado
    @inner.inspect
  end
end

p FloatPrecisionDecorator.new(2,10).infinite?

TIrate que? tirate un AJAX

Por algo se empieza...

$.ajax({ url: '/meme', statusCode: {404: function(){alert('not found');} } }).done(function(){alert('hello');});

No mas excusas para no testear con picotest

Picotest es una gem pensada principalmente para testear pequeños metodos, como helpers, funciones de calculo, etc...

Apenas se libero una primera version 0.0.1 de prueba para mostrar la idea, la cual consiste en evitar el "no vale la pena testear esto" cuando estamos frente a metodos o funciones que tienen un monton de casos pero testearlos supondria escribir mucha mas cantidad de lineas de codigo de lo que implicaria la propia funcionalidad que se testea

La solucion a esto en picotest es ofrecer un DSL que permita escribir una gran cantidad de casos de prueba en una o por lo menos muy pocas lineas. Por ejemplo:

require "picotest"

suite(1 => 1, 4 => 2, 9 => 3, 16 => 4).test(Math.method(:sqrt))

Tambien tiene sintaxis especifica para hacer oracle testing y mocking muy sencillo (seguir los enlaces para mas informacion)

Enlaces

• Post un poco mas detallado, con ejemplos: http://tario-project.blogspot.com/2012/01/no-more-excuses-for-not-testing.html
• Sitio en github: https://github.com/tario/picotest/