RVM es una herramienta impresionante que permite entre muchas otras cosas switchear de versiones de ruby o gemsets con simples comandos ahorrandonos lo que seria un "configuration hell" cada vez que querriamos cambiar la version de ruby (no se puede andar instalando y desinstalando ruby todos los dias)
El que hace un uso intensivo de RVM con múltiples versiones de ruby/gemsets sabra que averiguar la version@gemset activada en un momento dado requiere correr el comndo rvm current, esto podria ser tedioso si se abren multiples tabs y se quiere saber en un vistazo cual es la version de ruby activada y en primera instancia se puede recurrir a cambiar los titulos de los tabs, pero hay otra cosa adicional que se puede hacer
Poner la version de ruby en el prompt
Cambiar el COMMAND_PROMPT en .bashrc o .bash_profile para que muestre en todo momento la version de ruby activada (ver screenshot), incluso se pueden usar colores y poner lo que sea, aca va un ejemplo de la linea que yo agregue al final de mi .bashrc para que el prompt salga como en la imagen:
Y de aca puede haber un montón de derivaciones, como por ej poner ruby -v en lugar de rvm current o incluso algunos lo usan para mostrar a que host están conectados por ssh
Actualizacion
Una versión mejorada del comando podría ser agregar algún texto diciendo que es rvm al principio y al final en lugar de poner un comando ANSI para retornar al color gris claro específicamente, usar el color "default" que es el color del texto que sale en la terminal (que esta sujeto a la configuración de la terminal y no necesariamente sera gris claro)
Estoy armando un entorno para desarrollo con rails, y rvm... el como instalar rvm se puede ver en un montón de sitios, empezando por el sitio oficial http://beginrescueend.com/rvm/install/
En resumen, con RVM instalado, tiro esta secuencia de comando
el primero para instalar ruby 1.9.2:
sudo rvm install 1.9.2
Despues, si todo salio bien, hay que switchear a esa version de ruby
rvm use 1.9.2
Instalar la gem rails
gem install rails
Hasta ahi todo bien, pero al intentar generar un aplicacion con rails asi:
nte" y mientras ruby podria llevarse una porción apreciable de CPU (yo por mi parte espere varios minutos y lo único que obtuve fue perder un núcleo durante ese tiempo y el comando no se completo). Si bien en muchos lugares se explica que esperando un rato largo (10 o 15 minutos) el comando se completa, no es muy tolerable para lo que es el "desarrollo rapido" con RoR.
La Solucion
Buscando por la web, me encontré con este articulo, que explica cual es el problema y da una posible solución (que al menos funciono en mi caso). Básicamente explica que el problema tiene que ver con rubygems, no con bundler.
Lo que hay que hacer es asegurarse de que el cache de gems esta generado, esto se hace corriendo el comando bundle pack, como dice la explicación que extraje de la pagina:
WHAT YOU CAN DO
So it’s still slow. My general advice is to:
Check in your vendor/cache directory with your .gem files. If bundle install doesn’t make one, force it with bundle pack.
On new installs, CI runs, and deploys, use bundle --local which will attempt to resolve using only vendor/cache
Lock down to specific versions (or use the twiddle-wakka) in your Gemfile
Y despues deberia tardar mucho menos en ejecutarse
Workaround
Si por casualidad la solución que les di no funciona pueden aplicar el workaround de crear la aplicación con rails usando la opcion --skip-bundle:
Recuerden que esto causa que las gems básicas de la aplicación no se instalen, por lo que tendrán que instalarlas a mano, para eso hay que ver el archivo Gemfile que esta en el directorio raíz de la aplicacion recién creada e instalar las gemas que figuran ahí con el comando gem.
Y después si usan gemas nuevas que no se especifican por default no olviden agregarlas al Gemfile igual ya que es muy útil por si quieren deployar la app a heroku después o simplemente para que las dependencias estén explicitas. Recuerden que después se puede correr el comando "bundle install" a mano en cualquier momento.
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...
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/rackpara 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
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
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"
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.
RVM
