Rubyconf Argentina 2011

No podía dejar de ir a este evento, no voy a contar todo lo que vi porque el post se volveria demasiado extenso, pero voy a incluir las cosas que mas me impactaron.

Ruby Fun Day

Asi llamaron a la previa que organizaron para dos dias antes de evento. Estuvo muy bien pensado y realmente cumplio lo que decia el titulo Ruby-Fun-Day, en un principio no estaba seguro de ir pero mas tarde me di cuenta de que si no hubiera ido me hubiera arrepentido.

El RubyFunDay lo organizaron para los que querian iniciarse en el mundo de ruby y no anden tan desorientados en las charlas (el plato fuerte) pero para los que tienen cancha también estuvo muy bueno porque dio la oportunidad para conocer gente copada, actualizarse y por ahí otras actividades relativas a agile.

Ese dia aproveche la jornada para aprender de rails y heroku que los tenia un poco olvidados en un taller dictado por @bendycode (Stephen Anderson).

Vean el sitio de tryruby recargado con dibujitos del libro Poignant Guide de Why, es impresionante y una forma muy copada de aprender el lenguaje ruby

Ruby, Ruby, Ruby, Ruby, POO OO OO, la cancion de ruby

Desde el martes, el primer dia de la conferencia, escuche la canción. La deje de ringtone en mi telefono, es muy pegadiza:

El presente de ruby es 1.9

Yutaka Hara dio la charla llamada "Pasado, Presente y Futuro de Ruby", básicamente la lección que mas me quedo es que hay que migrar todo a ruby 1.9, porque ruby 1.8 es el pasado, basta hacer unos simples benchmarks para ver que ruby 1.9 es mucho mas rápido que su antecesor sin contar otras mejoras como ligeros improvements en la sintaxis del lenguaje, inclusión "out-of-the-box" de rubygems y un sin numero de otras cosas (talvez en la pagina oficial de ruby se encontrara información detallada)

En un momento de la charla @yhara pregunto quien usa Ruby 1.8 y a mi me llego a dar un poco de vergüenza levantar la mano

Mientras que ruby 1.9 esta muy bueno, siempre tuvo una cosa que no me gusto que es la falta de compatibilidad hacia atrás (igual esto seguramente tiene justificación relacionada con las impresionantes mejores que trae), esta característica hace que la migración a 1.9 sea difícil, no tanto por las aplicaciones hechas por uno mismo, sino por las dependencias ya que no todas las gemas funcionan con ruby 1.9.

Esto no me detendrá para migrar y la respuesta al problema de las dependencias no soportadas en ruby 1.9 es forkear las dependencias, en la gran mayoria de los casos la gema que no anda con ruby 1.9 es solo por un par de lineas que usan sintaxis no soportada por ruby 1.9, lo unico que hay que hacer para que funcione es arreglar esas lineas y listo, pero eso es un tema para otro post...

Links:

Slides de la charla que dio @yhara_en: http://ht.ly/7nOL7

Notas acerca de que voy a hacer para migrar proyectos: http://tario-project.blogspot.com/2011/11/migrating-everthing-to-ruby19.html

Cuba Web Micro Framework

En una espacio que organizaron para "Ligthing Talks" una de las charlas que dieron me llamo bastante la atención, Cuba es un framework mas minimalista que sinatra, vale la pena probarlo, me preguntaria como seria factible deployar eso a heroku

Actualizacion: el usuario maxidr aporto la info necesaria via comentarios en este post para deployar un app hecha con cuba (o con cualquier framework basado en rack) a heroku sin mayor esfuerzo, pasense por http://devcenter.heroku.com/articles/rack para mas info

Ahora, por ejemplo, asi es una aplicacion con tests incluidos:

# cat hello_world.rb
require "cuba"

Cuba.use Rack::Session::Cookie

Cuba.define do
 on get do
   on "hello" do
     res.write "Hello world!"
   end

   on true do
     res.redirect "/hello"
   end
 end
end

# cat hello_world_test.rb
require "cuba/test"

scope do
 test "Homepage" do
   visit "/"
   assert has_content?("Hello world!")
 end
end

Links:

https://github.com/soveran/cuba

http://cuba.is

¿Quien hace el mejor asado?

Muy graciosa la charla, despues se puso algo mas serio y explico cosas bastante interesantes. @tenderlove (Aaron Patterson), ruby commiter y rails commiter, analizo porque el router (el componente de rails que decide a que controlador llamar, que acción y con que parametros de acuerdo a la url) actual es lento en muchos casos y explico como se metio en las tripas del algoritmo de regular expression para cambiar el orden del algoritmo de búsqueda de rutas que implica evaluar un mismo texto contra varias expresiones regulares.

El resultado de esa investigación fue Journey, un nuevo enrutador con un algoritmo mas optimo y por lo tanto mas rapido para mas cantidad de rutas. Este se integrara a rails seguramente para la version 3.2

Links:

http://www.slideshare.net/tenderlove/rubyconf-argentina-2011

https://github.com/tenderlove/journey

Super Nario GC

Narihiro Nakamura, un commiter de MRI y un mago del Garbage Collection dio una charla acerca de Parallel Marking, una implementacion mas performante del GC de Ruby.

Basicamente el GC de ruby corre en un solo thread mientras que ademas tiene que detener todos los threads en ejecución hasta que finaliza el proceso de garbage collection, Parallel Marking en resumidas cuentas hace posible un garbage collection multi-thread con las consecuencias positivas en la performance que eso conlleva.

Para demostrar cuales fueron los resultados de su trabajo, Nari mostro ahi mismo el Super Mario GC que mostraba en pantalla estadisticas del GC e instanciaba objetos a proposito para provocar que se invoque el GC a cada rato.

Cuando corrio el juego con su implementacion del GC las pausas ocasionadas por este casi no se veian ni se notaban, solo se podia apreciar por un texto en el medio de la pantalla que titilaba una fraccion de segundo cuando el GC se ponia a trabajar, sino no habia manera de saber que el GC estaba trabajando, despues cuando corrio exactamente lo mismo con el GC clasico las pausas pasaban a ser dolorosas para la dinamica del juego.

Nari explico que en la implementacion actual el 30% del CPU era invertido en el GC "Stop-the-world" y que la implementacion de Parallel marking ganaba un 40% de ese tiempo invertido, esto considerando que las pruebas las hizo con un procesador de dos nucleos, pero si se ejecutara en procesadores de 4 u 8 nucleos (que mas o menos es lo que tienden a salir los procesadores asi por estos tiempos) el tiempo invertido en GC seria mucho mucho menor

Ojala que esa optimizacion se incorpore pronto.

El Cuento de los Tres Arboles (en ingles TTT)

@chacon explica en detalle lo que pasa con el subcomando reset de git. Los que nunca usaron git quedaron :O porque sin contexto es muy difícil entender de que se estaba hablando, los que usan git a diario seguramente sacaron algo nuevo de la charla. Espero que mucha gente haya perdido el "miedo" al reset y aprendido que reset --hard usualmente es una pesima idea.

Para aquellos experimentados en git (como yo, muahahahahhahaha) la charla no represento ninguna novedad en lo técnico pero fue una buena lección de como dar lecciones (con diagramas, dibujitos, comparaciones, etc...)

Github wants you

Aparentemente github no descarta la busqueda de talentos mas alla de las fronteras de EEUU donde residen sus headquarters, incluso en lugares donde *actualmente* (por lo menos hasta donde yo se), github no tiene oficinas, porque un lema al que puso enfasis fue "work where and when you want".

@mojombo, Tom Preston-Werner (vendria a ser algo asi como el Batman de git con un logo de pulpo en lugar de murcielago) explico como empezaron github y con muchos estímulos visuales (talvez, creo yo, un poco exagerados) se dedico a convencernos de ir (vacaciones flexibles, seguro medico, ambiente distendido, esas cosas).

Yo, personalmente, no creo que github en ese sentido sea muy diferente a otras compañías, pero trabajar ahi seria muy interesante, por las cosas que hacen que es algo que todos lo ven desde la perspectiva de usuario de la plataforma o "superfan"

Aca la deck de @mojombo:

http://speakerdeck.com/u/mojombo/p/optimizing-for-happiness

Igualmente nada se comparara con haber visto esa presentacion en vivo

Ruby hasta en el drinkup

Ni sabia que habia una bebida que se llamaba Ruby (el nombre completo es Absolute Ruby Red) , también vi un lambda el domingo cuando iba al RubyFunDay y la patente del taxi en el que volvi despues del drinkup decia "GEM"

RVM

No hubo una charla acerca de eso, pero hablando con otros rubystas durante la conferencia me di cuenta que tendría que probarlo. Al final lo instale y me di cuenta de que es una magnifica herramienta, sobre todo imprescindible cuando se tiene que trabajar con múltiples versiones de ruby de manera comoda (ejemplo: buscar que una gem sea compatible con ruby 1.8 y ruby 1.9)

Como nota final, talvez me este olvidando de algo, pero ya llego la hora de cortar el post... cualquier cosa seguramente habrá una segunda parte de este post si queda algo mas que decir.